It All Starts With REQUIREMENTS!

The key to any successful DoD/DHS development program is identifying and understanding all of the program requirements immediately after contract award and before any real resources have been committed. Without a comprehensive grasp of the program requirements, it is not likely that your project plan will lead to fulfillment of the Customer’s needs.

Understanding Requirements

It is also critical that you establish program goals or milestones that are directly traceable to these requirements. This will ensure that your entire team is working toward the same completion point, and that the milestones represent a satisfied Customer. It will also make sure that the technical approach, resourcing, and schedule developed by the PM will effectively and efficiently guide the team along the desired path.

A requirement is a statement of a necessary or expected system property, feature, characterization, or usage. There are different kinds of requirements. In most cases, requirements focus on function (what the system does) and quality (how well it does it).

From a Product Support perspective, requirements originate from a need and are communicated from the Customer (typically a Government Service) using different channels. It would be foolish to rely on one document or discussion to establish the requirements for a program. A comprehensive effort to gather requirements from all possible sources will ensure nothing that defines program success is overlooked. The following are some sources of program requirements, along with practical examples of Product Support program requirements that should be researched, identified, and documented.

• Contract Section C (or J Attachment) of the SOW
• Contract Data Requirements List (CDRL) items
• Performance Specifications, including the support system requirements
• Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS)
• Meetings intended to validate both the Government’s and Contractor’s understanding and interpretation
  • Project Kickoff
  • Provisioning Guidance Conference (PGC)
  • Technical Manual Kickoff
  • IPTs

As hard as the Buying Agency may try to clearly define what their expectations are for the products and services they are purchasing through the use of these requirements documents, there is often room for interpretation. This situation further emphasizes the need to address program requirements early. Requirements should be documented and evaluated periodically at program technical and management reviews to ensure all activities are focused on the established goals and to assess progress toward meeting those requirements.

Taking a Systems Engineering Approach to Requirements Management

The Systems Engineering process is the basis for the identification and documentation of program requirements. This activity often employs a software tool such as DOORS or JAMA to capture, characterize, and define program requirements. Documenting and socializing these specific program requirements supports the focusing of design, analysis, testing, program management, and logistics analysis efforts towards fulfilling these stated requirements.

After coordination with the customer and a first-order definition of the system technology to be employed, these stated requirements will be subject to the Requirements Derivation process where new and more detailed requirements are created based on these higher-level stated requirements. The focus of the derivation process is to develop actionable requirements through decomposition, analysis, consideration of program constraints, allocation, and, lastly, documenting traceability back to the higher-level requirements.

For example, if the System Performance Specification includes a system level requirement for Operational Availability (A_o), the derivation process will break down this requirement to subsystem or equipment level design-to parameters such as Mean Time Between Failure (MTBF) and Mean Time to Repair (MTTR). The documentation of this derived requirement will also include traceability to the verification method that will be used to confirm that the system design and support comply with the higher-level requirement. In the example above, the system and derived requirements could be verified by analysis contained in the Reliability, Maintainability, and Availability (RMA) Analysis Report, likely a CDRL deliverable item.

Both the system-level and derived requirements become program goals for all program activities, including design, product support, testing, etc., and help the Program Manager allocate resources to the identified verification methods and processes that are associated with each requirement. The completed Requirements Verification Matrix is usually highlighted during the program Design Reviews (PDR and CDR) with the Customer.

Article Authored by Stephen Brunner, Business Director