SG 1 Develop Customer RequirementsStakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders (e.g., customers, end users, suppliers, builders, and testers) 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. Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since stakeholder needs, expectations, constraints, and limitations should be clearly identified and understood, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, a surrogate for the end user or customer is frequently involved to represent their needs and help resolve conflicts. The customer relations or marketing part of the organization as well as members of the development team from disciplines such as human engineering or support can be used as surrogates. Environmental, legal, and other constraints should be considered when creating and resolving the set of customer requirements. The following specific practice is subsumed in the staged representation by SP 1.1-2, Elicit Needs. SP 1.1-1 Collect Stakeholder NeedsIdentify and collect stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle. This practice addresses the receipt of requirements that a customer provides to define what is needed or desired. These requirements may or may not be stated in technical terms. They should address the various product life-cycle activities and their impact on the product. SP 1.1-2 Elicit NeedsElicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle. Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product life-cycle activities and their impact on the product.
Subpractices
SP 1.2-1 Develop the Customer RequirementsTransform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
The various inputs from the customer 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. Typical Work Products
Subpractices
SG 2 Develop Product RequirementsCustomer 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 are established. Refer to the Maintain Bidirectional Traceability of Requirements specific practice of the Requirements Management process area for more information about maintaining bidirectional traceability. SP 2.1-1 Establish Product and Product-Component RequirementsEstablish 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.
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. Refer to the Requirements Management process area for more information about managing changes to requirements. Typical Work Products
Subpractices
SP 2.2-1 Allocate Product-Component RequirementsAllocate the requirements for each product component. Refer to the Technical Solution process area for more information about allocation of requirements to products and product components. This specific practice provides information for defining the allocation of requirements but must interact with the specific practices in the Technical Solution process area to establish solutions to which the requirements are allocated. 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
Subpractices
SP 2.3-1 Identify Interface RequirementsIdentify 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. Refer to the Product Integration process area for more information about the management of interfaces and the integration of products and product components. 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
Subpractices
SG 3 Analyze and Validate RequirementsThe requirements are analyzed and validated, and a definition of required functionality is developed. 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. Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders' needs, expectations, constraints, and interfaces. Considerations, such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy, must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for time-critical sequencing of functions. The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then to translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept. Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment. SP 3.1-1 Establish Operational Concepts and ScenariosEstablish and maintain operational concepts and associated scenarios. Refer to the Technical Solution process area for more information about detailed development of operational concepts that are dependent on the selected designs. A scenario is 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. For example, the operational concept for a satellite-based communications product is quite different from one based on landlines. Since the alternative solutions have not usually been defined when preparing the initial operational concepts, conceptual solutions are developed for use when analyzing the requirements. The operational concepts are refined as solution decisions are made and lower level detailed requirements are developed. Just as a design decision for a product may become a requirement for product components, the operational concept may become the scenarios (requirements) for product components. The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts. Typical Work Products
Subpractices
SP 3.2-1 Establish a Definition of Required FunctionalityEstablish and maintain 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. 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. (See the definition of "functional architecture" in the glossary.) Typical Work Products
Subpractices
SP 3.3-1 Analyze RequirementsAnalyze requirements to ensure that they are necessary and sufficient. In light of the operational concept and scenarios, the requirements for one level of the product hierarchy are analyzed to determine whether they are necessary and sufficient to meet the objectives of higher levels of the product hierarchy. The analyzed requirements then provide the basis for more detailed and precise requirements for lower levels of the product hierarchy. As requirements are defined, their relationship to higher level requirements and the higher level defined functionality must be understood. One of the other actions is the determination of which key requirements will be used to track technical progress. For instance, the weight of a product or size of a software product may be monitored through development based on its risk. Typical Work Products
Subpractices
SP 3.4-3 Analyze Requirements to Achieve BalanceAnalyze requirements to balance stakeholder needs and constraints. Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk. Typical Work Products
Subpractices
The following specific practice is subsumed in the staged representation by SP 3.5-2, Validate Requirements with Comprehensive Methods. SP 3.5-1 Validate RequirementsValidate requirements to ensure the resulting product will perform appropriately in its intended-use environment. Typical Work Products
Subpractices
SP 3.5-2 Validate Requirements with Comprehensive MethodsValidate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate. Requirements validation is performed early in the development effort to gain confidence that the requirements are capable of guiding a development that results in successful final validation. This activity should be integrated with risk management activities. Mature organizations will typically perform requirements validation in a more sophisticated way and will broaden the basis of the validation to include other stakeholder needs and expectations. These organizations will typically perform analyses, simulations, or prototypes to ensure that requirements will satisfy stakeholder needs and expectations. Typical Work Products
Subpractices
|