Purpose:

To elicit, develop, and analyze customer and contractual requirements.

Objective:

Establishes organizational expectations that all changes to contractual requirements must be reflected in the supplier agreements established and maintained.

Description:

There are two types of requirements: customer requirements, which address the needs of relevant stakeholders for which one or more products and services will be acquired, and contractual requirements are the requirements to be addressed through the acquirer’s relationship with suppliers and other appropriate organizations. Both sets of requirements should address needs relevant to later product lifecycle phases (e.g., operation, maintenance, support, disposal) and key quality attributes (e.g., safety, reliability, maintainability).

In some acquisitions, the acquirer assumes the role of an overall systems engineer, architect, or integrator for the product. In these acquisitions, the Requirements Development process area of CMMI-DEV should be used.
Requirements Development in CMMI-DEV includes additional information helpful in these situations, including deriving and analyzing requirements at successively lower levels of product definition (e.g., establishing and maintaining product component requirements).

Requirements are the basis for the acquired product’s selection and design or configuration. The development of requirements includes the following activities:

• • Elicitation, analysis, and validation of stakeholder needs, expectations, constraints, and interfaces to establish customer requirements that constitute an understanding of what will satisfy stakeholders
  • Development of the lifecycle requirements of the product (e.g., development, maintenance, transition to operations, decommissioning)
  • Establishment of contractual requirements consistent with customer requirements to a level of detail that is sufficient to be included in the solicitation package and supplier agreement
  • Development of the operational concept
  • Analysis of needs and requirements (for each product lifecycle phase), the operational environment, and factors that reflect overall customer and end-user needs and expectations for quality attributes
  • Identifying quality attributes, which are non-functional properties of a product or service (e.g., responsiveness, availability, security), is critical to customer satisfaction and meeting the needs of relevant stakeholders.

The requirements included in the solicitation package form the basis for evaluating proposals by suppliers and for further negotiations with suppliers and communication with the customer. The contractual requirements for the supplier are baselined in the supplier agreement.

Requirements are refined throughout the project lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the project’s lifecycle are analyzed for their impact on contractual requirements.

Requirements analyses aid in understanding, defining, and selecting requirements at all levels from competing alternatives. Analyses occur recursively at successively more detailed levels until sufficient detail is available to produce contractual requirements and to refine these requirements further, if necessary. At the same time, the supplier builds or configures the product.

The involvement of relevant stakeholders in both requirements development and analyses gives them visibility into the evolution of requirements.  Participation continually assures stakeholders that requirements are being
properly defined.

Entrance Criteria:

• Business Project Champion and Process Engineer assigned.
• Identified Requirements Analyst shall be trained in Requirements Elicitation and Requirements Analysis.
• Requirements Providers identified.
• Process Design Summary and Project Charter baseline communicated.
• An enhanced and approved version of the Process Design Summary shall be made available for Enhancement Projects.
• Requirements Analyst shall be trained on the Requirements Gathering Tool planned to be used on the project.

Exit Criteria:

• Stakeholder needs, expectations, constraints, and interfaces.
• Prioritized customer requirements
• Customer constraints on the conduct of verification
• Customer constraints on the conduct of validation
• External Interface Requirements
• Prioritized Contractual Requirements
• Requirement Allocation Sheets
• Operational, Maintenance, Support, and Disposal Concepts
• Use Cases, User Stories
• New Requirements
• Requirements Defects Report
• Proposed Requirements Changes to Resolve Defects
• Key requirements
• Technical Performance  Measures
• Assessment of Risks Related to Requirements
• Proposed Requirements Changes
• Records of Analysis Methods and Results

Supplier Deliverables

• Requirements and validation methods (e.g., prototypes, simulations)

Process and Procedures:

• Develop Customer Requirements
• Develop Contractual Requirements
• Analyze and Validate Requirements

Tailoring Guidelines:

• None

Process Verification Record(s):

• Correspondence over e-mail clarifying Requirements
  • Stored By: Business Analyst
• Minutes of Meeting – Customer Requirements Review
  • Business Analyst
• Records Containing review feedback on the Customer Requirements Document
  • Business Analyst
• Completed Customer Requirements Checklist
  • Business Analyst
• Completed Peer Review Summary Report
  • Business Analyst
• Records containing review feedback on Customer Requirements Document
  • Business Analyst
• Approval Records from Business Process Owner, Business Project Champion, and lead Architect approving Customer Requirements Document.
  • Business Analyst

Measure(s):

• Defect Density – Process Design Summary, the total number of defects identified during customer requirements gathering and impact on processing design summary
  • Maintained by: Business Analyst
  • Submitted by: Business Analyst
• Bug Density – Customer Requirements, the number of defects identified in the Customer Requirements Document divided by the total number of Customer Requirements. <?>

• • Maintained by: Business Analyst
  • Submitted by: Business Analyst

References:

• CMMI^® for Development, Version 1.3, Software Engineering Process Management Program, November 2010
• CMMI^® for Acquisition, Version 1.3, Software Engineering Process Management Program, November 2010
• CMMI^® for Services, Version 1.3, Software Engineering Process Management Program, November 2010