From change control to acceptance
Requirements keep moving after you write them, and somebody has to prove that what was built does the job. This lesson shows you how to link every requirement to its reason and its tests, judge a change request with real impact analysis, run user acceptance testing with Ravi and the pilot shops, and measure after go-live whether the project met its objectives.
By the end you can
- Build a traceability matrix from objective to requirement, story, test and release, and use it in both directions
- Work out the impact of a change request against a baseline and send it to the right decider
- Plan UAT with named testers, entry and exit criteria, and scenarios taken from the to-be process
- Triage UAT findings into defects, changes and training gaps, and sign off against written criteria
- Evaluate the solution after go-live against the objectives you set at the start
The everyday picture
Think of a tailor making a suit for a wedding. On the first visit she writes everything on a card: the measurements, the cloth, the wedding date, and why you want the suit (you will dance a lot). When you come back and ask for a second pair of trousers, she does not just start cutting. She writes the change on the card, tells you it adds four days and some money, and asks you to choose.
At the fitting she does not inspect the seams with you. She asks you to sit, raise your arms, walk and dance a few steps, because that is what the suit is for. Problems go into three piles: a fault she fixes for free, a new wish that is a change, and a habit you need to learn (this jacket is meant to be worn open). After the wedding, she asks how the suit felt by midnight. Requirements work ends the same way: a written agreement, changes judged against it, a fitting built on real use, and a check after the event.
Traceability: every requirement has a reason and a proof
The project "Phone orders into the app" now has objectives from What business analysts do (app share from 62% to 75%, corrections from about 125 to under 60 a week), findings from Stakeholders and elicitation, a to-be process from Modelling processes, requirements and rules with IDs from Requirements that work, and stories from User stories and acceptance criteria. Traceability is the set of links that ties all of this together.
The links run in two directions. Backward tracing answers "why does this exist?": every story points to a requirement, and every requirement points to an objective or a stakeholder need. Forward tracing answers "is it done?": every requirement points to the stories that build it, the tests that check it and the release that ships it. The BABOK Guide calls this task Trace Requirements, part of the Requirements Life Cycle Management knowledge area, and names four kinds of link: derive (a requirement comes from a higher one), depends (one cannot be done or is not useful without another), satisfy (a solution part meets a requirement) and validate (a test checks a requirement).
Most teams keep the links in a traceability matrix. It can be a spreadsheet or links between items in the team's backlog tool. Here are four rows of yours:
| Objective or need | Requirement | Stories | Tests | Release |
|---|---|---|---|---|
| O1 app share 75% (credit finding) | RULE-03, FR-08 ask for a one-off increase | ST-14, ST-15 | TC-5, TC-6, UAT S2 | R1 pilot |
| O2 corrections under 60 a week | RULE-05 pack size as case or unit | ST-6 | TC-3, UAT S6 | R1 pilot |
| O1 app share (speed finding) | FR-14 rep mode during a visit | ST-20 | none | R1 pilot |
| none | FR-16 order history as a spreadsheet | ST-27 | TC-12 | R2 |
Each gap tells you something. Row three has no test, so nobody will prove that rep mode works before the pilot. Row four has no objective. It came from a demo comment and will use Lagoon Digital's time without moving either objective, so you ask who needs it before it stays in release 2. The matrix pays for itself in three jobs: impact analysis (what else moves when this changes), coverage (is every must-have built and tested) and proving value (which objective each release serves).
Keep it light. Trace at the level where you make decisions: objective, requirement, story, test, release. Tracing every sentence to every screen becomes a second job nobody keeps up, and an out-of-date matrix is worse than none, because people trust it.
Quick check
The head of partner sales asks, "Is everything we need for the credit problem ready for the pilot?" Which trace do you follow?
"Is it ready" is a coverage question, so you start at the need and walk forward: requirements, stories, tests and whether those tests passed. Backward tracing answers why something exists. A vendor status report tells you what was built, not whether it meets the need you traced.