Subscribe by Email

Friday, May 14, 2010

Requirements Development (RD) Process Area in CMMi

he purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. An Engineering process area at Maturity Level 3.
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 lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability).
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.

Specific Goals and Practices

SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
- SP 1.1 Elicit Needs.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
- SP 1.2 Develop the Customer Requirements.
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.

SG 2 Develop Product Requirements
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product component requirements.” Product and product component requirements address the needs associated with each product lifecycle phase.
- SP 2.1 Establish Product and Product-Component Requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions.
- SP 2.2 Allocate Product-Component Requirements.
Allocate the requirements for each product component. The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production.
- SP 2.3 Identify Interface Requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.

SG 3 Analyze and Validate Requirements
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment.
- SP 3.1 Establish Operational Concepts and Scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario.
- SP 3.2 Establish a Definition of Required Functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
- 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. Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
- SP 3.5 Validate Requirements.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

No comments:

Facebook activity