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.

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.

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

1.    External interface requirements

2.    Contractual requirements

3.    Contractual requirements priorities

Subpractices

1.    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.

2.    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.

3.    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.

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.

4.    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.

5.    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.

6.    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.

7.    Establish and maintain a prioritization of contractual requirements.

Priority can be based on a combination of several factors that include customer desires, costs, timeframe 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.