Requirements Management in PM²: turning needs into verifiable criteria
Sixteenth article in the “Learning PM² Through a Project” series
The statement “we need a booking feature” is not a manageable requirement. It expresses a need, but does not define who uses it, in what situation, under which rule, what result it must produce, or how correctness will be verified.
In PM², Requirements Management ensures that the project delivers what was actually agreed, rather than merely what the team interpreted.
What is a requirement?
A requirement describes a need, capability, condition or constraint that a solution must satisfy.
It can concern:
| Type | Example |
|---|---|
| Business requirement | Reduce no-shows in group classes. |
| User requirement | A member must be able to cancel a booking within a configurable limit. |
| Functional requirement | The system must automatically free the place and promote the first person on the waiting list. |
| Non-functional requirement | Place availability must update within five seconds under normal use. |
| Constraint | Access must use the authentication already present in Annotatio. |
Distinguishing these levels prevents a common error: discussing the technical solution before clarifying the problem and expected outcome.
A requirement’s lifecycle
flowchart LR
A[Elicit] --> B[Analyse and clarify]
B --> C[Document and validate]
C --> D[Approve and baseline]
D --> E[Implement and verify]
E --> F[Accept or manage change]
A requirement is not “done” when it is written. It is managed when it remains linked to its origin, the decision that approved it, the deliverable that implements it, and the verification that demonstrates fulfilment.
Characteristics of a good requirement
| Characteristic | Control question |
|---|---|
| Clear | Will two people interpret it in the same way? |
| Necessary | Does it contribute to a real need, benefit or constraint? |
| Complete | Does it state context, rules, exceptions and expected result? |
| Verifiable | Is there a test, acceptance criterion or objective evidence? |
| Feasible | Can it be delivered within available constraints, capacity and technology? |
| Traceable | Can we trace its origin, decision, implementation and test? |
Words such as “intuitive”, “fast”, “modern” or “easy” are not prohibited, but alone they are ambiguous. Turn them into observable conditions: for example, “a new member completes a booking in no more than three steps, without assistance”.
Requirements baseline: the reference point for change
When a set of requirements is analysed, agreed and approved, it becomes a baseline. From then on, it should not be modified informally.
This does not make the project rigid. It makes visible the difference between:
- clarifying an already approved requirement;
- fixing an implementation defect;
- proposing a change to a requirement or scope.
The last case requires Change Management: logging, impact assessment and a decision by the competent authority.
Traceability: why it matters
Traceability connects at least four elements:
| Link | Question it answers |
|---|---|
| Need / benefit → requirement | Why are we building this? |
| Requirement → deliverable or activity | Where is it implemented? |
| Requirement → test or acceptance criterion | How do we prove it is satisfied? |
| Requirement → change / decision | Why did it change, who decided and with what impact? |
A complex tool is not always needed. A small project may use a disciplined table; a large one may need a backlog or dedicated repository. The chain of evidence matters, not the software used.
The Annotatio case: from vague request to verifiable requirement
Initial request: “We would like to manage the waiting list better.”
One possible refinement is:
| Level | Statement |
|---|---|
| Business need | Reduce empty places caused by late cancellations. |
| User requirement | The manager must be able to define whether waiting-list promotion is automatic or manual. |
| Functional requirement | When a place becomes available, the system must notify the first member on the list; if they do not confirm within 30 minutes, it must move to the next member. |
| Acceptance criterion | In a test with three users on the list, the first receives the notification; after 30 minutes with no answer, the second is promoted and the event is recorded. |
This makes estimation, development, testing and acceptance possible. It also exposes questions hidden by the vague request: is the time configurable? what happens if push notification is unavailable? can the manager intervene? are there cancellation limits?
Validation and verification: two different actions
| Action | Question | Typical contributors |
|---|---|---|
| Validation | Are we specifying the right thing for the need? | PO, BM, users and business stakeholders. |
| Verification | Does the solution correctly implement what was specified? | Solution team, QA, PM and acceptance participants. |
A feature may pass every test and still create no value: it is then verified, but the requirement may not have been properly validated.
Do not confuse these
| Statement | Correction |
|---|---|
| “A requirement is a screen or technical solution.” | It can be at a detailed level, but it should first express a need, capability or constraint. |
| “If the client says it verbally, it is already in scope.” | It must be clarified, documented and approved according to governance. |
| “A passing test proves we built the right thing.” | It mainly proves implementation against a specification; validation concerns the need. |
| “A baseline blocks every change.” | It enables conscious, traceable management of change. |
Three questions to anchor it
- Which benefit or need justifies this requirement?
- How will you objectively demonstrate that it is fulfilled?
- If it changes after approval, what will be the impact on schedule, cost, quality and other requirements?
Flashcards
Q: What is a requirements baseline?
A: The set of analysed and approved requirements that becomes the controlled reference for delivery, verification and changes.
Q: What is the difference between validation and verification?
A: Validation checks that the right thing is being defined; verification checks that the solution correctly implements what was specified.
Q: What is traceability for?
A: To link need, requirement, implementation, test and change decisions.
Exam-style question
During testing, users ask to change waiting-list confirmation time from 30 to 10 minutes. The PM tells the team to change the parameter immediately because the request is small.
What is the correct approach?
Answer: first clarify whether the change alters an approved requirement or configuration and assess its impact. Even a small change may affect user experience, operating rules, testing and communication. If it changes the baseline, apply Change Management proportionately to the project.
Source
Requirements Management, the Requirements Management Plan and related logs are covered in the European Commission’s PM² Methodology Guide 3.1.
Next: Scope and Change Management, for keeping the project boundary under control without preventing useful changes.