Requirements Management Plan Template

Elicitation approach, RACI, requirement attributes, prioritisation, baseline and change control, traceability, metrics

Вимоги та аналізСтандартmanagement plan mathОновлено 20 жовт. 2026 р.

Як використовувати: Use it at project start to agree how requirements will be handled from elicitation to acceptance. Agree roles and change control thresholds with the sponsor first. The main pitfall is a plan too heavy for the team to follow.

Перегляд

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

Схожі шаблони

Вимоги та аналіз