Explorer

• Introduction to Requirements and Acceptance
• Organisations, Roles and Responsibilities
  • Organisations and Groups
  • Sponsor and User Responsibilities
  • Programme or Project Responsibilities
  • Stakeholder Responsibilities
• Principles
  • Requirements Management Principles
  • The Requirement and Acceptance Management Plan (RAMP)
    • RAMP: Requirements and Acceptance Strategies
    • RAMP: Management Aspects
  • User Requirements Principles
    • Key User Requirements (KUR) Principles
    • User Requirements Document (URD) Principles
  • System Requirements Principles
    • System Requirements Document (SRD) Principles
  • Effectiveness Envelope
  • Test, Evaluation and Acceptance Principles
    • Test and Evaluation Principles
    • Acceptance Principles
    • Integrated Test, Evaluation and Acceptance (ITEA) Principles
    • Verification and Validation
• Processes
  • Requirements Management Tasks
  • User Requirements Definition
    • Defining User Requirements: the Six Tasks
    • User Requirements Capture: Areas to Consider
    • User Requirements: Review Checks
  • System Requirements Definition
    • Defining System Requirements: the Six Tasks
    • System Requirements: Define Constraints
    • System Requirements: Review Checks
    • Do's and Don'ts when Defining System Requirements
  • Requirements and Acceptance Evolution
    • Stage 1: Project Initiation to Mid Concept
    • Stage 2: Mid to End of Concept
    • Stage 3: Initial gate to End of Concept
    • Stage 4: Start to Mid Assessment
    • Stage 5: Mid Assessment to Start of Demonstration
    • Stage 6: Start to End of Demonstration
    • Stage 7: End of Demonstration
    • Stage 8: Start of in-service to FOC
    • Stage 9: In Service (FOC)
  • Integrated Test, Evaluation and Acceptance (ITEA) Process
    • ITEA Process: the Six Tasks
• Products
  • Requirements and Acceptance Management Plan (RAMP)
  • User Requirements Document (URD)
    • URD Part 1: General Description
    • URD Part 2: Key User Requirements
    • URD Part 3: Individual Capability Requirements and Constraints
    • URD Parts 4 and 5: Context Documents and Glossary
    • User Requirements: Recommended Core Attributes
  • System Requirements Document (SRD)
    • SRD Part 1: General Description
    • SRD Part 2: Key System Requirements
    • SRD Part 3: Individual System Requirements and Constraints
    • SRD Parts 4 and 5: Context Documents and Glossary
    • System Requirements: Recommended Core Attributes
  • Integrated Test, Evaluation and Acceptance Plan (ITEAP)
    • ITEAP Schedule
    • Verification and Validation Requirements Matrix (VVRM)
• Resources
  • Acronyms
  • Glossary

Content

System Requirements Document (SRD) Principles

What is a System Requirements Document ?

A System Requirements Document (SRD) is a structured definition of the characteristics that the MOD require and expect of an equipment-centric solution to an operational capability need.

It is the solution-focussed response to a capability-focussed User Requirements Document (URD) and it is the single source for all relevant information, managed throughout the life of the equipment.

What is the purpose of the SRD ?

• It defines what is needed, by how much, at what level of performance and when – across all DLoDs.
• It sets the benchmark to validate the Equipment Contract Specification (ECS) or Statement of Requirement (SOR) against.
• It defines the ‘current intention’ for performance and time to develop the ECS from and to conduct the following against:
  • Balance of Investment
  • analysis of Trade-Offs
  • option down-selection
  • Combined Operational Effectiveness Approval (part of the Combined Operational Effectiveness Investment Appraisal (COEIA))
  • supplier selection.
• It defines the baseline to verify and accept the equipment solution to the URD against.
• It informs the development of an ECS or SOR to enable procurement.
• It informs the non-equipment DLoD contributors of what their contributions must include.
• It informs the equipment DLoD contributor of what constraints the non-equipment DLoD contributions impose.
• It informs other SRDs of interoperability that is required by the system or is committed by the system.
• It informs Through Life Capability Management of how much a capability gap - defined in a URD - can be filled at an acceptable level of risk by contributions from each DLoD. This also informs residual gap analysis.

