Many of our colleagues in the systems engineering industry and government have noted that DoD and other organizations acquisition programs frequently have documented requirements that are stated too generally to support development of good Technical Performance Measures (TPMs) for assessing progress in design development or verification measures to ensure a requirement has been satisfied.
If at the beginning of a program acquisition process the operational requirements and the derived systems requirements are too general or too vague with no or vague operational and systems performance goals, it is difficult to develop meaningful TPMs and/or verification values.
Is there a way to adjust the acquisition process to better define requirements earlier? Can we identify an acquisition milestone by which time the operational sponsor for a program must have refined its requirements statements to better support TPM and verification measure development?
In our review of DoD policy and practice, we have identified the following 7 factors or rules of thumb that may assist in developing better operational and system requirements. In this process it is important to distinguish between these operational requirements and system requirements
- Operational requirements must not specify particular system solutions and should have clear performance goals. These requirements need to be developed early in the lifecycle (for DoD programs this should be before the Milestone A Decision).
- Operational requirements should be clearly linked to an operational architecture.
- System requirements should be clearly derived from the operational requirements and linked to a systems architecture clearly derived from the operational architecture (for DoD pre-Milestone B).
- System requirements should have clearly stated performance goals derived from the operational performance goals (for DoD by Milestone B).
- Performance goals should be clearly allocated to software, hardware, and human operator (for DoD by Milestone B).
- Hardware, Software, and Human elements of a system should each have their own set of requirements and architectures linked to the system requirements and system architecture (for DoD by Milestone B).
- TPMs can then be formulated as the status of each desired performance goal. TPMs can be rolled up through the allocations (for DoD by Milestone B).
Innoslate provides a means to capture this kind of information and determine the quality of the requirements. Check out the white paper entitled “Using Innoslate for Requirements Analysis and Management” for more details.
Topics: Systems Engineering