# Requirements Management Plan: [Project or product name]

> Requirements management plan describing how requirements will be
> elicited, documented, prioritised, baselined, changed, traced and
> reported for [Project name]. Based on common industry practice in
> business analysis and systems engineering. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write the plan at project start and keep it short enough that people
  actually follow it. Tailor the process to the project's size and risk.
- Agree sections 3 (roles) and 7 (change control) with the sponsor before
  any requirement is baselined; disputes later are about these two.
- Reference the tools and templates the team will really use, with links.
- Review the plan at each phase gate and record changes in section 13.
-->

| Field | Value |
|---|---|
| Document ID | [RMP-PROJECT-001] |
| Project | [Project name] |
| Version | [0.1] |
| Status | [Draft / Approved] |
| Owner | [@lead-business-analyst] |
| Approved by | [@sponsor], [@project-manager] |
| Last updated | YYYY-MM-DD |

## 1. Purpose and scope

<!-- Guidance: What this plan governs and which requirement levels it covers. -->

This plan governs the requirements of [Project name] from initial
elicitation to acceptance and handover. It covers [business, stakeholder,
system and software requirements / epics and user stories] for [releases
in scope]. It does not cover [for example operational change requests
after handover, which follow the service management process].

## 2. Elicitation approach

<!-- Guidance: Choose techniques per stakeholder group and requirement type. Plan the sessions; elicitation that is not scheduled does not happen. -->

| Stakeholder group | Techniques | Frequency / timing | Output | Facilitator |
|---|---|---|---|---|
| *Example:* Executive sponsors | Interviews | Weeks 1 to 2 | Business objectives, constraints | [@ba] |
| *Example:* Operations staff | Observation, workshops | Weeks 2 to 5, 3 workshops | Process maps, user requirements | [@ba] |
| *Example:* Customers | Survey, usability sessions | Weeks 3 to 6 | Needs, pain points | [@ux] |
| *Example:* IT and security | Document analysis, interviews | Weeks 2 to 4 | Constraints, interface requirements | [@architect] |
| [Group] | [Technique] | [Timing] | [Output] | [@name] |

Elicitation records (notes, recordings, photos of whiteboards) are stored
in [location] with ID `ELC-nnn` so that each requirement can cite its
source.

## 3. Roles and responsibilities

<!-- Guidance: One accountable person (A) per activity. R = responsible, A = accountable, C = consulted, I = informed. -->

| Activity | Sponsor | Product owner | Business analyst | Architect | QA lead | Dev team | CCB |
|---|---|---|---|---|---|---|---|
| Elicit requirements | I | C | A/R | C | C | C | - |
| Document and analyse | I | C | A/R | C | C | C | - |
| Prioritise | C | A | R | C | I | C | - |
| Approve baseline | A | R | R | C | C | I | C |
| Assess change impact | I | C | A/R | R | R | R | I |
| Approve changes | C | R | C | C | C | I | A |
| Maintain traceability | - | I | A/R | C | R | R | - |
| Verify and accept | C | A | R | C | R | C | - |

The change control board (CCB) consists of [sponsor or delegate, product
owner, architect, project manager, QA lead] and meets [weekly / as
needed].

## 4. Requirement types and attributes

<!-- Guidance: Name each type, its ID format and the attributes every requirement must have before it can be approved. -->

| Type | ID format | Documented in |
|---|---|---|
| Business requirement | BR-nnn | BRS |
| Stakeholder / user requirement | STK-UR-nnn | StRS |
| Functional requirement or user story | SRS-FR-nnn / [KEY]-nnn | SRS / backlog |
| Non-functional requirement | NFR-<char>-nn | NFR specification |
| Transition requirement | TR-nnn | Transition plan |
| Constraint | CON-nnn | Relevant specification |

| Attribute | Values | Mandatory |
|---|---|---|
| ID | Unique, never reused | Yes |
| Statement | One testable sentence | Yes |
| Source | Stakeholder and elicitation record | Yes |
| Rationale | Why it is needed | Yes |
| Priority | Must / Should / Could / Won't | Yes |
| Owner | Accountable stakeholder | Yes |
| Status | Proposed, Approved, Implemented, Verified, Deferred, Rejected | Yes |
| Verification method | Inspection, Analysis, Demonstration, Test | Yes |
| Target release | Release ID | When approved |
| Risk / complexity | High, Medium, Low | Optional |

## 5. Prioritisation method

<!-- Guidance: Pick one primary method and say who decides ties. Combine MoSCoW for scope with a scoring method for ordering if needed. -->

Scope is set with **MoSCoW**. Within each category, items are ordered by a
value-to-cost score:

$$
\text{Score} = \frac{\text{Business value} + \text{Risk reduction} + \text{Time criticality}}{\text{Effort}}
$$

