The System Requirement Document (SRD) defines system level functional and performance requirements for a system. The SRD is derived from the Concept of Operations (CONOPS), system-level performance metrics, mission threads/use cases, and usage environment and is developed but by the program office.  It should include a system level description of all software elements required by the preferred system concept.  The SRD is developed during the Technology Development (TD) Phase but a draft SRD should be developed for the Analysis of Alternatives (AoA) in the Materiel Solutions Analysis (MSA) Phase. The SRD is used by the program office to provide more detailed requirements than what’s provided in a Capability Development Document (CDD) and should be finalized prior to contract award. [1]

MIL-STD-961E “Defense and Program-Unique Specifications Format and Content” – 2 April 2008

The SRD should be developed with feedback and input from the industrial base. Once the SRD is placed on contract, the contractor will further develop the specification and develop their own, more detailed requirements document; sometimes called a Weapons Systems Specification (WSS).

The term “System Requirements Document” is a phrase commonly used to describe a software performance specification. If your acquisition is exclusively for software, you may call yours a “System Performance Specification” or “System Requirements Document”.

Follow MIL-STD-961E “Defense and Program-Unique Specifications Format and Content” when developing the SRD.

AcqTips:  

  • A contractor may build an internal document for managing the traceability of their requirements. If they call this an SRD, you might want to call yours a system specification to avoid confusing the two. Any requirements in their document should be ultimately traceable back to your system performance specification.
  • The SRD and WSS should all be traceable to the Initial Capabilities Document (ICD) and CDD.

AcqLinks and References:

Print Friendly, PDF & Email