Requirements Development (RD) Category: Engineering
Notes:
·
The contents of this web page were extracted from
the following document: Capability Maturity Model® Integration
(CMMISM), Version 1.1, Continuous Representation,
CMU/SEI-2002-TR-011, March 2002 (CMMI-SE/SW/IPPD/SS). Copyright 2002 by Carnegie
Mellon University. NO WARRANTY.
·
Ignore the identifiers
in square brackets that appear at the end of paragraphs.
·
The formatting may not
be the same as in the printed CMMI document. The web page is best viewed in
Internet Explorer.
·
In the CMMI, a subset is known as a "Process Area
(PA)" and a requirement is known as a "Practice". The specific practices are
referred to as SPs and the generic practices are referred to as GPs.
·
This web page contains the text for SPs and GPs as
it appears in Chapter 7 of the CMMI document, in the section corresponding to
the process area named in the heading of this page. This web page does not
include the detailed description of the GPs that appears in a separate chapter
of the CMMI document; the
detailed description of the GPs is available in a separate web
page. (Note: Using the hyperlink provided here will open that web page in a
separate window.)
Purpose The purpose of Requirements Development is to produce and
analyze customer, product, and product-component requirements. [PA157]
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). [PA157.N101]
Requirements are the basis for design. The development of
requirements includes the following activities:
[PA157.N102]
· 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. [PA157.N103]
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. [PA157.N104]
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. [PA157.N105]
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. [PA157.N111]
Analyses are used to understand, define, and select the
requirements at all levels from competing alternatives. These analyses include
the following: [PA157.N106]
· 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.” [PA157.N107]
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: [PA157.N108]
· Constraints of various types
· Technological limitations
· Cost and cost drivers
· 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 sub-functions, 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. [PA157.N109]
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. [PA157.N110]
Refer to the Requirements Management process area for more information
about managing customer and product requirements, obtaining agreement with the
requirements provider, obtaining commitments with those implementing the
requirements, and maintaining traceability. [PA157.R101]
Refer to the Technical Solution process area for more information about how
the outputs of the requirements development processes are used, and the
development of alternative solutions and designs used in refining and deriving
requirements. [PA157.R102]
Refer to the Product Integration process area for more information about
interface requirements and interface management. [PA157.R103]
Refer to the Verification process area for more information about verifying
that the resulting product meets the requirements.
[PA157.R104]
Refer to the Validation process area for more information about how the
product built will be validated against the customer needs.
[PA157.R105]
Refer to the Risk Management process area for more information about
identifying and managing risks that are related to requirements.
[PA157.R106]
Refer to the Configuration Management process area for information about
ensuring that key work products are controlled and managed.
[PA157.R107]
Specific Goals
SG 1
Develop Customer Requirements [PA157.IG101]
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
SG 2
Develop Product Requirements [PA157.IG103]
Customer requirements are refined and elaborated to develop product and product-component requirements.
SG 3
Analyze and Validate Requirements [PA157.IG102]
The requirements are analyzed and validated, and a definition of required functionality is developed.
Generic Goals
GG 1
Achieve Specific Goals [CL102.GL101]
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GG 2
Institutionalize a Managed Process [CL103.GL101]
The process is institutionalized as a managed process.
GG 3
Institutionalize a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GG 4
Institutionalize a Quantitatively Managed Process
[CL105.GL101]
The process is institutionalized as a quantitatively managed process.
GG 5
Institutionalize an Optimizing Process [CL106.GL101]
The process is institutionalized as an optimizing process.
Practice-to-Goal Relationship Table
SG 1 Develop Customer Requirements
[PA157.IG101]
SP 1.1-1 Collect Stakeholder Needs
SP 1.1-2 Elicit Needs
SP 1.2-1 Develop the Customer Requirements
SG 2 Develop Product Requirements
[PA157.IG103]
SP 2.1-1 Establish Product and Product-Component Requirements
SP 2.2-1 Allocate Product-Component Requirements
SP 2.3-1 Identify Interface Requirements
SG 3 Analyze and Validate Requirements [PA157.IG102]
SP 3.1-1 Establish Operational Concepts and Scenarios
SP 3.2-1 Establish a Definition of Required Functionality
SP 3.3-1 Analyze Requirements
SP 3.4-3 Analyze Requirements to Achieve Balance
SP 3.5-1 Validate Requirements
SP 3.5-2 Validate Requirements with Comprehensive Methods
GG 1 Achieve Specific Goals [CL102.GL101]
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process [CL103.GL101]
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process [CL104.GL101]
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]
GP 4.1 Establish Quantitative Objectives for the Process
GP 4.2 Stabilize Subprocess Performance
GG 5 Institutionalize an Optimizing Process [CL106.GL101]
GP 5.1 Ensure Continuous Process Improvement
GP 5.2 Correct Root Causes of Problems
Specific Practices by Goal
SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and
translated into customer requirements. [PA157.IG101]
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. [PA157.IG101.N101]
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.
[PA157.IG101.N102]
SP 1.1-1 Collect Stakeholder Needs
Identify and collect stakeholder needs, expectations, constraints, and
interfaces for all phases of the product life cycle.
[PA157.IG101.SP101]
In the staged representation, this
specific practice is only included as informative material and appears after the
Elicit Needs specific practice.
The basic activity 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. [PA157.IG101.SP101.N101]
Elicit stakeholder needs, expectations, constraints, and interfaces for all
phases of the product life cycle.
[PA157.IG101.SP102]
In the staged representation, this
specific practice takes the place of the Collect Stakeholder Needs specific
practice.
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. [PA157.IG101.SP102.N102]
Examples of
techniques to elicit needs include the following: [PA157.IG101.SP102.N103]
· Technology demonstrations
· Interface control working groups
· Technical control working groups
· Interim project reviews
· Questionnaires, interviews, and operational scenarios obtained from end users
· Operational walkthroughs and end-user task analysis
· Prototypes and models
· Brainstorming
· Quality Function Deployment
· Market surveys
· Beta testing
· Extraction from sources such as documents, standards, or specifications
· Observation of existing products, environments, and workflow patterns
· Use cases
· Business case analysis
· Reverse engineering (for legacy products)
Subpractices
1. Engage relevant stakeholders
using methods for eliciting needs, expectations, constraints, and external
interfaces. [PA157.IG101.SP102.SubP101]
SP 1.2-1 Develop the Customer Requirements
Transform stakeholder needs, expectations, constraints, and interfaces into
customer requirements. [PA157.IG101.SP103]
For Integrated Product and Process Development
Relevant stakeholders representing all phases of the product’s life cycle should include business as well as technical functions. In this way, concepts for all product-related life-cycle processes are considered concurrently with the concepts for the products. Customer requirements result from informed decisions on the business as well as technical effects of their requirements. [PA157.IG101.SP103.AMP101]
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.
[PA157.IG101.SP103.N101]
Typical Work Products
1. Customer
requirements [PA157.IG101.SP103.W101]
2. Customer
constraints on the conduct of verification [PA157.IG101.SP103.W102]
3. Customer
constraints on the conduct of validation [PA157.IG101.SP103.W103]
Subpractices
1. Translate the stakeholder
needs, expectations, constraints, and interfaces into documented customer
requirements. [PA157.IG101.SP103.SubP101]
2. Define constraints for
verification and validation. [PA157.IG101.SP103.SubP102]
SG 2 Develop Product Requirements
Customer requirements are refined and elaborated to develop product and
product-component requirements. [PA157.IG103]
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. [PA157.IG103.N101]
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. [PA157.IG103.N102]
Refer to the Maintain Bidirectional Traceability of Requirements specific
practice of the Requirements Management process area for more information about
maintaining bidirectional traceability.
[PA157.IG103.N102.R101]
SP 2.1-1 Establish Product and Product-Component Requirements
Establish and maintain product and product-component requirements, which are
based on the customer requirements. [PA157.IG103.SP101]
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. [PA157.IG103.SP101.N101]
Product and product-component requirements address the
satisfaction of customer, business, and project objectives and associated
attributes, such as effectiveness and affordability. [PA157.IG103.SP101.N104]
Design constraints include specifications on product
components that are derived from design decisions, rather than higher level
requirements.
[PA157.IG103.SP101.N102]
For Software Engineering
For example, application components that must interface with an off-the-shelf database component must comply with interface requirements imposed by the selected database. Such product-component requirements are generally not traceable to higher level requirements. [PA157.IG103.SP101.N102.AMP101]
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. [PA157.IG103.SP101.N103]
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.
[PA157.IG103.SP101.N105]
Refer to the Requirements Management process area for more information
about managing changes to requirements.
[PA157.IG103.SP101.N105.R101]
Typical Work Products
1. Derived
requirements [PA157.IG103.SP101.W101]
2. Product
requirements [PA157.IG103.SP101.W102]
3.
Product-component requirements [PA157.IG103.SP101.W103]
Subpractices
1. Develop requirements in
technical terms necessary for product and product-component design.
[PA157.IG103.SP101.SubP101]
Develop architecture requirements
addressing critical product qualities and performance necessary for product
architecture design.
[PA157.IG103.SP101.SubP101.N101]
2. Derive requirements that
result from design decisions. [PA157.IG103.SP101.SubP102]
Refer to the Technical Solution process area for more information about
developing the solutions that generate additional derived requirements. [PA157.IG103.SP101.SubP102.R101]
Selection of a technology brings
with it additional requirements. For instance, use of electronics requires
additional technology-specific requirements such as electromagnetic interference
limits.
[PA157.IG103.SP101.SubP102.N101]
3. Establish and maintain
relationships between requirements for consideration during change management
and requirements allocation. [PA157.IG103.SP101.SubP103]
Refer to the Requirements Management process area for more information about
maintaining requirements traceability.
[PA157.IG103.SP101.SubP103.R101]
Relationships between requirements
can aid in evaluating the impact of changes.
[PA157.IG103.SP101.SubP103.N101]
SP 2.2-1 Allocate Product-Component Requirements
Allocate the requirements for each product component.
[PA157.IG103.SP102]
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.
[PA157.IG103.SP102.R101]
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.
[PA157.IG103.SP102.N101]
Typical Work Products
1. Requirement
allocation sheets [PA157.IG103.SP102.W101]
2. Provisional
requirement allocations [PA157.IG103.SP102.W102]
3. Design
constraints [PA157.IG103.SP102.W103]
4. Derived
requirements [PA157.IG103.SP102.W104]
5. Relationships
among derived requirements [PA157.IG103.SP102.W105]
Subpractices
1. Allocate requirements to
functions. [PA157.IG103.SP102.SubP101]
2. Allocate requirements to
product components. [PA157.IG103.SP102.SubP102]
3. Allocate design constraints to
product components. [PA157.IG103.SP102.SubP103]
4. Document relationships among
allocated requirements. [PA157.IG103.SP102.SubP104]
Relationships include dependencies
in which a change in one requirement may affect other requirements.
[PA157.IG103.SP102.SubP104.N101]
SP 2.3-1 Identify Interface Requirements
Identify interface requirements.
[PA157.IG103.SP103]
Interfaces between functions (or between objects) are
identified. Functional interfaces may drive the development of alternative
solutions described in the Technical Solution process area. [PA157.IG103.SP103.N101]
Refer to the Product Integration process area for more information about
the management of interfaces and the integration of products and product
components. [PA157.IG103.SP103.N101.R101]
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.
[PA157.IG103.SP103.N102]
Typical Work Products
1. Interface
requirements [PA157.IG103.SP103.W101]
Subpractices
1. Identify interfaces both
external to the product and internal to the product (i.e., between functional
partitions or objects). [PA157.IG103.SP103.SubP101]
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.
[PA157.IG103.SP103.SubP101.N101]
Interfaces with product-related
life-cycle processes should also be identified. [PA157.IG103.SP103.SubP101.N102]
Examples of these interfaces include interfaces with test equipment,
transportation systems, support systems, and manufacturing facilities.
[PA157.IG103.SP103.SubP101.N103]
2. Develop the requirements for
the identified interfaces. [PA157.IG103.SP103.SubP102]
Refer to the Technical Solution process area for more information about
generating new interfaces during the design process.
[PA157.IG103.SP103.SubP102.R101]
Requirements for interfaces are
defined in terms of origination, destination, stimulus, data characteristics for
software, and electrical and mechanical characteristics for hardware.
[PA157.IG103.SP103.SubP102.N102]
SG 3 Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required
functionality is developed.
[PA157.IG102]
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.
[PA157.IG102.N104]
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. [PA157.IG102.N101]
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.
[PA157.IG102.N102]
Requirements are validated to increase the probability
that the resulting product will perform as intended in the use environment. [PA157.IG102.N103]
SP 3.1-1 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios. [PA157.IG102.SP101]
Refer to the Technical Solution process area for more information about
detailed development of operational concepts that are dependent on the selected
designs. [PA157.IG102.SP101.R101]
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.
[PA157.IG102.SP101.N101]
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.
[PA157.IG102.SP101.N102]
The scenarios may include operational sequences, provided
those sequences are an expression of customer requirements rather than
operational concepts.
[PA157.IG102.SP101.N103]
Typical Work Products
1. Operational
concept [PA157.IG102.SP101.W101]
2. Product
installation, operational, maintenance, and support concepts
[PA157.IG102.SP101.W102]
3. Disposal
concepts [PA157.IG102.SP101.W103]
4. Use cases [PA157.IG102.SP101.W104]
5. Timeline
scenarios [PA157.IG102.SP101.W105]
6. New
requirements [PA157.IG102.SP101.W106]
Subpractices
1. Develop operational concepts
and scenarios that include functionality, performance, maintenance, support, and
disposal as appropriate. [PA157.IG102.SP101.SubP101]
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.
[PA157.IG102.SP101.SubP101.N101]
2. Define the environment the
product will operate in, including boundaries and constraints.
[PA157.IG102.SP101.SubP102]
3. Review operational concepts
and scenarios to refine and discover requirements.
[PA157.IG102.SP101.SubP103]
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.
[PA157.IG102.SP101.SubP103.N101]
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.
[PA157.IG102.SP101.SubP104]
SP 3.2-1 Establish a Definition of Required Functionality
Establish and maintain a definition of required functionality. [PA157.IG102.SP102]
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.
[PA157.IG102.SP102.N101]
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 Appendix C, the glossary. [PA157.IG102.SP102.N102]
Typical Work Products
1. Functional
architecture [PA157.IG102.SP102.W101]
2. Activity
diagrams and use cases [PA157.IG102.SP102.W102]
3.
Object-oriented analysis with services identified [PA157.IG102.SP102.W103]
Subpractices
1. Analyze and quantify
functionality required by end users. [PA157.IG102.SP102.SubP101]
2. Analyze requirements to
identify logical or functional partitions (e.g., subfunctions).
[PA157.IG102.SP102.SubP102]
3. Partition requirements into
groups, based on established criteria (e.g., similar functionality, performance,
or coupling), to facilitate and focus the requirements analysis.
[PA157.IG102.SP102.SubP103]
4. Consider the sequencing of
time-critical functions both initially and subsequently during product-component
development. [PA157.IG102.SP102.SubP104]
5. Allocate customer requirements
to functional partitions, objects, people, or support elements to support the
synthesis of solutions. [PA157.IG102.SP102.SubP105]
6. Allocate functional and
performance requirements to functions and subfunctions.
[PA157.IG102.SP102.SubP106]
Analyze requirements to ensure that they are necessary and sufficient. [PA157.IG102.SP103]
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.
[PA157.IG102.SP103.N102]
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.
[PA157.IG102.SP103.N101]
Typical Work Products
1. Requirements
defects reports [PA157.IG102.SP103.W101]
2. Proposed
requirements changes to resolve defects [PA157.IG102.SP103.W102]
3. Key
requirements [PA157.IG102.SP103.W103]
4. Technical
performance measures [PA157.IG102.SP103.W104]
Subpractices
1. Analyze stakeholder needs,
expectations, constraints, and external interfaces to remove conflicts and to
organize into related subjects. [PA157.IG102.SP103.SubP101]
2. Analyze requirements to
determine whether they satisfy the objectives of higher level requirements. [PA157.IG102.SP103.SubP102]
3. Analyze requirements to ensure
that they are complete, feasible, realizable, and verifiable.
[PA157.IG102.SP103.SubP103]
While design determines the
feasibility of a particular solution, this subpractice addresses knowing which
requirements affect feasibility.
[PA157.IG102.SP103.SubP103.N101]
4. Identify key requirements that
have a strong influence on cost, schedule, functionality, risk, or performance. [PA157.IG102.SP103.SubP104]
5. Identify technical performance
measures that will be tracked during the development effort.
[PA157.IG102.SP103.SubP105]
Refer to the Measurement and Analysis process area for more information about
the use of measurements. [PA157.IG102.SP103.SubP105.R101]
6. Analyze operational concepts
and scenarios to refine the customer needs, constraints, and interfaces and to
discover new requirements. [PA157.IG102.SP103.SubP106]
This analysis may result in more
detailed operational concepts and scenarios as well as supporting the derivation
of new requirements.
[PA157.IG102.SP103.SubP106.N101]
SP 3.4-3 Analyze Requirements to Achieve Balance
Analyze requirements to balance stakeholder needs and constraints. [PA157.IG102.SP104]
Stakeholder needs and constraints can address cost,
schedule, performance, functionality, reusable components, maintainability, or
risk. [PA157.IG102.SP104.N102]
Typical Work Products
1. Assessment of
risks related to requirements [PA157.IG102.SP104.W101]
Subpractices
1. Use proven models,
simulations, and prototyping to analyze the balance of stakeholder needs and
constraints. [PA157.IG102.SP104.SubP103]
Results of the analyses can be
used to reduce the cost of the product and the risk in developing the product.
[PA157.IG102.SP104.SubP103.N101]
2. Perform a risk assessment on
the requirements and functional architecture.
[PA157.IG102.SP104.SubP101]
Refer to the Risk Management process area for information about performing a
risk assessment on customer and product requirements and the functional
architecture. [PA157.IG102.SP104.SubP101.R101]
3. Examine product life-cycle
concepts for impacts of requirements on risks.
[PA157.IG102.SP104.SubP102]
SP 3.5-1 Validate Requirements
Validate requirements to ensure the resulting product will perform appropriately
in its intended-use environment.
[PA157.IG102.SP105]
In the staged representation, this
specific practice is only included as informative material and appears after the
Validate Requirements with Comprehensive Methods specific practice.
Typical Work Products
1. Results of
requirements validation [PA157.IG102.SP105.W101]
Subpractices
1. Analyze the requirements to
determine the risk that the resulting product will not perform appropriately in
its intended-use environment. [PA157.IG102.SP105.SubP101]
SP 3.5-2 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. [PA157.IG102.SP106]
In the staged representation, this
specific practice takes the place of the Validate Requirements specific
practice.
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.
[PA157.IG102.SP106.N102]
Typical Work Products
1. Record of
analysis methods and results [PA157.IG102.SP106.W101]
Subpractices
1. Analyze the requirements to
determine the risk that the resulting product will not perform appropriately in
its intended-use environment. [PA157.IG102.SP106.SubP101]
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. [PA157.IG102.SP106.SubP102]
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. [PA157.IG102.SP106.SubP103]
Generic Practices by Goal
(Note: The detailed description of the GPs is available in a separate web page. Using the hyperlink provided here will open that web page in a separate window. However, the GP elaborations pertinent to the process area of this web page are available below.)
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
Perform the base practices of the requirements development process to develop
work products and provide services to achieve the specific goals of the process
area. [GP102]
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the
requirements development process. [GP103]
Elaboration:
This policy establishes organizational expectations for
collecting stakeholder needs, formulating product and product-component
requirements, and analyzing and validating those requirements. [PA157.EL101]
Establish and maintain the plan for performing the requirements development
process. [GP104]
Elaboration:
Typically, this plan for performing the requirements
development process is a part of the project plan as described in the Project
Planning process area.
[PA157.EL102]
Provide adequate resources for performing the requirements development process,
developing the work products, and providing the services of the process. [GP105]
Elaboration:
Special expertise in the application domain, methods for
eliciting stakeholder needs, and methods and tools for specifying and analyzing
customer, product, and product-component requirements may be required. [PA157.EL103]
Examples of
other resources provided include the following tools: [PA157.EL104]
· Requirements specification tools
· Simulators and modeling tools
· Prototyping tools
· Scenario definition and management tools
· Requirements tracking tools
Assign responsibility and authority for performing the process, developing the
work products, and providing the services of the requirements development
process. [GP106]
Train the people performing or supporting the requirements development process
as needed. [GP107]
Elaboration:
Examples of
training topics include the following: [PA157.EL105]
· Application domain
· Requirements definition and analysis
· Requirements elicitation
· Requirements specification and modeling
· Requirements tracking
Place designated work products of the requirements development process under
appropriate levels of configuration management.
[GP109]
Elaboration:
Examples of
work products placed under configuration management include the following: [PA157.EL106]
· Customer requirements
· Functional architecture
· Product and product-component requirements
· Interface requirements
GP 2.7 Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the requirements development
process as planned. [GP124]
Elaboration:
Select relevant stakeholders from customers, end users,
developers, producers, testers, suppliers, marketers, maintainers, disposal
personnel, and others who may be affected by, or may affect, the product as well
as the process.
[PA157.EL113]
Examples of
activities for stakeholder involvement include the following: [PA157.EL114]
· Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
· Establishing operational concepts and scenarios
· Assessing the adequacy of requirements
· Establishing product and product-component requirements
· Assessing product cost, schedule, and risk
GP 2.8 Monitor and Control the Process
Monitor and control the requirements development process against the plan for
performing the process and take appropriate corrective action. [GP110]
Elaboration:
Examples of
measures used in monitoring and controlling include the following: [PA157.EL110]
· Cost, schedule, and effort expended for rework
· Defect density of requirements specifications
GP 2.9 Objectively Evaluate Adherence
Objectively evaluate adherence of the requirements development process against
its process description, standards, and procedures, and address noncompliance. [GP113]
Elaboration:
Examples of
activities reviewed include the following: [PA157.EL111]
· Collecting stakeholder needs
· Formulating product and product-component requirements
· Analyzing and validating product and product-component requirements
Examples of
work products reviewed include the following: [PA157.EL112]
· Product requirements
· Product-component requirements
· Interface requirements
· Functional architecture
GP 2.10 Review Status with Higher Level Management
Review the activities, status, and results of the requirements development
process with higher level management and resolve issues.
[GP112]
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined requirements development
process. [GP114]
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement
information derived from planning and performing the requirements development
process to support the future use and improvement of the organization’s
processes and process assets. [GP117]
GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish and maintain quantitative objectives for the requirements development
process that address quality and process performance based on customer needs and
business objectives. [GP118]
GP 4.2 Stabilize Subprocess Performance
Stabilize the performance of one or more subprocesses to determine the ability
of the requirements development process to achieve the established quantitative
quality and process-performance objectives.
[GP119]
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure continuous improvement of the requirements development process in
fulfilling the relevant business objectives of the organization. [GP125]
GP 5.2 Correct Root Causes of Problems
Identify and correct the root causes of defects and other problems in the
requirements development process. [GP121]