Summary

Establish and maintain contractual requirements that are based on the customer requirements.

Description

Customer requirements can be expressed in the customer’s terms and can 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 and operationally related quality attribute requirements and their validation, technical performance measures, verification requirements such as product acceptance criteria), contractual requirements cover nontechnical stakeholder needs, expectations, constraints, and interfaces.

 

Examples of nontechnical requirements include the following:
  • Frequency and format of supplier reviews
  • Supplier reports and other communication
  • Availability of support to meet levels of the business process or product performance
  • Warranty of products provided by a supplier
  • Logistics support that sustains both short- and long-term readiness
  • Minimal total lifecycle cost to own and operate (i.e., minimal total ownership cost)
  • Maintenance concepts that optimize readiness while drawing on both acquirer and supplier sources
  • Data management and configuration management that facilitates cost effective product support throughout the product’s use by the acquirer


The modification of requirements due to approved requirement changes is covered by the maintain aspect of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area.

Refer to the Requirements Management (REQM) (CMMI-ACQ) process area for more information about managing requirements.


Example Work Products



  1. External interface requirements
  2. Prioritized contractual requirements


Subpractices



1. Develop functional and quality attribute requirements necessary for the determination of alternative solutions and the development of the product by the supplier.

Priorities can be assigned to product requirements to provide a basis for future requirements tradeoffs should such tradeoffs become necessary. Acquirers may assign priorities using categories such as Essential, Important, or Desirable.



2. Develop requirements for the interfaces between the acquired product and 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 considerations and constraints necessary for supplier activities that include: determination of alternative solutions, development and evaluation of architectures, and the development of the product.

Design considerations and constraints address the quality attributes 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 can establish common design constraints for products or product families that can be deployed in one or more domains. Alternatively, acquirers can 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.

Common design constraints can also be established and maintained by a customer organization or system-of-systems office for a group of acquisitions collectively intended to establish a major capability (e.g., for systems-of-systems, product lines, standard services).



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.

 

Testing requirements can include mirroring the production environment of the acquirer, the type of test data to be used, and simulated testing of interfaces with other products.



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 can 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 (PP) (CMMI-ACQ) process area for more information about establishing the acquisition strategy and estimating effort and cost.