The purpose of Acquisition Requirements Development (ARD) is to develop and analyze customer and contractual requirements.
This process area describes two types of requirements: customer requirements, which address the needs of relevant stakeholders for which one or more products and services will be acquired, and contractual requirements, which are the requirements to be addressed through the acquirer’s relationship with suppliers and other appropriate organizations. Both sets of requirements must address needs relevant to later product lifecycle phases (e.g., operation, maintenance, support, and disposal) and key product attributes (e.g., safety, reliability, and maintainability).
Tip
Customer needs can prescribe particular solutions (e.g., a particular service-oriented architecture to facilitate interoperability) in addition to describing the problem to be solved.
In some acquisitions, the acquirer assumes the role of overall systems engineer, architect, or integrator for the product. In these acquisitions, the Requirements Development process area of CMMI-DEV should be used. Requirements Development in CMMI-DEV includes additional information helpful in these situations, including deriving and analyzing requirements at successively lower levels of product definition (e.g., establishing and maintaining product component requirements).
Hint
Significant changes to requirements may occur during different phases in the project lifecycle. It may be useful to think about your acquisition strategy differently (e.g., evolutionary or incremental approaches), especially if the project lifecycle is lengthy.
Requirements are the basis for the selection and design or configuration of the acquired product. The development of requirements includes the following activities:
• Elicitation, analysis, and validation of stakeholder needs, expectations, constraints, and interfaces to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
• Development of the lifecycle requirements of the product (e.g., development, maintenance, transition to operations, decommissioning)
• Establishment of contractual requirements consistent with customer requirements to a level of detail that is sufficient to be included in the solicitation package and supplier agreement
• Development of the operational concept
• Analysis of needs and requirements (for each product lifecycle phase), the operational environment, and factors that reflect overall customer and end user needs and expectations for attributes such as safety, security, and affordability
The requirements included in the solicitation package form the basis for evaluating proposals by suppliers and for further negotiations with suppliers and communication with the customer. The contractual requirements for the supplier are baselined in the supplier agreement.
Requirements are refined throughout the project lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the project’s lifecycle are analyzed for their impact on contractual requirements.
Requirements analyses aid understanding, defining, and selecting requirements at all levels from competing alternatives. Analyses occur recursively at successively more detailed levels until sufficient detail is available to produce contractual requirements and to further refine these, if necessary, while the supplier builds or configures the product.
Tip
As long as they continue to be maintained, requirements provide stakeholders a common understanding of the product or service as it evolves through the life of the acquisition project.
Involvement of relevant stakeholders in both requirements development and analyses gives them visibility into the evolution of requirements. Participation continually assures stakeholders that requirements are being properly defined.
The Acquisition Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses eliciting and defining a set of customer requirements. The Develop Contractual Requirements specific goal addresses defining contractual requirements that are based on customer requirements and are included in the solicitation package and supplier agreement. The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in the first two specific goals. The specific practices associated with this specific goal cover analyzing and validating requirements with respect to the acquirer’s intended environment.
Refer to the Requirements Management process area for more information about managing requirements and changes, obtaining agreement with the requirements provider, obtaining commitments with those implementing the requirements, and maintaining traceability.
Refer to the Solicitation and Supplier Agreement Development process area for more information about developing solicitation packages and supplier agreements.
Refer to the Acquisition Technical Management process area for more information about confirming that the resulting product meets contractual requirements.
Refer to the Acquisition Validation process area for more information about validating the acquired product or service against stakeholder needs, expectations, constraints, and interfaces.
Refer to the Risk Management process area for more information about identifying and managing risks that are related to requirements.
Specific Goal and Practice Summary
SG 1 Develop Customer Requirements
SP 1.1 Elicit Stakeholder Needs
SP 1.2 Develop and Prioritize Customer Requirements
SG 2 Develop Contractual Requirements
SP 2.1 Establish Contractual Requirements
SP 2.2 Allocate Contractual Requirements
SG 3 Analyze and Validate Requirements
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Analyze Requirements
SP 3.3 Analyze Requirements to Achieve Balance
SP 3.4 Validate Requirements
Tip
Stakeholder needs are rarely communicated fully in an official document. They are communicated in documentation, conversations, meetings, demonstrations, and so on. Therefore, this information must be translated into requirements that the project and the customer can agree to.
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
Stakeholders (e.g., customers, end users, suppliers, testers, integrators, maintainers, operators, supplier agreement management personnel, manufacturers, and logistics support personnel) are sources of requirements. Their needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
X-Ref
For help in facilitating the discovery of quality attributes, see “Quality Attribute Workshops, Third Edition,” at www.sei.cmu.edu/publications/documents/03.reports/03tr016.html.
Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since these needs, expectations, constraints, and interfaces must be clearly identified and understood throughout the project lifecycle, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, relevant stakeholders are frequently involved throughout the project lifecycle to communicate their needs, expectations, and constraints, and to help resolve conflicts. Environmental, legal, and other constraints should be considered when creating and evolving the set of requirements for acquiring products or services.
Hint
Rarely do customers know exactly what they want. Plan to use an iterative process to learn the requirements for the product or service to be acquired.
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
Eliciting goes beyond collecting needs by proactively identifying additional needs not explicitly provided by stakeholders. Relevant stakeholders who represent all phases of the product lifecycle in the acquirer’s intended environment should include business as well as technical functions. Using this approach, needs for all product-related lifecycle processes are considered concurrently with concepts for acquired products.
Tip
In the case of acquiring product lines or product families, SP 1.1 is sometimes implemented across the product line or product family. A special infrastructure project may establish core assets used in developing each product in the family. In such an organization, requirements come from the organization, the individual acquisition programs, and the core asset development project.
An analysis of business processes is a common source of stakeholder needs, expectations, constraints, and interfaces. Additional needs typically address project lifecycle activities and their impact on the product.
X-Ref
For more information on acquiring products and services in a product line environment, see “Acquisition Organizations and Product Lines” at www.sei.cmu.edu/productlines/acquisition.html.
Hint
Ask what the product must do and how it will behave. Also determine what is required to produce it (if it is a physical product), license it, install it, train end users, maintain it, migrate to new versions, support its use, retire it, and dispose of it.
Never underestimate the value of reviewing other sources of requirements. A large number of acquisition projects fail because one or more sources of requirements were not considered.
Typical Work Products
- Stakeholder needs, expectations, constraints, and interfaces
Subpractices
- Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces.
Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements.
The customer typically describes requirements as capabilities expressed in broad operational terms concerned with achieving a desired effect under specified standards and regulations. Customer requirements may also include needs, expectations, constraints, and interfaces with regard to verification and validation. Inputs from the customer and other stakeholders must be aligned to the organization’s strategy. Missing information must be obtained and conflicts must be resolved as customer requirements are developed and prioritized.
Customer requirements may also exist as an output of another project’s activities such as a previous project that delivered the initial capability.
- Prioritized customer requirements
- Customer constraints on the conduct of verification
- Customer constraints on the conduct of validation
Subpractices
- Translate stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
- Establish and maintain a prioritization of customer requirements.
Having prioritized customer requirements guides the acquirer in determining project scope and which requirements and requirements changes to include in supplier agreements. This prioritization ensures that requirements critical to the customer and other stakeholders are addressed quickly.
Determining priorities and resolving conflicts among them can be addressed when eliciting stakeholder needs, as described in the previous specific practice.
- Define constraints for verification and validation.
Customer requirements are refined and elaborated into contractual requirements.
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements, called contractual requirements, to be included in the solicitation package for potential suppliers and eventually in the supplier agreement. The level of detail of contractual requirements is based on the acquisition strategy and project characteristics.
Contractual requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by design constraints and supplier capabilities. Contractual requirements include both requirements documented in contracts between an acquirer and supplier and requirements addressed through formal agreements between the acquirer and other organizations (e.g., partners, subcontractors, government agencies, and internal organizational units). (See the definition of “contractual requirements” in the glossary.) Requirements are reexamined throughout the project lifecycle.
The requirements are allocated to supplier deliverables. The traceability across levels of requirements and supplier deliverables is documented.
Refer to the Maintain Bidirectional Traceability of Requirements specific practice of the Requirements Management process area for more information about maintaining bidirectional traceability.
Establish and maintain contractual requirements that are based on customer requirements.
Customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. Contractual requirements are the expression of these requirements in technical terms that can be used for design decisions.
Hint
Translating requirements (i.e., from customer to contractual) introduces opportunities for misinterpretation and risk. Spend extra time ensuring that the contractual requirements reflect the customer need.
In addition to technical requirements (e.g., requirements specifying interfaces with other products or applications, functional requirements and their validation, technical performance measures, and verification requirements such as product acceptance criteria), contractual requirements cover nontechnical stakeholder needs, expectations, constraints, and interfaces.
Tip
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 REQM process area.
Refer to the Requirements Management process area for more information about managing changes to requirements.
- External interface requirements
- Contractual requirements
- Contractual requirements priorities
Subpractices
- Develop functional and performance requirements necessary for the determination of alternative solutions and the development of the product by the supplier.
Priorities may be assigned to product requirements to provide a basis for future requirements tradeoffs should this become necessary. Acquirers may assign priorities using categories such as Essential, Important, or Desirable.
- Develop interface requirements of the acquired product to other products in the intended environment.
Requirements for interfaces are defined in terms of origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
- Develop design constraints necessary for the determination of alternative solutions and the development of the product by the supplier.
Design constraints express the qualities and technical performance that are critical to the success of the product in its intended operational environment. They account for customer requirements relative to product interoperability, implications from the use of commercial-off-the-shelf (COTS) products, safety, security, durability, and other mission-critical concerns.
Hint
Recognize that if multiple systems are being developed to provide the needed capability, the interfaces may change as the systems evolve.
To achieve high levels of reuse and interoperability, acquirers may establish common design constraints for products or product families that can be deployed in one or more domains. Alternatively, acquirers may accelerate the development of technical requirements and design constraints by reusing shared or common constraints or requirements and their associated test cases from previous acquisitions or leverage the supplier’s previous product developments.
- Develop requirements for verification and validation of the product to be developed by the supplier.
Requirements for verification and validation typically include types and coverage of testing and review to be carried out in the supplier’s and acquirer’s environments.
- Establish and maintain relationships among the requirements under consideration during change management and requirements allocation.
Relationships between requirements can affect evaluating the impact of requirements changes. Expected requirements volatility is a key factor in anticipating scope changes and supporting the acquirer’s selection of the appropriate acquisition type.
Tip
Sometimes an insignificant requirements change can greatly improve the merits of a COTS-based solution, especially with regard to cost and schedule risks. However, the use of COTS may constrain the overall solution’s performance and the support that can be offered later in the product’s life. A relationship with a vendor may need to be maintained.
- Identify nontechnical requirements.
Contractual requirements consist of both technical and nontechnical requirements. Examples of nontechnical requirements are listed in the example box in this specific practice.
- Establish and maintain a prioritization of contractual requirements.
Priority can be based on a combination of several factors that include customer desires, costs, time frame for when the capabilities are needed, and length of time to satisfy a particular requirement.
When cost estimates can be determined for contractual requirements, their priority and costs can be used to guide contract and budget negotiations and to determine which changes should be made to the contract.
Priority may also help when developing a release strategy (e.g., first release only addresses high-priority requirements; lower-priority requirements are deferred to a later release or maintenance phase).
Refer to the Project Planning process area for more information about establishing an acquisition strategy and estimating costs associated with requirements.
Tip
Sometimes a higher-level requirement specifies performance that is satisfied by multiple supplier deliverables or even across multiple supplier teams.
The allocation of a higher-level requirement to supplier deliverables is not necessarily fixed. Often, a provisional allocation of a higher-level requirement to a supplier is made, but is later revised to account for the unique or emerging capabilities of individual suppliers, teams, or new COTS products.
Allocate contractual requirements to supplier deliverables.
Contractual requirements are allocated, as appropriate, to supplier deliverables. The requirements for each supplier deliverable are documented. In some cases, technical requirements are allocated to third-party products that must be used by the supplier (e.g., COTS products).
Typical Work Products
- Requirement allocation sheets
Hint
Pay close attention to integration issues when you allocate contractual requirements to multiple suppliers. You unknowingly may end up as the product integrator.
Subpractices
- Allocate requirements to supplier deliverables.
- Allocate design constraints to supplier deliverables.
- Document relationships among allocated requirements and design constraints.
- Allocate requirements to suppliers.
In situations where multiple suppliers are involved in developing the technical solution, different products or product components may be allocated to different suppliers.
Requirements are analyzed and validated.
Analyses are performed to determine the impact the intended operational environment will have on the ability to satisfy stakeholder 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.
Tip
Requirements analyses examine requirements from different perspectives (e.g., feasibility, cost, and risk) and using different abstractions (e.g., functional, data flow, entity relationship, state diagrams, and temporal).
The objectives of these analyses are (1) to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, constraints, and interfaces and (2) to translate these concepts into requirements. In parallel with these activities, the parameters to be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept.
Hint
Identify technical performance measures and other measures that help in assessing or predicting performance, usability, cost, schedule, risk, and so forth. Use them to state contractual requirements, establish quality objectives, evaluate progress, manage risk, and conduct trade studies. They provide a data-driven approach to engineering the product.
Requirements are validated to increase the probability that the resulting product will perform as intended in the acquirer’s environment.
Establish and maintain operational concepts and associated scenarios.
Operational concepts or concepts of operations is an overall description of the problem to be solved in operational terms and the way in which the product to be acquired is intended to be used or operated, deployed, supported (including maintenance and sustainment), and disposed. The acquirer explicitly accounts for design constraints.
X-Ref
For more information about technical performance parameters, see “Using Capability Maturity Model Integration (CMMI) to Improve Earned Value Management” (www.sei.cmu.edu/publications/documents/02.reports/02tn016.html).
In contrast, an operational scenario is a description of a sequence of events that might occur in the use of the product to be acquired, and makes explicit some stakeholder needs. Typically, operational scenarios are derived from business process descriptions and operational concepts.
Operational concepts and scenarios can assist in the elicitation of needs and the analysis and refinement of requirements. Operational concepts and scenarios can be further refined as solution decisions are made and more detailed requirements are developed. They are evolved to facilitate the validation of technical solutions delivered by the supplier.
Hint
Think of an operational concept as a picture that portrays the product, end user, and other entities in the intended environment. Think of an operational scenario as a story describing a sequence of events and end-user and product interactions. An operational concept provides a context for developing or evaluating a set of scenarios.
Typical Work Products
- Operational, maintenance, support, and disposal concepts
- Use cases
- New requirements
Subpractices
- Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal, as appropriate.
- Define the environment in which the product will operate, including boundaries and constraints.
- Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. Reviews should be held periodically to ensure that the operational concepts and scenarios agree with the requirements. The review may be in the form of a walkthrough.
- Develop a detailed operational concept, as candidate solutions are identified and product and product component solutions are selected by the supplier, that defines the interaction of the product, the end user, and the environment, and that satisfies operational, maintenance, support, and disposal needs.
Tip
Operational concepts and scenarios are a way to demonstrate or bring to life what the requirements are trying to capture.
Analyze requirements to ensure they are necessary and sufficient.
As contractual requirements are defined, their relationship to customer requirements must be understood. In light of the operational concepts and scenarios, the contractual requirements are analyzed to determine whether they are necessary and sufficient to meet customer requirements. The analyzed requirements then provide the basis for more detailed and precise requirements throughout the project lifecycle.
Tip
One senior DoD program manager on a 7-million-line code development project mused, “We need to find a way to suppress our appetite. We’re developing millions of lines of code for functionality that will never be used.” Although “gold plating” or overpromising may be a good way to justify a project early on, eventually the products need to be built in a reasonable amount of time.
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.
Refer to the Acquisition Technical Management process area for more information about tracking technical progress and technical performance measures.
Typical Work Products
- Requirements defects reports
- Proposed requirements changes to resolve defects
- Key requirements
- Technical performance measures
Subpractices
- Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects.
- Analyze requirements to determine whether they satisfy higher-level requirements.
- Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable.
- Analyze and propose the allocation of requirements to supplier deliverables.
- Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance.
- Identify technical performance measures to be tracked during the acquisition.
Technical performance measures are precisely defined measures based on a product requirement, product capability, or some combination of requirements and/or capabilities. Technical performance measures are chosen to monitor requirements and capabilities that are considered key factors in a product’s performance. Data for technical performance measures are provided by the supplier as specified in the supplier agreement.
Refer to the Measurement and Analysis process area for more information about specifying measures.
- Analyze operational concepts and scenarios to refine customer needs, constraints, and interfaces and to discover new requirements.
This analysis may result in more detailed operational concepts and scenarios as well as support the derivation of new requirements.
Analyze requirements to balance stakeholder needs and constraints.
Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
Requirements are analyzed to determine whether they reflect an appropriate balance among cost, schedule, performance, and other factors of interest to relevant stakeholders. Models and simulations can be used to estimate the impacts that requirements will have on these factors. By involving stakeholders from different phases of the product’s lifecycle in analyzing these impacts, risks can be determined. If the risks are considered unacceptable, the requirements may be revised or reprioritized to improve the balance of cost, schedule, and performance.
X-Ref
When analyzing requirements, look at some of the characteristics described in REQM SP 1.1 subpractice 2 to understand the many factors that can be considered.
Tip
The relationships among customer and contractual requirements are investigated and recorded (see REQM SP 1.4).
Typical Work Products
- Assessment of risks related to requirements
Subpractices
- Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints.
- Perform a risk assessment on requirements and design constraints.
Refer to the Risk Management process area for more information about performing a risk assessment on customer and contractual requirements and design constraints.
- Examine product lifecycle concepts for impacts of requirements on risks.
Validate requirements to ensure the resulting product performs as intended in the user’s environment.
Requirements validation is performed early in the acquisition with end users or their representatives 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 typically perform requirements validation in a more sophisticated way using multiple techniques and broaden the basis of the validation to include other stakeholder needs and expectations. These organizations typically perform analyses, prototyping, and simulations to ensure that requirements will satisfy stakeholder needs and expectations.
Typical Work Products
- Records of analysis methods and results
Typical Supplier Deliverables
- Requirements and validation methods (e.g., prototypes and simulations)
Subpractices
- Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
- 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 Acquisition Validation process area for more information about preparing for and performing validation on products and product components.
- Assess product and product component solutions as they are developed by the supplier in the context of the validation environment to identify issues and expose unstated needs and customer requirements.