Introductory Notes

This process area describes three types of requirements: customer requirements, product requirements, and product-component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product life-cycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).

Requirements are the basis for design. The development of requirements includes the following activities:

  • Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders

  • Collection and coordination of stakeholder needs

  • Development of the life-cycle requirements of the product

  • Establishment of the customer requirements

  • Establishment of initial product and product-component requirements consistent with customer requirements

This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.

Customer requirements are further refined into product and product-component requirements. In addition to customer requirements, product and product-component requirements are derived from the selected design solutions.

Requirements are identified and refined throughout the phases of the product life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product's life cycle are analyzed for impact on derived and allocated requirements.

The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product-component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product-component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.

Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:

  • Analysis of needs and requirements for each product life-cycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability

  • Development of an operational concept

  • Definition of the required functionality

The definition of functionality, also referred to as "functional analysis," is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining the services. The definition of functions, their logical groupings, and their association with requirements is referred to as a "functional architecture."

Analyses occur recursively at successively more detailed layers of a product's architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of the following:

  • Constraints of various types

  • Technological limitations

  • Cost and cost drivers

Table . Practice-to-Goal Relationship Table

Continuous Representation

Staged Representation

SG 1 Develop Customer Requirements

SG 1 Develop Customer Requirements

SP 1.1-1 Collect Stakeholder Needs

SP 1.1-2 Elicit Needs

SP 1.1-2 Elicit Needs

SP 1.2-1 Develop the Customer Requirements

SP 1.2-1 Develop the Customer Requirements

 

SG 2 Develop Product Requirements

SG 2 Develop Product Requirements

SP 2.1-1 Establish Product and Product-Component Requirements

SP 2.1-1 Establish Product and Product-Component Requirements

SP 2.2-1 Allocate Product-Component Requirements

SP 2.2-1 Allocate Product-Component Requirements

SP 2.3-1 Identify Interface Requirements

SP 2.3-1 Identify Interface Requirements

SG 3 Analyze and Validate Requirements

SG 3 Analyze and Validate Requirements

SP 3.1-1 Establish Operational Concepts and Scenarios

SP 3.1-1 Establish Operational Concepts and Scenarios

SP 3.2-1 Establish a Definition of Required Functionality

SP 3.2-1 Establish a Definition of Required Functionality

SP 3.3-1 Analyze Requirements

SP 3.3-1 Analyze Requirements

SP 3.4-3 Analyze Requirements to Achieve Balance

SP 3.4-3 Analyze Requirements to Achieve Balance

SP 3.5-1 Validate Requirements

SP 3.5-2 Validate Requirements with Comprehensive Methods

SP 3.5-2 Validate Requirements with Comprehensive Methods

 

GG 1 Achieve Specific Goals

 

GP 1.1 Perform Base Practices

 

GG 2 Institutionalize a Managed Process

GG 3 Institutionalize a Defined Process

GP 2.1 Establish an Organizational Policy

GP 2.1 Establish an Organizational Policy

GP 2.2 Plan the Process

GP 2.2 Plan the Process

GP 2.3 Provide Resources

GP 2.3 Provide Resources

GP 2.4 Assign Responsibility

GP 2.4 Assign Responsibility

GP 2.5 Train People

GP 2.5 Train People

GP 2.6 Manage Configurations

GP 2.6 Manage Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and Control the Process

GP 2.8 Monitor and Control the Process

GP 2.9 Objectively Evaluate Adherence

GP 2.9 Objectively Evaluate Adherence

GP 2.10 Review Status with Higher Level Management

GP 2.10 Review Status with Higher Level Management

GG 3 Institutionalize a Defined Process

 

GP 3.1 Establish a Defined Process

GP 3.1 Establish a Defined Process

GP 3.2 Collect Improvement Information

GP 3.2 Collect Improvement Information

GG 4 Institutionalize a Quantitatively Managed Process

 

GP 4.1 Establish Quantitative Objectives for the Process

 

GP 4.2 Stabilize Subprocess Performance

 

GG 5 Institutionalize an Optimizing Process

 

GP 5.1 Ensure Continuous Process Improvement

 

GP 5.2 Correct Root Causes of Problems

 

  • Time constraints and schedule drivers

  • Risks

  • Consideration of issues implied but not explicitly stated by the customer or end user

  • Factors introduced by the developer's unique business considerations, regulations, and laws

A hierarchy of logical entities (functions and subfunctions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, associated processes, or services.

Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.



CMMI (c) Guidelines for Process Integration and Product Improvement
CMMI (c) Guidelines for Process Integration and Product Improvement
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net