Each factor is scored 1, 2, 3, 5, 8 or 13 by the product owner (value,
time criticality), architect (risk reduction) and development team
(effort). Must requirements together may not exceed [60%] of planned
capacity. Ties are resolved by the product owner; disputes escalate to the
sponsor.

## 6. Baseline

<!-- Guidance: Define what a baseline is, when it is taken, and how it is identified. -->

A baseline is the approved set of requirements, at a stated version, for a
release. Baselines are taken at [end of analysis phase / each release
planning] and are labelled `REQ-BL-<release>.<n>`. After baseline, any
change to an approved requirement follows section 7. Editorial changes
that do not alter meaning (spelling, formatting) are allowed without CCB
approval but are recorded in the revision history.

## 7. Change control process

<!-- Guidance: Keep the process proportional: small changes decided by the product owner, large ones by the CCB. Define the thresholds. -->

The flow below shows how a change request moves from submission to closure.

```mermaid
flowchart TD
  A[Change request submitted] --> B[BA logs CR and checks completeness]
  B --> C[Impact analysis: scope, cost, schedule, risk]
  C --> D{Within product owner threshold?}
  D -->|Yes| E[Product owner decides]
  D -->|No| F[CCB decides]
  E --> G{Approved?}
  F --> G
  G -->|Yes| H[Update requirements, baseline and traceability]
  G -->|No| I[Record rejection and reason]
  H --> J[Communicate decision]
  I --> J
```

| Threshold | Decided by |
|---|---|
| *Example:* Effort under 3 days, no change to a Must, no schedule impact | Product owner |
| *Example:* Effort 3 days or more, or affects a Must, a milestone or budget | CCB |
| *Example:* Budget increase above [10%] or milestone moved | Sponsor via CCB |

Each change request records: ID, requester, date, description, reason,
affected requirements, impact estimate, decision, decision date and
decider.

## 8. Traceability approach

<!-- Guidance: Say which links are maintained, at what level, by whom, and where. -->

Links maintained: business requirement to stakeholder requirement to
system or software requirement to design element to test case. Links are
recorded in [tool] and exported to the requirements traceability matrix
[RTM-xxx] at each baseline. The BA is accountable; developers link
commits and pull requests to requirement IDs; QA links test cases.

## 9. Tools and repositories

| Purpose | Tool | Location | Access |
|---|---|---|---|
| *Example:* Requirements repository | [Requirements tool or Markdown in Git] | [URL or path] | Project team: edit; stakeholders: read |
| *Example:* Backlog | [Issue tracker] | [URL] | Team |
| *Example:* Models and diagrams | [Modelling tool] | [URL] | BA, architects |
| *Example:* Test management | [Tool] | [URL] | QA, BA |
| [Purpose] | [Tool] | [Location] | [Access] |

## 10. Review and approval

<!-- Guidance: Define review types, participants and exit criteria so that "approved" means the same thing to everyone. -->

| Review | Participants | When | Exit criteria |
|---|---|---|---|
| Peer review | BA, another BA | Each new requirement set | Checklist complete; no open major comments |
| Stakeholder walkthrough | Owners of the requirements | Before baseline | Each owner confirms correctness |
| Technical review | Architect, dev lead, QA lead | Before baseline | Feasible, testable, no conflicts |
| Formal approval | Sponsor, product owner | Baseline | Signed approval recorded |

Requirement quality checklist: necessary, unambiguous, singular,
feasible, verifiable, consistent, traceable, and free of design detail.

## 11. Metrics

<!-- Guidance: A few metrics, reported regularly, that show stability and quality of requirements. -->

| Metric | Definition | Target | Report frequency |
|---|---|---|---|
| Requirements volatility | Changed + added + deleted after baseline / baselined count | Under [10%] per release | Per sprint |
| Change request cycle time | Median days from submission to decision | Under [5] days | Monthly |
| Test coverage | Approved requirements with at least one test / approved | 100% of Must | Per baseline |
| Review defect density | Defects found in review / requirements reviewed | Trending down | Per review |
| Requirements defects in test | Defects traced to wrong or missing requirements | [Target] | Per release |

## 12. Communication

<!-- Guidance: Who hears what, how and how often. -->

| Audience | Information | Channel | Frequency | Owner |
|---|---|---|---|---|
| Sponsor and steering group | Baseline status, major changes, metrics | Steering report | Monthly | [@pm] |
| Delivery team | New and changed requirements | Backlog refinement | Weekly | [@po] |
| Stakeholder owners | Decisions on their requests | Email, CR log | Per decision | [@ba] |
| All stakeholders | Approved baseline | Repository link | Per baseline | [@ba] |

## 13. Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial plan |
| [x.y] | YYYY-MM-DD | [@name] | [Change] |

## Standard and licence note

Based on common industry practice for requirements management planning in
business analysis and systems engineering. Original text written for this
collection; examples are illustrative. Template licence: MIT.