CMMI and Requirements Part I

Share This Post

CMMI and Requirements Part I
A lot of our clients are looking at CMMI-Dev ( to see how their software development organizations can benefit from it. However what I have noticed is that many people refer to CMMI as a process. CMMI is actually a framework for developing and improving processes. What does this mean? This mean the CMMI does not prescribe step by step what you should do, instead they give “Specific Goals” and “Specific Practices” which describe what criteria a process should satisfy. CMMI defines 22 process areas and 5 (or 6 if you count zero as a level) levels of maturity. Two of the process areas are related to requirements, Requirements Management which is a Level 2 process and Requirements Development which is a Level 3 process.

The 6 levels are:





The CMMI-Dev specification defines a requirement as:
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
There are two Process Areas related to requirements, Requirements Development and Requirements Management.
Requirements Development (Level 3)
• SG 1 Develop Customer Requirements
– SP 1.1 Elicit Needs
– SP 1.2 Develop the Customer Requirements
• SG 2 Develop Product Requirements
– SP 2.1 Establish Product and Product Component Requirements
– SP 2.2 Allocate Product Component Requirements
– SP 2.3 Identify Interface Requirements
• SG 3 Analyze and Validate Requirements
– SP 3.1 Establish Operational Concepts and Scenarios
– SP 3.2 Establish a Definition of Required Functionality
– SP 3.3 Analyze Requirements
– SP 3.4 Analyze Requirements to Achieve Balance
– SP 3.5 Validate Requirements
Requirements Management (Level 2)
• SG 1 Manage Requirements
– SP 1.1 Obtain an Understanding of Requirements
– SP 1.2 Obtain Commitment to Requirements
– SP 1.3 Manage Requirements Changes
– SP 1.4 Maintain Bidirectional Traceability of Requirements
– SP 1.5 Identify Inconsistencies Between Project Work and Requirements
As you can see, the Specific Goals and Specific Practices are quite high level. Therefore, there are a number of processes that could satisfy the criteria. The key point is that the CMMI describes the areas of a process that should be examined. In subsequent articles I will examine how various processes satisfy the letter and the spirit of the CMMI requirements process areas.

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.