Background
In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 5. We also look at the mapping from RMM level 5 to various CMMI levels.
In the previous article in the series, we looked at how RMM level 4 – traced requirements processes map to CMMI levels.
RMM Level 5 – Integrated Requirements
In RMM level 4 we discussed the benefits of establishing traceability within the scope of the requirements realm. This traceability helped us with tracking the impact of changes and validation of requirements, and it helped us with reporting and management functions that improved our insight and lessened our efforts.
RMM level 5 extends this traceability concept beyond the requirements realm. We can extend tracing into development, testing and documentation, as well as project management.
Delivery Scheduling
Each delivery of our software includes a set amount of functionality. We prefer using a timebox approach for planning those deliveries. We also suggest using use cases as the “pieces” of functionality that are delivered. We also have proposed an approach to managing changes to the delivery schedule. This overall process is a form of integration of requirements, and is dependent upon having organized, structured, traced requirements. It also requires us to create linkages between implementation elements/effort and the requirements that are supported.
Quality Assurance
There are two elements of integration between QA and requirements. The first is in defining test cases based on use cases. Each use case drives the creation of one or more test cases that are used to validate that the delivered software meets the requirements.
The second element is in tracking and management of bugs. We have a triage process for determining how to address bugs. Those bugs can come from anywhere – and sometimes they come from incorrect requirements. Establishing relationships between requirements and bugs allows us to manage the defect resolution process more effectively.
Documentation
When we write documentation, our goal is to have the reader know how to accomplish something that they want to do. When we develop software, we define the things that users will be able to do. It only makes sense to structure documentation around use cases.
Mapping CMMI Levels to RMM Level 5
In our diagram, we show the following mappings for RMM level 5:
- CMMI level 0 – No Entry
- CMMI level 1 – No Entry
- CMMI level 2 – No Entry
- CMMI level 3 – Requirements Should Be Integrated
- CMMI level 4 – Requirements Should Be Integrated
- CMMI level 5 – Requirements Should Be Integrated
For CMMI Level 0 through CMMI Level 2 – when our process is unmanaged, and unstructured, integration doesn’t matter. Requirements management software will not solve our problems.
For CMMI Level 3 through CMMI Level 5 – Being able to quantify the performance of our process, and improve our process based on that feedback both require an element of instrumentation and insight into our techniques and tools. Attempting to do that meaningfully without additional structure and traceability will provide limited benefit. If we’re investing this level of effort in our requirements process, we should extend it to include our overal software development process by integrating to other systems.
From a CMMI Level Perspective
The previous analysis basically looked at the “RMM level 5″ column in our grid, and inspected the relative decisions for each “CMMI level” row. Now we will look at it by reviewing the CMMI levels, and seeing how they map to the RMM level.
A quick review of the same chart (so you don’t have to scroll up and down):
At CMMI level 1 through CMMI level 3, we don’t address integration with other systems. We want to focus on getting a cohesive and powerful requirements management process in place before we look at integrating it to our other processes.
At CMMI levels 4 and 5 we are measuring and improving on our process. We require traceability as a key component to our quantified analysis and instrumentation. We should be extending that traceability beyond the requirements realm to maximize the value of what we are doing.
Summary
- RMM level 5 specifies that requirements documents are organized, structured, and traceable – both to each other and to other systems.
- Once we reach a company-standard process (CMMI level 3) we should be at RMM level 5, but we must have reached RMM level 2.
- RMM level 5 is never required to achieve any of the CMMI levels – but it is valuable and encouraged.
Don’t forget to take our One Minute Survey on CMMI and RMM Levels.
Latest Articles
Comments on all Articles
