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: Review Checks

This guidance is for those acting in the Requirements Manger role. It covers the checks to perform as part of the Review task when defining system requirements.

The Review checks include:

• adherence to guidance
• individual requirements checks
• fitness for purpose.

Adherence to guidance

Perform a quality check on the (evolving) System Requirements Document (SRD) to ensure that it:

• Complies with the standard format, and is consistent with the compilation guidelines - SRD Structure.
• Is internally consistent across all Parts, and across single statements within Part 3 of the SRD.
• Is complete, covering all of the user requirements, and all the unavoidable constraints.
• Is not over-engineered.
• Is not over-prescriptive.
• Is free of solution specifications.
• Is well structured and organised.
• Is correctly understood by, and satisfies the needs of, its target audience.

Individual requirements checks

Within Part 3 of the SRD, check the individual requirements as suggested in the following table to ensure they have the desired characteristics.

Desired Characteristic	Questions to Ask
Unambiguous	Is each requirement understandable and clear to its intended audience? Does it have only one interpretation? Is the 'user' identified?
Concise	Is each requirement singular / atomised? Is it brief and precise? Are there any redundant words?
Objective	Are there any subjective or descriptive expressions, such as 'comfortable', used?
Subject to validation	Can the satisfaction of each requirement be objectively tested and how? Is what constitutes a ‘pass’ clear?
Non-prescriptive	Is each requirement genuinely a need and not a solution or implied solution?
Traceable	Can each requirement be traced back via the User Requirements Document (URD) to a stakeholder and thus its source?
Justified	Test the need for each individual requirement by asking - "What would be the impact of omitting this requirement?" Is the justification an obvious statement (e.g. to a scrutineer), not merely an obscure reference?
Unique	Does it describe a single characteristic required at that level of detail?
Abbreviations and acronyms otherwise explain them fully in the glossary.
Technology or solution-independent within the bounds of down-selection decisions already taken.
Achievable at an acceptable level of risk.
Verifiable	Is it numerically quantified or is its satisfaction ‘measurable’? Is the verification criteria appropriate to both the nature of the requirement and its importance? Are the ‘pass’ or ‘fail’ criteria clear?

Fitness for Purpose

Check the resulting set of system requirements to confirm that it is fit for purpose:

• Is it complete in its coverage?
  • Are all User Requirements and Capability Constraints - and no more - addressed?
  • Are mandatory system interfaces identified?
  • Are user requirements and constraints linked to at least one system requirement or constraint?
• Is it internally consistent and free of contradiction, particularly between requirements and constraints?
• Is it achievable within Approval Limits?
• Is it a fit-for-purpose input to other processes? In particular, for the development of solution options, the Equipment Contract Specification and the acquisition of the non-equipment DLoD.

Change History

Change History