LEARN. PRACTICE. GROW.1. Start with the problem and the people
A fictional team reconciles fund movements every morning. The initial request is to buy a tool, but the observed problem is time spent distinguishing repeated files from legitimate corrections. Before choosing a solution, describe who performs the work, the intended outcome, and where exceptions arise. Listen to analysts, overnight support, and the process owner. An interview reveals one person’s experience; a session using examples helps compare interpretations. Record disagreements and who can clarify each rule. The project coordinator facilitates this discovery without assuming that the most experienced person has authority to approve every need.
2. Write criteria that support a decision
A requirement such as the dashboard must be fast leaves room for incompatible interpretations. Ask which operation matters, who performs it, at what volume, and under which conditions. In this exercise, stakeholders agree to measure the 95th percentile of search time for 30 concurrent users against a defined dataset. The numerical threshold should come from the need and an informed decision, never an arbitrary choice by the coordinator. Include functional criteria, such as distinguishing a repeated file from a correction, and relevant operational conditions. A criterion supports accepting or rejecting an observed result; a document’s existence does not demonstrate that the behavior was implemented.
3. Follow the chain from need to evidence
Use stable identifiers to connect need, requirement, component, test, and acceptance decision. One row might contain N2, R7, importer, T7, version 3, and a pending result. This structure helps locate needs without implementation and changes without appropriate tests. If T7 passed on version 2 and R7 changed in version 3, the link remains useful, but the earlier result does not demonstrate the new behavior. Assess impact before deciding what to repeat. Also check the reverse direction: a feature without an identified need may represent unnecessary work or a need not yet documented. The matrix guides questions; it does not replace technical judgment or approval.
4. Resolve requests with explicit authority
In a project with approved scope, additional retention can affect storage, operations, schedule, and budget. Record the reason for the request and prepare options, including keeping the existing solution, adjusting the request, or changing commitments. Identify who decides under the applicable governance. The person writing meeting minutes may lack authority to approve spending. In adaptive delivery, needs are also analyzed and prioritized; having a backlog does not remove financial constraints or necessary formal decisions. Communicate the outcome and update affected elements after the appropriate decision. Do not confuse a favorable conversation with authorization that the process explicitly requires.
5. Prepare a release decision
A release needs its own criteria, necessary components, and evidence appropriate to its risk. In the fictional case, importing movements and applying permissions are essential for safe reconciliation; exporting charts is desirable. If capacity is insufficient, present an option preserving the goal and deferring less necessary work, with visible consequences. A dashboard showing 20 of 21 tests passed does not establish readiness if the blocked test covers a mandatory requirement. Explain what is demonstrated, what is missing, and who can decide on the situation. An authorized exception, where the process allows one, must remain distinct from a passed test; it does not retroactively rewrite evidence.
6. Guided exercise and summary
Build a small matrix for three requirements: import a valid file, reject a duplicate, and allow support-led recovery. Define someone responsible for clarifying each rule, an observable test, and the target version. Imagine that the first two tests pass and recovery has not been exercised. Write a two-sentence status that preserves progress and exposes the gap. Then add a retention request and identify affected decisions and evidence. The expected result is an understandable chain between need, commitment, and demonstration. Check for vague language, forgotten groups, results from earlier versions, or approvals attributed to someone who merely collected information.
Fictional example: R1 imports a file, R2 rejects a repeat, and R3 enables support-led recovery. R1 and R2 passed on version 3; R3 is blocked. Correct status distinguishes partial technical delivery from pending acceptance.
Common pitfalls
Counting documents as evidence, accepting results from another version, confusing a recipient with an approver, and hiding a mandatory requirement inside an aggregate percentage.
Related topics: Discover requirements and validate outcomes · Stakeholders and communication
Each requirement needs an identifiable need, testable criteria, and applicable evidence. Requests and gaps should reach the person with authority to decide.
Reference: Project management and business analysis · CAPM ECO 2023; official outline consulted 2026-09-29