The Requirements Management process maintains a current and approved set of requirements over the entire acquisition life cycle. This helps ensure delivery of a capability that meets the intended mission performance, as stipulated by the operational user.
The end-user needs are usually identified in operational terms at the system level during implementation of the Stakeholder Requirements Definition and Requirements Analysis processes (see Systems Engineering (SE) Guidebook, Section 4.2.1. Stakeholder Requirements Definition Process and SE Guidebook, Section 4.2.2. Requirements Analysis Process, respectively). Through the Requirements Management process, the Systems Engineer tracks requirement changes and maintains traceability of end-user needs to the system performance specification and, ultimately, the delivered capability. As the system design evolves to lower levels of detail, the Systems Engineer traces the high-level requirements down to the system elements through the lowest level of the design.
Requirements Management provides bottom-up traceability from any derived lower-level requirement up to the applicable source (system-level requirement) from which it originates. This bi-directional traceability is the key to effective management of system requirements. It enables the development of an analytical understanding of any system-wide effects of changes to requirements for a given system element, updating requirements documentation with rationale and impacts for approved changes.
At the same time, bi-directional traceability ensures that approved changes do not create any "orphaned" lower-level requirements (i.e., that all bottom-up relationships to applicable system-level requirements remain valid after the change). Bi-directional traceability also ensures that higher-level requirements are properly flowed to lower-level requirements and system element designs so that there are no "childless parent" higher-level requirements (i.e., each high-level requirement is ultimately being addressed by lower-level requirements and system element designs).
Robust Requirements Management, implemented in synchronization with the program’s Configuration Management process (see SE Guidebook, Section 4.1.6. Configuration Management Process), can help the program to avoid or mitigate unintended or unanticipated consequences of changes through rigorous documentation of the system performance specification. Thoughtful analysis and management of requirements can help lay the foundation for system affordability.
The Program Manager (PM) should keep leadership and all stakeholders informed of cost, schedule and performance impacts associated with requirement changes and requirements growth.
The Systems Engineer establishes and maintains a Requirements Traceability Matrix (RTM), which captures all the requirements in the system performance specification, their decomposition/derivation and allocation history and rationale for all entries and changes. The requirements should be:
All affected stakeholders and decision makers should fully understand the effects of proposed changes to requirements at the system or system element level before they accept any changes for incorporation into the design. The RTM provides significant benefits during trade-off analysis activities, since it captures the system-wide effects of proposed changes to established requirements.
In accordance with DoDI 5000.85, 3C.3.e., Component Acquisition Executives (CAE) establish Configuration Steering Boards (CSB), following Capability Development Document (CDD) validation, for Acquisition Category (ACAT) I and IA programs in development, production and sustainment. The CSB reviews all requirements changes and any significant technical configuration changes that have the potential to result in cost and schedule impacts to the program. In a continuous effort to reduce Total Ownership Cost (TOC), the PM, in consultation with the Program Executive Officer (PEO) and requirements sponsor, will identify and propose to the CSB recommended requirements changes, to include de-scoping options, that reduce the program cost and/or moderate requirements needed to respond to any threat developments. These recommended changes will be presented to the CSB with supporting rationale addressing operational implications.
SE Guidebook, Section 2.2 Tools, Techniques, and Lessons Learned contains information about SE tools generally employed in the Requirements Management process. There are many commercial software packages specifically designed for the traceability aspect of Requirements Management, from top-level operational requirements down to the lowest-level system elements in the Work Breakdown Structure.