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 Principles

What are system requirements ?

System requirements may be:

• functional requirements - what the system must do
• non functional requirements - constraints and how well it must perform.

All system requirements for any one system-of-interest shall be recorded in a System Requirement Document (SRD) that is unique to that system. Each system requirement shall be traceable back to its source user requirement documented in a User Requirements Document (URD).

What are Key System Requirements ?

Key System Requirements (KSR) are a sub-set of the system requirements - and constraints exceptionally.

KSRs may be used at the discretion of the IPT:

• To highlight those few requirements that are high priority or fundamental to the required performance.
• To highlight critical requirements and constraints that attract high risk.
• To identify a sub-set of system-characterising requirements and constraints as a basis for summary management reporting.

What are system constraints ?

System constraints are necessary restrictions on the solution to the system requirements.

Their main sources are:

• the URD
• the other DLoDs that contribute to the system-of-interest
• interoperating systems
• the existing system to be upgraded or updated, where relevant
• MOD policy
• standards
• legislation and regulations.

All system constraints for any one system-of-interest shall be recorded in that systems’ SRD.

Each system constraint shall be traceable back to its source.

What is the scope of system requirements ?

Interoperability requirements shall be addressed as an integral element of the system need, not as an addendum. They include both the need to output services to other systems and the need to input services from other systems.

The non-equipment DLoDs that contribute to the system-of-interest may themselves require the acquisition of enabling-equipment. Typically, this includes special-to-type training systems and test equipment inextricably linked with the equipment solution and it follows that the IPT is best placed to lead on the Training and Logistics DLoDs.

The complexity of such enabling equipments and their procurement strategy determines whether they fall within the scope of the SRD for the operational capability, or demand separate SRDs.

What is a ‘system’ in this context ?

In this context, a 'system' is an equipment or service that contributes in delivering a new operational capability that is operated by suitably trained personnel and is logistically supported.

It may require associated infrastructure within a specific context, it may exploit information, and it may be operated in accordance with specific doctrine and concepts.

A system in this context may:

• Deliver an operational capability - for example centred on a new Main Battle Tank.
• Deliver an enabling capability - for example centred on a simulator for conversion-to-type training, or special-to-type test equipment for sustaining operations.
• Form a part of a larger system-of-systems, and may have an integrated set of sub-systems or components within it.

Change History

Change History