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.
CMMI Levels and RMM Level 1 – Written Requirements
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 1. We also cover the tradeoffs and benefits of the practices it requires. Finally, we look at the mapping from RMM level 1 to various CMMI levels.
CMMI Levels and Requirements Management Maturity Introduction
CMMI (Capability Maturity Model Integration) is a description of the level of enlightenment of a process. It is essentially a measure of the quality and capability of a process. There are five categories, into one of which every process will fall. IBM took a similar approach to defining the requirements management process. In this series of posts, we will marry the two frameworks.
Flashback: A Year Ago This Week on Tyner Blain [2005-12-30]
A look back at the best from a year ago.
Writing For The Purpose of Reading
The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.
The Impact of Change and Use Cases
Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?
Product Managers Play Tug-of-War
63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.
Companies Will Waste $1B This Year on Software Tools
Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.
Non-Functional Requirements Equal Rights Amendment
We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…