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 3. We also question the language used and reinterpret some of what IBM suggests. Finally, we look at the mapping from RMM level 3 to various CMMI levels.
In the previous article in the series, we looked at how RMM level 2 – organized requirements documents processes map to CMMI levels.
RMM Level 3 – Structured Requirements
RMM level 1 requires us to document our requirements. RMM level 2 requires us to organize that documentation and use consistent formatting for the documents. RMM level 3 introduces the concept of using structured requirements, as well as the idea of requirements having attributes. The first notion relates to the relationships between requirements, and the second is a way of apply structure to the requirements so that we can reason about them more effectively.
Structured Requirements
The first thing that the IBM team identifies is the need to identify different types of requirements. Avoid all of the naming bugaboos, and consider the notion of identifying different structures of artifacts in the software development process. We have a series of elements of information that we need to understand and articulate in order to travel from an identified market need to a delivered software product.
There are many different approaches to documenting requirements. We all struggle to agree on particular naming conventions. We use different requirements documents to represent different parts of the flow.
In Alphabet Soup – Requirements Documents, we use the following diagram to try and summarize the stages of decomposition.
This is the first level of decomposition – requirements (MRD or PRD) versus specification (SRS or FRS).
There’s another level of detail in the structuring of requirements, built on the work that Karl Wiegers has done. It looks at the artifacts in more detail – and I believe is what the IBM team had in mind when they defined RMM level 3. Here’s the version of the diagram that we developed in our article on non-functional requirements, and then reference as part of our introduction to structured requirements. You can read more about this approach in those articles.
We’ve also done some exploration of how to marry interaction design with structured requirements. The approach of starting with a user-centric perspective has a lot of benefits, and we believe there is a way to combine those benefits with the benefits inherent in a structured approach to requirements documentation. Here’s the diagram we created that shows how we adapt our structured approach to an interaction design context.
Regardless of the approach you take, the element that is relevant to having an RMM level 3 requirements process is the notion that different documents represent different types of requirements/constraints/designs.
Requirement Structures
The IBM team also talks about having attributes as part of requirements. Unfortunately, this is a little bit of the “if you have a hammer, everything looks like a nail” syndrome. What their suggestion implies is
- You have a notion of objects, and you use objects to represent requirements artifacts.
- You apply the concept of attributes to structure the elements of information within those artifacts.
- You have some means (human or machine) to reason about those attributes in a way that provides distinct value relative to reasoning about the artifacts.
Their approach is unfortunate, if only because it appears presumptive, and perhaps biased. I believe we can restructure their language into something design-agnostic that achieves the same objectives.
We propose that there are two relevant benefits that could be addressed with the attributes-approach they suggest:
- Being able to manage and reason about the meta-data of a requirement artifact has value. Meta-data are pieces of data that describe the data. For example, who is the author of the document? When was it last edited? What is its priority? To which other requirements is it related? Being able to track, edit, and view this information allows us to make decisions about how and when to use the document. It helps us plan activities and investments that are looking at the process as a whole – combining information about all of the requirements to make high level decisions.
- Structuring information within a requirement artifact has value. Artifacts can be free-form text. That text can be organized into sections and lists and tables. That type of organization is helpful to humans who read it. It allows us to organize our content so that it is easier to read the requirements. Most good business writing has these elements – where the organization of information is suited to the content and its intended use. To be at RMM level 3, we must also be at RMM level 2, which requires consistent formatting. Combining that consistency with structure makes it easier for people to read (and saves time when writing) requirements. There is also benefit to using a structure that can be read by machines as well as humans. When information has structure, it introduces the possibility of machine-reasoning, just as it improves human-consumption. While machine-reasoning about elements of requirements documents is not a criterion of achieving RMM level 3, the IBM article implies that this benefit exists. And it does exist. Without going off on a tangent, we can at least easily envision the generation of a report based upon the status of all requirements scheduled for a given release. This report can be created without formally structuring the information, but it is easier to create when we can reason about the structure of the information.
I think this is exactly what IBM intended, and they just used an unfortunately symbolic word – attributes. The same criticism has been applied to much of our writing about the way we use the word requirement.
Mapping CMMI Levels to RMM Level 3
In our diagram, we show the following mappings for RMM level 3:
- CMMI level 0 – No Entry
- CMMI level 1 – Requirements Should Be Structured
- CMMI level 2 – Requirements Should Be Structured
- CMMI level 3 – Requirements Should Be Structured
- CMMI level 4 – Requirements Must Be Structured
- CMMI level 5 – Requirements Must Be Structured
For CMMI Level 0 – when our process is so ad-hoc that documentation of requirements is questionable, discussions about how we organize and structure the requirements documents are irrelevant.
For CMMI Level 1 through CMMI Level 3 – A valuable process must include documentation of requirements. Those documents really should be organized and structured. Structure is essentially organization at the next level of detail, and it is worth doing.
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 will provide limited benefit.
From a CMMI Level Perspective
The previous analysis basically looked at the “RMM level 3″ 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 require that requirements be written. We suggest that they be organized and structured.
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’ll address the higher CMMI levels in more detail as this series of articles continues.
Summary
- RMM level 3 specifies that requirements documents are organized, and structured.
- CMMI level 2 specifies that there is a managed process – in our case, one for managing requirements.
- A process must be at RMM level 2 and should be at level 3 or 4 to be at CMMI level 2 or CMMI level 3.
- A process should be at RMM level 3 if it is at CMMI level 1.
- A process should be at RMM level 4 if it is at CMMI level 2.
Note that this implies that we would spend the extra effort to get to CMMI 3 before we would try and reach RMM level 5.
Check out the next article, CMMI Levels and RMM Level 4 or take our One Minute Survey on CMMI and RMM Levels.
