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 2. We also cover the tradeoffs and benefits of the practices it requires. Finally, we look at the mapping from RMM level 2 to various CMMI levels.
In the previous article in the series, we looked at how RMM level 1 – written requirements processes map to CMMI levels.
RMM Level 2 – Organized Requirements
RMM level 1 requires us to document our requirements, but doesn’t talk about how we document them. We can use emails, store information in databases, spreadsheets, and screenshots. But without an over-arching organization. In RMM level 2, we have to organize our requirements documents, we have to use consistent formatting, and we have to deal with administrative issues like security and version control.
The Case For Organizing Requirements
There are two main drivers for organizing our requirements:
- The need to consume those requirements.
- The need to change those requirements over time.
Consuming Requirements
Requirements are written not just to organize our thoughts, but to provide direction for the team. They are a form of targeted communication. The set the scope for software delivery, provide guidance in making prioritization decisions, and provide insight into what we will deliver – helping manage the expecations of our customers.
Organizing our requirements makes it easier to consume them. When we ask people to review our requirements, they will have more confidence, and experience less frustration, if they are consistently looking for documents in the same location.
This location could be a document repository, a shared drive on the network, a website, a portal site, or even organized in a file cabinet (?!). The point is that they are always in the same place. As the quantity of our requirements grows, they should also be organized in a logical way within that location. At RMM level 2, any organization is valid – as long as it is consistent, it will provide value.
Changing Requirements Over Time
While documenting the requirements provides benefit, the disorganization comes at a cost. Requirements change over time. Our requirements documentation should change over time as well.
The biggest complaint with waterfall projects is that our understanding of the requirements does not change over time. Requirements are a moving target. With a waterfall project, we define a set of requirements, and then kick off the project – sort of a fire and forget model. Months or years later, we deliver a product – and it will probably match our documented requirements. While we were happily developing against the requirements we documented, the actual requirements have changed. There’s a very high risk that what we deliver will not meet the evolved needs.
- The Standish group reports that over 80% of projects are unsuccessful
either because they are over budget, late, missing function, or a
combination. (http://www.standishgroup.com/sample_research/chaos_1994_1.php)- 53 percent of projects cost 189 percent of their original estimate.
- Average schedule overruns may be as high as 100%
- Over 40% to 60% of defects in software are caused by poor requirements
definition.- About One-Quarter of all projects are cancelled.
- Customers do not use 20% of their product features.
While poorly documented requirements are certainly a factor in the statistics above, another factor is no-longer-relevant requirements. These likely play out as features that are missing, features that are not used, and project cancellation (due to lack of relevance, or lack of ROI).
When we don’t organize our requirements, then changing them becomes more expensive – we have to find them, modify them, and notify people that they’ve been changed. It also becomes difficult to know if this document is the latest document. Organization addresses this problem.
Why Avoid Organization?
Organization does come at a cost. We have to spend the time (and possibly money) to set up the repository. We have to spend time to determine how we want to organize our requirements. And we have to spend some time putting the documents into our organized repository.
We identified the benefits of getting data from an organized location. What if we don’t do that very often? If our requirements approvers never have to review the documents, then they don’t benefit from the effort we spent organizing the documents. Perhaps we just have a meeting where get verbal approvals, or route them all with an email (Microsoft Outlook lets you put voting buttons on emails) for approval.
If we’re using a waterfall style project where we document the requirements once, and never change them, then each person on the implementation team can just print out a copy and refer to it when they need it. Again, no benefit from organization.
We all recognize the costs of both of these approaches, but they do avoid a little bit of busy work. It’s possible, however unwise, that some teams will take this approach, and thereby not benefit from organization. Those teams might operate best at RMM level 1.
The Case For Consistently Formatting Requirements
By using consistent formatting, we make it easier for someone to read multiple requirements. They can more easily compare and contrast the documented requirements. They don’t have to spend cycles re-learning how to read each requirements document. Once they become familiar with the format, they can ignore it, and spend time on the content of the document.
When we talk about consistent requirements, we are generally talking about the logical consistency of the statements within and across requirements – but the consistency of formatting also has value. This formatting consistency is what RMM level 2 requires.
Avoiding Consistency
We save some time in training by not requiring people to write consistently. However, the time we save is probably completely absorbed by the time people spend thinking about how to structure the requirements while writing them. And we lose the benefits that come from reading requirements that use a consistent format.
Requirements Administration
The final element identified in RMM level 2 is the administrative perspective. A focus on security, access, and version control is what the IBM team identifies as the relevant administrative issues.
Security and access are identified as elements that engender trust in the documentation. We may be too agile or too trusting, but we don’t see those factors as being particularly relevant to trust. They are certainly valuable when it comes to protecting against unwanted distribution of the information – but we are not generally concerned with people modifying the documents in unacceptable ways. We’ll grudgingly admit that it is possible that a developer will open a requirements document and delete a requirement that he feels is inappropriate, or rewrite it so that it matches his implementation. We just don’t think that it is a practical concern.
Version control, however, is very important. The biggest trust issue we have is in being able to trust that we are reviewing the latest version of a requirements document. Version control provides us with that benefit. It also allows us to undo any untoward modifications of the document. At a minimum, version control should consist of the persistence of previous versions of files. This can be handled by using unique names for each version of the file, by storing copies of the file on a regular basis as backups, or by using version control.
Subversion is the best version control system (VCS) we know of. If implementing a new VCS, we suggest using subversion. It is open source, easy to administer, and best-of-breed.
Mapping CMMI Levels to RMM Level 2
In our diagram, we show the following mappings for RMM Level 2:
- CMMI level 0 – No Entry
- CMMI level 1 – Requirements Should Be Organized
- CMMI level 2 – Requirements Must Be Organized
- CMMI level 3 – Requirements Must Be Organized
- CMMI level 4 – Requirements Must Be Organized
- CMMI level 5 – Requirements Must Be Organized
For CMMI Level 0 – when our process is so ad-hoc that documentation of requirements is questionable, discussions about how we organize the requirements documents are irrelevant. We’re talking about icing and candles when we don’t even know if we have a cake.
For CMMI Level 1 – A valuable process must include documentation of requirements. Those documents really should be organized. The benefits of versioning alone should make this an easy decision. Placing the documents in known locations, and having them be written in a consistent format is valuable too.
For CMMI Level 2 and higher – When we talk about a managed process, we are talking about bringing order to the chaos. Centralizing the requirements in a repository, versioning the documents, and using consistent formatting all bring order.
Imagine a managed requirements process that does everything with the exception of applying consistent formatting to our documents. Perhaps we have various authors of our requirements documents, and they write inconsistently. There’s value in doing all of this, but it would be CMMI level 2, RMM level 1. Only with all three elements (consistent location, consistent formatting, and versioned documents) would the process be both CMMI level 2 and RMM level 2.
We would definitely focus on moving from RMM level 1 to RMM level 2 before we would try and standardize our process across our company. That standardization would be the move from CMMI level 2 to CMMI level 3. Based on that perspective, we believe that an RMM level 2 process rating is a mandatory element of all CMMI levels above CMMI level 1.
From a CMMI Level Perspective
The previous analysis basically looked at the “RMM level 2″ 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, we require that the documentation be organized. A managed process without some form of organization and consistent documentation is a poorly managed process.
At CMMI level 3, we are standardizing our approach across our company. And 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 2 specifies that requirements documents are organized.
- 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 to be at CMMI level 2.
- A process should be at RMM level 3 if it is at CMMI level 1.
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 3 or take our One Minute Survey on CMMI and RMM Levels.
