A visual guide to the steps and documents involved in requirements management.

What is Requirements Management?

Requirements management is the process of defining, documenting, prioritizing, and tracking the requirements in any project. Requirements are the features and functions that the solution must provide to meet the needs and expectations of the stakeholders. Requirements management helps to ensure that the project delivers the right solution, on time and within budget.

Why is Requirements Management Important?

Requirements management is important because it helps to:

• Clarify the scope and objectives of the project
• Align the expectations and requirements of the stakeholders
• Reduce the risk of scope creep, rework, and defects
• Improve the quality and usability of the solution
• Facilitate communication and collaboration among the project team and the suppliers
• Support the decision making and governance of the project

Everything flows from the Requirements Catalogue

The following diagram shows the process of requirements management for a project. 

The process consists of the following steps and documents:

Requirements Catalogue: A document that lists and describes the requirements of the software project, including the functional and non-functional requirements, the acceptance criteria, and the priority and status of each requirement.

Evaluation Matrix: A document that compares and evaluates the different suppliers and their quotes based on the criteria and weights defined by the project team.

Supplier Evaluation: A step that involves assessing and rating the performance and satisfaction of the supplier and the software solution.

Supplier Quote: A document that provides the estimated cost, time, and resources required to deliver the software solution that meets the requirements.

Statement of Work: A document that describes the scope, deliverables, milestones, and responsibilities of the software project.

Test Strategy: A document that defines the testing methodology, techniques, tools, and standards for the software solution.

Full Business Case: A document that provides the justification and rationale for the software project, including the benefits, costs, risks, and alternatives.

Contract: A document that defines the terms and conditions of the agreement between the project team and the supplier.

Purchase Order: A document that authorizes the purchase of the software solution from the supplier.

Decision: The Senior Responsible Officer (“SRO”) will sign the Contract and Approve the Purchase Requisition once they are satisfied that there is a business case

Mobilise resources: A step that involves securing and allocating the necessary human, financial, and technical resources for the software project.

Deliver solution: A step that involves developing, testing, and deploying the software solution that meets the requirements.

Test Plan: A document that outlines the objectives, scope, approach, and schedule of the testing activities for the software solution.

Test Preparation: A step that involves designing and preparing the test cases and the test environment for the software solution.

Test Execution: A step that involves executing the test cases and verifying the results against the requirements and the acceptance criteria.

Purchase Invoice (“PI”): A document that requests the payment for the software solution from the project team.

Receipt Goods: A step that involves receiving and inspecting the software solution from the supplier. The output of this step is the…

…Goods Receipt Notice (“GRN”):  A document that acknowledges the receipt and acceptance of the software solution from the supplier.

Payment: A document that confirms the payment for the software solution to the supplier.

Who are involved?

Project Team: The group of people who are responsible for planning, managing, and delivering the software project.

Governance: The process of monitoring, controlling, and reporting the progress, performance, and quality of the software project.

Control Points

Authority to Go To Market: There is nothing stopping a project team obtaining a quotation and Statement of Work from a potential supplier. However, the governance of an organisation would stop them entering into a contract. To this end, most potential suppliers would ask the question “do you have the budget approved for this project?”.

Authority to Implement: This is the key decision as to whether the project will commence. In the PRINCE2 methodology this is the completion of the Initiation Phase and the start of the Implementation Phase. If the PRINCE2 approach is being followed then there will be a “contract” between the SRO and the project manager in the form of a Project Initiation Document (“PID”).

Authority to Release: If the testing has gone well then the project manager will request that the solution is brought into live service. This can happen in many ways but the phrase “brought into live service” is a financial term used to say that the asset (the solution delivered by the project) can be transferred to the balance sheet and be depreciated from the point that it has come into live service. The financial transfer happens when the project team receipt the goods listed on the Purchase Order.

Purchase Invoice Approval: The PI approval route will usually follow the same steps of authorisation as the Purchase Order. So, ultimately, this will go back to the SRO. The SRO will confirm with the project manager that testing has been successful. The test strategy will have set out up front the tolerance for what is acceptable.

Authorisation of Payment: The Accounts Payable team will match the Purchase Invoice, the Purchase Order and the GRN. If they are all in order then payment will be made to the supplier

• Next Entry: What is Augmented-AI