Demix has a large team of lead appraisers and together with our partners, conduct the most CMMI SCAMPI appraisals globally. During the appraisal, we always interview the sponsors which typically are the CIOs. One question we asked which process area is giving them the most challenges? The answer is often related to requirements volatility. The requirements gathering, requirements change and requirements validation activities are providing headaches and impacting product delivery, budget and costs.
So how does CMMI address this? The answer is provided in two CMMI process areas. The first is requirements management (REQM) and the second is requirements development (RD).
Requirements Management (REQM) has one specific goal (SG) and 5 specific practices (SPs), listed below:
SG 1 Manage Requirements: Requirements are managed and inconsistencies with project plans and work products are identified.
SP 1.1 Understand Requirements: Develop an understanding with the requirements providers on the meaning of the requirements.
SP 1.2 Obtain Commitment to Requirements: Obtain commitment to requirements from project participants.
SP 1.3 Manage Requirements Changes: Manage changes to requirements as they evolve during the project.
SP 1.4 Maintain Bidirectional Traceability of Requirements: Maintain bidirectional traceability among requirements and work products.
SP 1.5 Ensure Alignment Between Project Work and Requirements: Ensure that project plans and work products remain aligned with requirements.
Requirements Development (RD) has three goals, supported by 10 specific practices. They are.
SG 1 Develop Customer Requirements: Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
SP 1.1 Elicit Needs: Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
SP 1.2 Transform Stakeholder Needs into Customer Requirements: Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements.
SG 2 Develop Product Requirements: Customer requirements are refined and elaborated to develop product and product component requirements.
SP 2.1 Establish Product and Product Component Requirements: Establish and maintain product and product component requirements, which are based on the customer requirements.
SP 2.2 Allocate Product Component Requirements: Allocate the requirements for each product component.
SP 2.3 Identify Interface Requirements: Identify interface requirements.
SG 3 Analyze and Validate Requirements: The requirements are analyzed and validated.
SP 3.1 Establish Operational Concepts and Scenarios: Establish and maintain operational concepts and associated scenarios.
SP 3.2 Establish a Definition of Required Functionality and Quality Attributes: Establish and maintain a definition of required functionality and quality attributes.
SP 3.3 Analyze Requirements: Analyze requirements to ensure that they are necessary and sufficient.
SP 3.4 Analyze Requirements to Achieve Balance: Analyze requirements to balance stakeholder needs and constraints.
SP 3.5 Validate Requirements: Validate requirements to ensure the resulting product will perform as intended in the end user's environment.
In the traditional waterfall type methodologies or stage gate projects, the above practices are typically implemented through a variety of methods, such as UML (Unified Modelling Languages), System Requirements Specifications, Business Requirements Specifications, Change Control Processes, Requirement Traceability Matrices. SCRUM Agile has built in support for many of the practices through the product backlog and the sprint backlog, and stories.
Visit the Demix Download Page for free best practice templates and documentation.
Visit the Demix Self-Assessment page for free self-assessments.