What is the life of an SRD ?

The SRD endures throughout the life of the equipment contribution to the capability which may differ from the life of the capability.

Normally the SRD is developed – or an existing one is changed - when the ‘first-pass’ of capturing user requirements is complete. At this point the URD is sufficiently mature to inform the development of the SRD.

Scope and Boundary of the SRD ?

The scope and boundary of the SRD includes:

• One discrete system - ideally with a single Design Authority for the equipment DLoD contribution, and subject to a single Acceptance Strategy.
• Detailed requirements for the equipment DLoD contribution, including interoperability with other systems.
• Summary requirements for the non-equipment DLoD contributions – that are still testable.
• Constraints that the equipment DLoD contribution imposes on the other contributing DLoDs and the constraints imposed on the equipment DLoD by the other contributing DLoDs.
• Additional constraints on the equipment DLoD contribution that are not attributable to the other DLoDs.

How is Change Management applied to the SRD ?

From inception in the Concept stage through to supplier selection, the SRD is subject to managed change and local version control should be applied.

At supplier selection, evolution of the complete SRD should be suspended to provide a period of stability while an ITT is prepared and supplier offers are solicited and evaluated.

Who owns the SRD ?

The SRD is produced by the Requirements Manager on behalf of the Integrated Project Team Leader (IPTL).

The IPTL owns the SRD and the IPTL, who is accountable to the URD sponsor, must ensure that value-for-money and achievability are integral to the SRD.

Who Authorises, Approves and Endorses the SRD ?

The Requirements Manager may authorise versions of the SRD for release to stakeholders and assessors.

The IPTL should approve versions of the SRD for release to external assessors and scrutineers, other DLoD suppliers, and in support of Business Cases.

The User should endorse versions of the SRD used as a basis for formal tasking of other DLoD suppliers, and in support of Business Cases.

What happens if the acquisition is Cancelled ?

If a complete acquisition is cancelled by the IAB at Initial or Main Gate, then the future of the SRD should be determined within the Through Life Capability Management process.

What is the relationship to the URD?

There should be a close alignment between an SRD and its initiating URD.

Where more than one system contributes to the satisfaction of a URD then one system should predominate, determining the Lead IPT. The Lead IPT acts as a focal point of contact with the Sponsor on behalf of all contributing systems and associated IPTs.

A single SRD may result in the procurement of more than one piece of equipment.

What is the relationship to the CIS System-of-Systems Portfolio ?

If the SRD defines a Communication and Information Systems (CIS) or service contributing to Network Enabled Capability (NEC) then the system should also be defined in a MOD Architectural Framework (MODAF). The model should define the relationship with interoperating systems and any parent system-of-systems.

What is the relationship to the DLoD ?

The Defence Lines of Development represent the highest level system solution architecture and their use is common across all MOD systems.

In defining system requirements the SRD allocates system characteristics across the DLoDs. As a result the SRD serves as a cohesive set of requirements for each and all of the individual DLoDs, recording the constraints that each imposes on the others.

Other DLoDs (particularly Training and Logistics) can have their own needs for procuring enabling equipment. They may be expressed directly in an Equipment Contract Specification, if they are simple, or they may involve developing a new SRD (or an annex to the core system SRD) for the required enabling system.

What about Urgent Operational Requirements (UORs) ?

SRDs should be raised for UORs. The urgency does not remove the need to define requirements in a systematic and structured way.

What is the Structure and Format of an SRD?

Each SRD consists of a complete, structured, set of individual system requirements and constraints supported by other text or documents. It may be maintained within a requirements database.

The SRD Structure comprises five parts and although the standard format may be augmented it should not be abridged without very good reason.

Change History

Change History

1 July 2008

Link to CIS Interoperability updated.