Analyze and Validate Requirements
The 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 timecritical 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 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 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
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
1. Operational concept
2. Product installation, operational, maintenance, and support concepts
3. Disposal concepts
4. Use cases
5. Timeline scenarios
6. New requirements
Subpractices
1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate.
Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints, in which the proposed product is expected to operate.
2. Define the environment the product will operate in, including boundaries and constraints.
3. Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. The reviews should be held periodically to ensure that they agree with the requirements. The review may be in the form of a walkthrough.
4. Develop a detailed operational concept, as products and product components are selected, that defines the interaction of the product, the end user, and the environment, and that satisfies the operational, maintenance, support, and disposal needs.
SP 3.2 Establish a Definition of Required Functionality
Establish 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.
Typical Work Products
1. Functional architecture
2. Activity diagrams and use cases
3. Object-oriented analysis with services identified
Subpractices
1. Analyze and quantify functionality required by end users.
2. Analyze requirements to identify logical or functional partitions (e.g., subfunctions).
3. Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis.
4. Consider the sequencing of time-critical functions both initially and subsequently during product-component development.
5. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions.
6. Allocate functional and performance requirements to functions and subfunctions.
SP 3.3 Analyze Requirements
Analyze 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
1. Requirements defects reports
2. Proposed requirements changes to resolve defects
3. Key requirements
4. Technical performance measures
Subpractices
1. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects.
2. Analyze requirements to determine whether they satisfy the objectives of higher level requirements.
3. Analyze requirements to ensure that they are complete, feasible,realizable, and verifiable.
While design determines the feasibility of a particular solution, this subpractice
addresses knowing which requirements affect feasibility.
4. Identify key requirements that have a strong influence on cost,schedule, functionality, risk, or performance.
5. Identify technical performance measures that will be tracked during the development effort.
6. Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.
This analysis may result in more detailed operational concepts and scenarios as well as supporting the derivation of new requirements.
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.
Typical Work Products
1. Assessment of risks related to requirements
Subpractices
1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints. Results of the analyses can be used to reduce the cost of the product and the risk in developing the product.
2. Perform a risk assessment on the requirements and functional architecture.
3. Examine product life-cycle concepts for impacts of requirements on risks.
SP 3.5 Validate Requirements with Comprehensive Methods
Validate 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
1. Record of analysis methods and results
Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations,models, scenarios, and storyboards) and by obtaining feedback about them from relevant stakeholders.
3. Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements.
The following specific practice appears in the continuous representation as SP 3.5-1, but is subsumed in the staged representation by SP 3.5, Validate Requirements with Comprehensive Methods. The specific practice is presented here in gray only as informative material.
SP 3.5-1 Validate Requirements
Validate requirements to ensure the resulting product will perform appropriately in its intended-use environment.
Typical Work Products
1. Results of requirements validation
Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
