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 4. W also look at the mapping from RMM level 4 to various CMMI levels.
In the previous article in the series, we looked at how RMM level 3 – structured requirements processes map to CMMI levels.
RMM Level 4 – Traced Requirements
RMM level 4 builds upon the previous three levels – structured, organized, and documented requirements. With an organization of structured requirements, we can overlay the notion of tracing between requirements.
Consider the structured requirements approach we adapted from Karl Wiegers.
In this structured approach, there is a notion of dependence.
- Goals depend upon use cases in order to be achieved.
- Goals depend upon non-functional requirements to define their achievability.
- Use cases depend upon functional requirements to enable their execution.
- Use cases depend upon non-functional requirements to characterize their effectiveness.
- Functional requirements depend upon designs, which depend upon implementation.
This structure of dependency represents the real-world reliance of one artifact on another. In an ongoing software development project, we can be making changes to any of these elements. Those changes can impact other elements.
As an example, we could change a use case. The goal that depends upon that use case might be affected. Our changes may affect the functional and non-functional requirements upon which the use case depends.
Traceability allows us to say this use case relies on those requirements. It represents relationships between specific artifacts. We can use traceability to reduce the effort (and errors) associated with propogating changes through the dependency network.
We can also use traceability to enable interesting aggregations of reporting information. For example, we could identify the percentage of completion of a given use case – by looking at the percentage completion of all implementation elements that support all design elements upon which the use case depends. Other analogous relationships can be created to meet other reporting objectives.
We can also use traceability to validate completeness (IBM uses the word “coverage” in their article) of our specification. We can review a goal, and ask the question: “Are all of the use cases required to achieve this goal defined?” We can also validate in the other direction: “Are all of these use cases required to achieve that goal?” We covered this specific example in our article, Completeness Validation With Use Cases. This also applies to the completeness validation of other artifacts in the requirements hierarchy.
Mapping CMMI Levels to RMM Level 4
In our diagram, we show the following mappings for RMM level 4:
- CMMI level 0 – No Entry
- CMMI level 1 – No Entry
- CMMI level 2 – Requirements Should Be Traced
- CMMI level 3 – Requirements Should Be Traced
- CMMI level 4 – Requirements Must Be Traced
- CMMI level 5 – Requirements Must Be Traced
For CMMI Level 0 and CMMI Level 1 – when our process is unmanaged, and unstructured, traceability does not provide value – it creates confusion.
For CMMI Level 2 and CMMI Level 3 – A valuable process must include organization of documented of requirements. Those documents should also be structured and traced.
For CMMI Level 4 and 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.
From a CMMI Level Perspective
The previous analysis basically looked at the “RMM level 4″ 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, we don’t address traceability We would focus on reaching CMMI level 2 before reaching RMM level 4.
At CMMI level 2 and CMMI level 3, we require that the documentation be organized. A managed process without some form of organization and consistent documentation is a poorly managed process. We also suggest that an RMM level of at least 3, and ideally 4 be adopted.
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.
Summary
- RMM level 4 specifies that requirements documents are organized, structured, and traceable.
- CMMI level 2 specifies that there is a managed process – in our case, one for managing requirements, and it should involve structure and traceability as components that simplify that management.
- A process must be at RMM level 4 before it can reach CMMI level 4.
Check out the next article, CMMI Levels and RMM Level 5 or take our One Minute Survey on CMMI and RMM Levels.
