CMMI and Requirements Part I
A lot of our clients are looking at CMMI-Dev (http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html) 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:
(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.
• 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