Develop Product Requirements
Customer requirements are refined and elaborated to develop product and product-component 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 life-cycle phase. Derived requirements arise from constraints, consideration of issues implied but
not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined.
The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is
documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements
established.
SP 2.1 Establish Product and Product-Component Requirements
Establish and maintain product and product-component requirements, which are based on the customer 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. An example of this translation is found in the first House of Quality Functional Deployment, which maps customer desires into technical parameters. For instance, "solid sounding door"
might be mapped to size, weight, fit, dampening, and resonant frequencies.
Product and product-component requirements address the satisfaction of customer, business, and project objectives and associated attributes, such as effectiveness and affordability.
Design constraints include specifications on product components that are derived from design decisions, rather than higher level requirements.
For Software Engineering
For example, application components that must interface with an off-theshelf database component must comply with interface requirements imposed by the selected database. Such product-component requirements are generally not traceable to higher level requirements.
Derived requirements also address the cost and performance of other life-cycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.
The modification of requirements due to approved requirement changes is covered by the "maintain" function of this specific practice; whereas, the administration of requirement changes is covered by the
Requirements Management process area.
Typical Work Products
1. Derived requirements
2. Product requirements
3. Product-component requirements
Subpractices
1. Develop requirements in technical terms necessary for product and product-component design.
Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design.
2. Derive requirements that result from design decisions.
Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits.
3. Establish and maintain relationships between requirements for consideration during change management and requirements allocation.
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. In
cases where a higher level requirement specifies performance that will be the responsibility of two or more product components, the performance must be partitioned for unique allocation to each product
component as a derived requirement.
Typical Work Products
1. Requirement allocation sheets
2. Provisional requirement allocations
3. Design constraints
4. Derived requirements
5. Relationships among derived requirements
Subpractices
1. Allocate requirements to functions.
2. Allocate requirements to product components.
3. Allocate design constraints to product components.
4. Document relationships among allocated requirements.
Relationships include dependencies in which a change in one requirement may affect other requirements.
SP 2.3 Identify Interface Requirements
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.
Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product-component integration and are an integral
part of the architecture definition.
Typical Work Products
1. Interface requirements
Subpractices
1. Identify interfaces both external to the product and internal to the product (i.e., between functional partitions or objects).
As the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product. Interfaces with product-related life-cycle processes should also be identified.
Examples of these interfaces include interfaces with test equipment,transportation systems, support systems, and manufacturing facilities.
2. Develop the requirements for the identified interfaces.
Requirements for interfaces are defined in terms of origination, destination,stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
