Requirements Management Plan Template | FREE Download

The Requirements Management Plan sets out how project requirements will be managed including how requirements will be identified, categorised, analysed, measured, tracked and validated. It is related to the Scope Management Plan and can be combined with it on small projects. stakeholdermap.com
The document is created with inputs from the Project Charter, development approach and the Quality Management Plan. It forms part of the Project Management Plan and aligns with change management, scope management, the release and iteration plan, development approach and the requirements backlog.

The completed plan drives the Requirements log and Traceability Matrix, and is and input to the Risk Register and Quality Management Plan.

Use this FREE template to document how requirements will be managed on your project . This template includes all of the areas you need to cover, with includes useful hints and tips to help you complete each section.
Requirements Management Plan Template

This is a FREE Requirements Management Plan Template in Word and PDF. The template is fully editable with Microsoft Word and can be converted or changed to suit your project requirements.

See what is in the Template! Check out the Contents complete with Hints and Tips on how to use.

Check out the contents below or Grab the template now!

The contents of the Requirements Management Plan Template

Field

Field Description and guidance completion

 

Project details and document control

Provide information on the project and document:
  • Project Name and Reference
  • Document information: ID, owner, issue date, last saved date, file name or path
  • Document history: version, issue date, changes.
  • Document approvals: role, name, signature, date
 

Requirements Collection

Set out how the requirements will be collected. This might be via user workshops, interviews, brainstorming, or review of enhancement requests or product reviews.

Hints and tips:
 

Requirements Analysis

Explain how the impact and usefulness of each requirement will be analysed, so that a priority, and category can be determined.

At stakeholdermap.com we recommend you also analyse the predicted impact on the Business Case objectives. You can ask the following questions:
  • Does the requirement directly contribute to one of the project objective?
  • If there is an indirect connection how many assumptions need to be true for the requirement to meet the objective?
The second question may seem a little strange, so let’s look at an example. Say we are gathering requirements for call centre software and have a key business objective to reduce average call handling time. A user-level requirement to allow service desk agents to change the user interface colour scheme will allow agents to configure their screen in a way that is pleasing to them, but we would have to make several assumptions to connect that requirement to a reduction in call handling time.

A good test is to try to map out the connection between the requirement and the objective. For example, will this requirement lead to a reduction in handling time?
Requirement: "Users can change their screen colour"
Path to reduction in handling time:
  1. users feel a personal connection to the software
  2. users use the software more?
  3. users are more productive?
  4. greater productivity means a reduction in call handling time?
This path looks very tenuous, which suggests that the requirement should be dropped or be categorised as 'nice to have' or 'cosmetic'.

In comparison a requirement for a knowledge base that provides service desk agents with template responses to common questions would have a direct contribution to reducing average call handling time.
 

Categories

Document categories you will use for requirement grouping. A common categorization is:
  • High-level requirements
  • User-level requirements
  • System-level requirements
System-level requirements are often divided into functional and non-functional.
 

Documentation

Describe how the requirements will be documented including the format and fields that will be used. Often requirements are gathered using a simple Excel spreadsheet, or Word document although specialist software also exists. Some examples:

Example of an Agile method format
As a/an I want to.... So that....




Traditional software style format
Type Business Function/Category Requirement Priority




 

Prioritisation

Describe the way that requirements will be prioritised. Some will be mandatory to meet with regulations, security, company policy or the forecast ROI. Others will be ‘nice to have’, but not essential to meet the business objectives.

For example, MoSCoW could be used. In this case requirements would be grouped as:
Must have – mandatory requirement
Should have – functionality or feature that should be available.
Could have – desirable or nice to have
Won’t or would have – not required but might be a future release.

You might also use a numerical scale – 1 to 10 or a simply high, medium, low.
 

Requirement / Product Metrics

Describe the metrics that will be used to measure requirements. For example, 99.9% availability, withstand x psi, near-real time etc.

This section may also be used to document how the success of the requirements process will be measured. For example:
  • how many change requests were needed due to missed or unclear requirements?
  • was any delay caused due to missed or unclear requirements?
  • were any requirements re-prioritized e.g. found to be nice to have rather than mandatory?
 

Traceability Structure

Show how the requirements will be traced through the product lifecycle from identification to delivery. Typically, a document called a Requirements Traceability Matrix will be used which will record the requirement ID, and corresponding:
  • Business objective/KPI
  • Project objective
  • WBS ID
  • Product design and development
  • Test cases
 

Progress Tracking

Explain how progress will be tracked. For example, through requirement checkpoints or progress meetings.
 

Reporting

Document what reporting is needed on the requirements, including report purpose, format, frequency and audience.
 

Validation

Explain the methods that will be used to validate the delivery of the requirements. For example, testing, audits, inspection, demonstration, proof of concept, beta version etc.
 
Describe how you will manage requirements changes. Including, new and changes to existing approved requirements. Set out the information that will be captured for each change, how the impact will the analysed and how changes will be reviewed and approved.

Requirements Management Plan Template

Word download - Requirements Management Plan Template (Word .doc)

PDF download - Requirements Management Plan Template (PDF)

 

Other Project Templates to download

 

 
 


Support stakeholdermap.com
If you liked this page, feel free to recommend us!