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

Requirements and Acceptance Management Plan (RAMP): Management Aspects

Stakeholder Management

Stakeholder management and buy-in is essential for a successful approach to Requirements and Acceptance and so the approach to stakeholder management must feature in the RAMP.

Review and maintenance of the stakeholder matrix, at the start of each phase of the Acquisition lifecycle, is essential to ensure the needs of stakeholders are being met.

For large projects, there are likely to be a considerable number of stakeholders - as a minimum the stakeholder matrix should include all Defence Lines of Development (DLoD) representatives.

Project Resources and Responsibilities

The RAMP identifies:

• The resources required to undertake this activity.
• The availability of the resources identified.
• The skills, knowledge and experience required to fulfil the roles.
• The requirement, as part of Integrated Test, Evaluation and Acceptance (ITEA) for such things as ranges and test facilities.

Maturity, Baselining and Updates

The Requirements and Acceptance evolution guidance suggests the use of nine review points spread across the Acquisition lifecycle.

The RAMP details how the evolution guidance will be implemented throughout the life of the project. Where a deviation from the guidance occurs the reason should be documented and the expected levels of maturity clearly defined.

Prior to Initial and Main Gate, if the expected levels of maturity are significantly less than would normally be anticipated at this stage, the Investments Approvals Board (IAB) should be engaged. They will advise on the acceptability of the proposed submissions.

The RAMP will also define the timescale for:

• Baselining the URD and SRD.
• Timing of updates to all documentation.
• A Performance, Cost and Time (PCT) slippage strategy. The PCT strategy must consider and define the impact any re-baselining of the URD, SRD or acceptance criteria will have on the contract.

Self Assessment and Assurance

The RAMP directs the project to the appropriate Self Assessment and Assurance process for Requirements and Acceptance.

Document Management, Ownership and Control

Requirements and Acceptance documents are key components of the Through Life Management Plan (TLPM). A configuration control process and levels of access are defined within the RAMP to control revisions, changes and additions.

The strategy details the approach to maintaining requirements documentation and the use of requirements management tools to support the development of the requirements set.

The Requirements and Acceptance configuration control processes used should align with those used in the project.

Communications

Poor communications is one of the most frequently cited reasons for project failure.

The RAMP should inform any other IPT or Project communication strategy, and not duplicate it. The communications strategy should reflect the outcome of the stakeholder analysis identifying key stakeholders. As a minimum it should identify the Capability Planning Group (CPG) or Programme Board points of contact.

The communication strategy should ensure sufficient lead time and contingency is factored in to allow stakeholders to complete any consultation.

Trade Off

The RAMP identifies the project approach to trade-off in each stage of the Acquisition lifecycle.

Trade off parameters must be agreed with the Programme Board and key stakeholders in advance.

Change History

Change History

1 August 2010

Removal of PID acronym.