|Requirements Development (RD)||
|The CMMi easy button concept and disclaimer
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
The concept of The CMMi easy button is to be able to
jump start SQA software professionals in establishing an
effective Software process Improvement (SPI) framework that is based on CMMi theories and best practices.
CMMI, CMM, and Capability Maturity Model are registered
in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.
|Causal Analysis and Resolution (CAR)||Configuration Management (CM)||Decision Analysis and Resolution (DAR)|
|Integrated Project Management +IPPD (IPM+IPPD)||Measurement and Analysis (MA)||Organizational Innovation and Deployment (OID)|
|Organizational Process Definition +IPPD (OPD+IPPD)||Organizational Process Focus (OPF)||Organizational Process Performance (OPP)|
|Organizational Training (OT)||Product Integration (PI)||Project Monitoring and Control (PMC)|
|Project Planning (PP)||Process and Product Quality Assurance (PPQA)||Quantitative Project Management (QPM)|
|Requirements Development (RD)||Requirements Management (REQM)||Risk Management (RSKM)|
|Supplier Agreement Management (SAM)||Technical Solution (TS)||Validation (VAL)|
|The CMMi Easy button notes on Requirements Development (RD)||Requirements Development (RD) purpose and introductory notes|
|Specific Goals and Practices|
|Specific Goal 1 (SG 1) Develop Customer Requirements (SP 1.*)|
|SP 1.1 Elicit Needs||SP 1.2 Develop the Customer Requirements||.||.|
|Specific Goal 2 (SG 2) Develop Product Requirements (SP 2.*)|
|SP 2.1 Establish Product and Product Component Requirements||SP 2.2 Allocate Product Component Requirements||SP 2.3 Identify Interface Requirements||.|
|Specific Goal 3 (SG 3) Analyze and Validate Requirements (SP 3.*)|
|SP 3.1 Establish Operational Concepts and Scenarios||SP 3.2 Establish a Definition of Required Functionality||SP 3.3 Analyze Requirements||SP 3.4 Analyze Requirements to Achieve Balance|
|SP 3.5 Validate Requirements||.||.||.|
|Generic Goals and Practices|
|Generic Goal 1 (GG 1) Achieve Specific Goals, Generic Practices (GP 1.*)|
|GP 1.1 Perform Specific Practices||.||.||.|
|Generic Goal 2 (GG 2) Institutionalize a Managed Process, Generic Practices (GP 2.*)|
|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||.||.|
|Generic Goal 3 (GG 3) Institutionalize a Defined Process, Generic Practices (GP 3.*)|
|GP 3.1 Establish a Defined Process||GP 3.2 Collect Improvement Information||.||.|
|Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process, Generic Practices (GP 4.*)|
|GP 4.1 Establish Quantitative Objectives for the Process||GP 4.2 Stabilize Subprocess Performance||.||.|
|Generic Goal 5 (GG 5) Institutionalize an Optimizing Process, Generic Practices (GP 5.*)|
|GP 5.1 Ensure Continuous Process Improvement||GP 5.2 Correct Root Causes of Problems||.||.|
The CMMi Easy button notes on Requirements Development (RD) Process Area
One of the main issues for making the requirements that the customer (end user) really wants visible to the developer, in a format that both the technical developer and business user agree, is the level and form of abstraction of the system functionality description.
In general the business user will want to use natural language terms to describe what is required whilst the developer will want a more logical structure to precisely describe the intention of the requestor. Many notations and strategies have evolved to try and bridge the communication gap between business and developer,
one of the most popular requirements (and systems) modeling formats is the Unified Modeling Language UML.
Under UML the following diagrams are used to convey the requirements:-
Requirements Development (RD)
An Engineering Process Area at Maturity Level 3
The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
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). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).
All development projects have requirements. In the case of a project that is focused on maintenance activities, the changes to the product or product components are based on changes to the existing requirements, design, or implementation. The requirements changes, if any, might be documented in change requests from the customer or users, or they might take the form of new requirements received from the requirements development process. Regardless of their source or form, the maintenance activities that are driven by changes to requirements are managed accordingly.
Requirements are the basis for design. The development of requirements includes the following activities:
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. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.
Requirements are identified and refined throughout the phases of the product lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s lifecycle are analyzed for impact on derived and allocated requirements.
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.
Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:
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:
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.
Related Process Areas
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.
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.
Refer to the Product Integration process area for more information about interface requirements and interface management.
Refer to the Verification process area for more information about verifying that the resulting product meets the requirements.
Refer to the Validation process area for more information about how the product built will be validated against the customer needs.
Refer to the Risk Management process area for more information about identifying and managing risks that are related to requirements.
Refer to the Configuration Management process area for information about ensuring that key work products are controlled and managed.
Specific Practices by Goal
SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
The needs of stakeholders (e.g., customers, end users, suppliers, builders, testers, manufacturers, and logistics support personnel) 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.
SP 1.1 Elicit Needs
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
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.
Examples of techniques to elicit needs include the following:
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.
In some situations, the customer provides a set of requirements to the project, or the requirements exist as an output of a previous project's activities. In these situations, the customer requirements could conflict with the relevant stakeholders' needs, expectations, constraints, and interfaces and will need to be transformed into the recognized set of customer requirements after appropriate resolution of conflicts.
Relevant stakeholders representing all phases of the product's lifecycle should include business as well as technical functions. In this way, concepts for all product-related lifecycle 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.
Typical Work Products
Subpractice 2: Define constraints for verification and validation.
SG 2 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 lifecycle 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 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 Function 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.
Derived requirements also address the cost and performance of other lifecycle 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
Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design.
Subpractice 2: Derive requirements that result from design decisions.
Refer to the Technical Solution process area for more information about developing the solutions that generate additional derived requirements.
Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits.
Subpractice 3: Establish and maintain relationships between requirements for consideration during change management and requirements allocation.
Refer to the Requirements Management process area for more information about maintaining requirements traceability.
Relationships between requirements can aid in evaluating the impact of changes.
SP 2.2 Allocate Product Component Requirements
Allocate 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
Subpractice 2: Allocate requirements to product components.
Subpractice 3: Allocate design constraints to product components.
Subpractice 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.
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
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 lifecycle processes should also be identified.
Examples of these interfaces include interfaces with test equipment, transportation systems, support systems, and manufacturing facilities.
Subpractice 2: Develop the requirements for the identified interfaces.
Refer to the Technical Solution process area for more information about generating new interfaces during the design process.
Requirements for interfaces are defined in terms such as origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
SG 3 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 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 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated 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. 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. Operational concepts and scenarios are evolved to facilitate the selection of product component solutions that, when implemented, will satisfy the intended use of the product. Operational concepts and scenarios document the interaction of the product components with the environment, users, and other product components, regardless of engineering discipline. They should be documented for all modes and states within operations, product deployment, delivery, support (including maintenance and sustainment), training, and disposal.
The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts.
Typical Work Products
Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints in which the proposed product or product component is expected to operate.
Subpractice 2: Define the environment in which the product or product component will operate, including boundaries and constraints.
Subpractice 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.
Subpractice 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 what are called “services” or “methods.” 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
Subpractice 2: Analyze requirements to identify logical or functional partitions (e.g., subfunctions).
Subpractice 3: Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis.
Subpractice 4: Consider the sequencing of time-critical functions both initially and subsequently during product component development.
Subpractice 5: Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions.
Subpractice 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 progress. For instance, the weight of a product or size of a software product may be monitored through development based on its risk.
Refer to the Verification process area for more information about verification methods that could be used to support this analysis.
Typical Work Products
Subpractice: 2 Analyze requirements to determine whether they satisfy the objectives of higher level requirements.
Subpractice: 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.
Subpractice: 4 Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance.
Subpractice: 5 Identify technical performance measures that will be tracked during the development effort.
Refer to the Measurement and Analysis process area for more information about the use of measurements.
Subpractice: 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
Results of the analyses can be used to reduce the cost of the product and the risk in developing the product.
Subpractice 2: Perform a risk assessment on the requirements and functional architecture.
Refer to the Risk Management process area for information about performing a risk assessment on customer and product requirements and the functional architecture.
Subpractice 3: Examine product lifecycle concepts for impacts of requirements on risks.
SP 3.5 Validate Requirements
Validate requirements to ensure the resulting product will perform as intended in the user's environment.
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. This activity should be integrated with risk management activities. Mature organizations will typically perform requirements validation in a more sophisticated way using multiple techniques and will broaden the basis of the validation to include other stakeholder needs and expectations.
Examples of techniques used for requirements validation include the following:
Subpractice 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.
Refer to the Validation process area for information about preparing for and performing validation on products and product components.
Subpractice 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.
Generic Practices by Goal
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.
GP 1.1 Perform Specific Practices
Perform the specific practices of the requirements development process to develop work products and provide services to achieve the specific goals of the process area.
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.
This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product component requirements, and analyzing and validating those requirements.
GP 2.2 Plan the Process
Establish and maintain the plan for performing the requirements development process.
This plan for performing the requirements development process can be part of (or referenced by) the project plan as described in the Project Planning process area.
GP 2.3 Provide Resources
Provide adequate resources for performing the requirements development process, developing the work products, and providing the services of the process.
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.
Examples of other resources provided include the following tools:
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.
GP 2.5 Train People
Train the people performing or supporting the requirements development process as needed.
Examples of training topics include the following:
Place designated work products of the requirements development process under appropriate levels of control.
Examples of work products placed under control include the following:
Identify and involve the relevant stakeholders of the requirements development process as planned.
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.
Examples of activities for stakeholder involvement include the following:
Monitor and control the requirements development process against the plan for performing the process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Objectively evaluate adherence of the requirements development process against its process description, standards, and procedures, and address noncompliance.
Examples of activities reviewed include the following:
Review the activities, status, and results of the requirements development process with higher level management and resolve issues.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined requirements development process.
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.
Examples of work products, measures, measurement results, and improvement information include the following:
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, which address quality and process performance, based on customer needs and business objectives.
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.
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.
GP 5.2 Correct Root Causes of Problems
Identify and correct the root causes of defects and other problems in the requirements development process.
Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance.
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-