Requirements Management Plan Template

Requirements Management Plan Template | FREE Download

This PMBOK template sets out how project requirements will be managed. Use this template to capture all of the key information you need. 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.

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 Tips to Complete

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:

Prepare a list of questions in advance.
Use whiteboards to sketch out processes or screens.
For existing systems ask users to walk through everyday tasks explaining what they do and don’t like.
Create mock ups to draw out details and clarify requirements.
Keep the Business Case & Return on Investment (ROI) in mind. Requirements should help meet the reason for investment, not just be a wish list of exciting functionalities.

Requirements Analysis

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

At stakeholdermap.com we recommend you also analyze the predicted impact on the Business Case objectives. You can ask the following questions:

Does the requirement directly contribute to one of the project objectives?
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 center 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 color 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 color"
Path to reduction in handling time:

users feel a personal connection to the software

users use the software more?

users are more productive?

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.

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.

Change Management

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 analyzed and how changes will be reviewed and approved.