Requirements management plan template
A requirements management plan says how a project will handle its requirements from the first draft to the last change: where they are written, how they are identified and versioned, who approves them, how they are traced to work and tests, how changes are requested and decided, and when a set of them is frozen as a baseline. It is short, written once near the start, and changed rarely; the requirements themselves live elsewhere. Below are what it covers, a template, a filled-in example for a software project, how it differs from a scope management plan and a traceability matrix, and a lighter version for agile teams.
I’ve spent the last 6 months trying to restore traceability as DAs and devs have amended signed off requirements, which has impacted releases , quality and significant additional cost (tens of thousands).
— r/businessanalysis, in a thread on requirements management for large software projects, 2022
What is a requirements management plan?
Requirements management, in Wikipedia’s definition, “is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project” (Wikipedia). The plan is the page that says how a particular project will do it.
NASA’s systems engineering handbook lists it as the first of the requirements management activities: “Establish a plan for executing requirements management.” Before that, “The organization (e.g., change board) and procedures to perform requirements management are established” (NASA Systems Engineering Handbook, section 6.2). In the PMBOK Guide’s process model, the requirements management plan is written while planning scope management, next to the scope management plan, and becomes part of the project management plan — which is why it turns up in PMP study material.
The reason to write it early is that the first baseline depends on it. Karl Wiegers: “Make sure your change control process and players are in place before you define any project baselines” (The Line in the Sand).
What a requirements management plan includes
| Section | What it settles |
|---|---|
| Documents | Which requirements documents exist and where each lives |
| IDs and versions | The ID scheme, versions per requirement and per document |
| Attributes | Priority, status, source and owner of each requirement |
| Roles | Who writes, reviews and approves which requirements |
| Sign-off and baselines | Who signs which version, and when a baseline is made |
| Traceability | What is linked to what, and where the links are kept |
| Change control | How changes are requested, analysed and decided |
| Tools | Where each of the above is kept |
| Metrics | What is counted and reported |
| Communication | Who is told about changes, and how |
Each section name links to the page on this site that covers it in detail.
Requirements management plan template
Copy it into a document; square brackets are yours to fill in. Two pages is plenty.
REQUIREMENTS MANAGEMENT PLAN
Project: [name]
Version: [x.y], [date]
Owner: [name, role]
1. DOCUMENTS
[document]: [which requirements],
[where it lives]
2. IDS AND VERSIONS
IDs: [prefix per type]; never
reused
Versions: [per requirement];
[per document x.y]
3. ATTRIBUTES
Priority: [scheme]
Status: [list of statuses]
Each requirement also has: [source,
owner]
4. ROLES
Writes: [name, role]
Reviews: [names, roles]
Approves: [who, for which
requirements]
5. SIGN-OFF AND BASELINES
[who signs], at [which points];
a baseline is named [RB-n]
6. TRACEABILITY
[from] -> [to] -> [to]
Kept in: [tool or matrix]
7. CHANGE CONTROL
Request: [form, channel]
Impact: [who analyses]
Decides: [board, limits]
Fast path: [threshold, who]
Recorded: [change log, decision log]
8. TOOLS
[what]: [where]
9. METRICS
[what is counted, how often]
10. COMMUNICATION
[who is told what, how, when]
Requirements management plan example
The customer portal from the other templates on this site, as the supplier’s business analyst wrote it before the requirements were agreed in January:
REQUIREMENTS MANAGEMENT PLAN
Project: Customer portal
Version: 1.0, 20 January
Owner: business analyst (supplier)
1. DOCUMENTS
Vision and scope: objectives (BO-)
and business requirements (BR-)
Functional specification: FR-,
business rules (RULE-), criteria
Non-functional list: NFR-
All in Confluence. Stories (PAY-)
in Jira link to the FR they build.
2. IDS AND VERSIONS
IDs never reused. Each requirement
has its own version (1, 2, ...);
the set has a version (1.0, 1.1).
3. ATTRIBUTES
Priority: MoSCoW, per release
Status: proposed, approved,
implemented, verified,
deferred, deleted, rejected
Each requirement also has a source
and an owner.
4. ROLES
Writes: business analyst
Reviews: product owner, finance
lead, tech lead, tester
Approves: product owner; finance
lead for payment rules
5. SIGN-OFF AND BASELINES
Product owner and finance lead sign
each version that starts or ends a
phase. Baselines are RB-n.
6. TRACEABILITY
BO -> BR -> FR, NFR, RULE -> story
-> test. Links in Jira; a matrix
exported before each sign-off.
7. CHANGE CONTROL
Request: change request form,
by email to the BA
Impact: BA with the tech lead
Decides: change control board, up
to 10 days or 10,000 EUR;
above that, the sponsor
Fast path: under 4 hours, product
owner and delivery lead
Recorded: change log; decision log
8. TOOLS
Confluence: documents. Jira: stories
and change requests. A spreadsheet:
the matrix export.
9. METRICS
Monthly: changes per month against
the baseline; open requests.
10. COMMUNICATION
Each decision goes to the requester
and to everyone on the impact list
the same day.
The plan did not need to change in the five months that followed. What changed was the requirements — three approved change requests, eight lines in the change log — and each time the plan already said who decided, where the new version went, and who had to be told.
Requirements management plan vs scope management plan vs RTM
| Document | Answers |
|---|---|
| Requirements management plan | How requirements are handled |
| Scope management plan | How the project’s scope is defined, checked and controlled |
| Requirements traceability matrix | Which requirement links to which work and tests |
| Requirements documentation | What the requirements say |
| Change control board charter | Who decides on changes, and up to what limit |
| Configuration management plan | What is versioned, and how versions are frozen together |
The scope that a scope management plan controls is written down in a project scope statement.
The plan describes; the matrix and the documents are the things it describes. A plan that says “all requirements are traced to tests” is worth nothing without the matrix that does it.
How to write a requirements management plan
- Write it before the first sign-off, while the rules can still be agreed without a dispute about a particular change.
- Start from what already exists. If the team keeps stories in Jira and documents in Confluence, the plan says so; it does not invent a new tool.
- Decide the IDs first. Everything else — traceability, change requests, the change log — refers to them.
- Name people, not departments, for writing, approving and deciding on changes.
- Put the change control rules in it, or point to the change control board charter.
- Keep it to two pages, and review it when the team or the tools change.
A lighter plan for agile teams
On an agile team, much of the plan is already in the team’s working agreements: the backlog holds the requirements, the product owner decides the order, and the definition of done says when a story’s criteria and tests are updated. What the backlog does not settle is worth writing down in half a page:
- Where the current requirements live, apart from the stories that changed them over time.
- How a change to a story that is already done is handled — a new story, linked to the old one.
- What needs sign-off outside the team, and on which version.
- How the requirements are traced to tests when someone outside the team asks.
Where Specroot fits
This is the problem Specroot works on: requirements kept with their IDs, versions, sign-offs, links and changes in one place — so that the plan describes how the project works, not a set of habits someone has to remember. Specroot for agencies and consultancies.
Read next
- Requirements change management: the process, with an example — Requirements change management step by step: request, impact analysis, decision, updating every document and test, and closing — with a worked example.
- Requirements traceability matrix (RTM): template and example — A free requirements traceability matrix template for Excel or Google Sheets, a filled-in example, forward and backward traceability, and RTMs in Jira and agile.
- Change control board (CCB): members, charter and process — What a change control board is, who sits on it, what it decides, a CCB charter template with an example, how a meeting runs, and CCB vs CAB vs product owner.