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.comThe 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.
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:
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:
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?
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.
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?
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"This path looks very tenuous, which suggests that the requirement should be dropped or be categorised as 'nice to have' or 'cosmetic'.
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?
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
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
Traditional software style format
Example of an Agile method format
As a/an | I want to.... | So that.... |
---|---|---|
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.
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:
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:
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 analyzed 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)
Requirements Management Checklist
Requirements Gathering Template
Requirements Traceability Matrix
More Project Templates to download!
- Microsoft Project Plans – real world project plans in Microsoft Project.
- Project Management Templates – All of our FREE project management templates in Word and Excel
PMBOK Management Plans
- 20 Common Project Risks