Elicit, develop, and analyze customer and contractual requirements.




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, which 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 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 selection and design or configuration of the acquired product. 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
    • Identification of quality attributes, which are non-functional properties of a product or service (e.g., responsiveness, availability, security) and are critical to customer satisfaction and to 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 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 further refine these requirements, if necessary, while the supplier builds or configures the product.

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.
  • For Enhancement Projects, enhanced and approved version of the Process Design Summary shall be made available.
  • Requirements Analyst shall be trained on the Requirements Gathering Tool, if planned to be used in 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:

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


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


  • <?>