When a requirement changes
In short: Requirements change, and that is normal. It is dangerous when a change goes through without a record. Impact analysis starts from the changed requirement and follows the matrix to the tests and to the dependent requirements. A requirement has versions, and the baseline is the agreed set of versions the team works against. A change after it goes through a request, an assessment and an approval by the person responsible for the requirement.
Problem
The test that "got it wrong"
On Monday, at a meeting, marketing says: "From today free delivery starts at 60 €." The developer changes the number the same day.
On Tuesday the test "A cart of 50.00 €: delivery is free" fails. QA records a defect: "Delivery is 4.90 € for an order of exactly 50.00 €". The developer closes it: "That is what was asked for." QA asks: "Where is it written?" Nowhere. The requirement still says 50 €, and so does the help page on the site.
Two days go on arguing whose version is right. The change was not wrong. What was wrong is that it went through without a record.
The idea
Impact analysis
Before something changes, you ask: what else depends on it? This is impact analysis. The matrix from the previous lesson makes it quick:
- Find the row of the changed requirement.
- Every tick in the row is a test that has to be reviewed.
- For each such test, decide: it changes, it stays the same, or it is no longer needed.
- Ask which new tests the new rule needs.
"Reviewed" does not mean "changed". The threshold becomes 60 €. "A cart of 120.00 €: delivery is free" is reviewed and stays the same. "A cart of 50.00 €" changes: it is now 4.90 €. And two new tests are needed, at the new boundary: 59.99 € and 60.00 €.
Beyond the tests, the impact reaches other things too: the cart screen, the help page, the advertising, the accounting report. The matrix shows the tests. The analyst knows the rest, and often so do the stakeholders.
Try it
The return period becomes 30 days
Mark the links. Then, in the second step, choose which tests have to be reviewed for the change.
Tests
- T-1: Received on 1 October, return requested on 15 October: accepted.
- T-2: Received on 1 October, return requested on 16 October: refused.
- T-3: A shipped order, not delivered yet: the return is refused.
- T-4: A paid order, not shipped yet: the cancellation is accepted.
- T-5: A shipped order: the cancellation is not accepted.
- T-6: A delivered order, return on the fifth day: accepted.
Press the cell where the test checks the requirement; press again to remove the link. The arrow keys move between the cells, Space or Enter marks.
| Requirements | T-1: Received on 1 October, return requested on 15 October: accepted. | T-2: Received on 1 October, return requested on 16 October: refused. | T-3: A shipped order, not delivered yet: the return is refused. | T-4: A paid order, not shipped yet: the cancellation is accepted. | T-5: A shipped order: the cancellation is not accepted. | T-6: A delivered order, return on the fifth day: accepted. | Covered by |
|---|---|---|---|---|---|---|---|
| R-1 A product can be returned within 14 days of receiving it. | 0 | ||||||
| R-2 Only a delivered order can be returned. | 0 | ||||||
| R-3 A paid order can be cancelled before it is shipped. | 0 | ||||||
| R-4 A shipped order cannot be cancelled. | 0 | ||||||
| Checks | 0 | 0 | 0 | 0 | 0 | 0 |
The reference matrix
- R-1: T-1, T-2, T-6
- R-2: T-3, T-6
- R-3: T-4
- R-4: T-5
Which tests have to be reviewed? T-1, T-2, T-6. “T-2” changes: 16 October is now accepted. “T-1” and “T-6” stay right, but “T-1” is no longer on the boundary. Two new tests are needed too: 31 October (accepted) and 1 November (refused).
The matrix says three tests: the ones in the row of R-1. T-6 is in the analysis because it checks the period too, even though it is also about the delivered order. The cancellation tests (T-4 and T-5) do not depend on the return period.
The idea
Requirements depend on each other
Sometimes the change is in one requirement, but the number is in another one too. The 50 € threshold is in two sentences:
- R-1: delivery is free for an order from 50.00 € inclusive;
- R-2: under 50.00 € delivery is 4.90 €.
You change R-1 to 60 €, and R-2 stays at 50 €. Now an order of 55 € is neither free nor under 50 €. The two requirements contradict each other.
That is why the analysis does not stop at the row in the matrix. It also asks which requirements depend on the changed one. A well-kept list records these links too, between the requirements. Then R-2 comes up in the analysis by itself, and its tests with it.
The idea
Versions and the baseline
A requirement is not overwritten. It gets a new version:
| Requirement | Version | Text | From | Decided by |
|---|---|---|---|---|
| R-1 | 1 | free delivery from 50.00 € | 1 March | the owner |
| R-1 | 2 | free delivery from 60.00 € | 16 November | the owner, at marketing's request |
The old version stays. A customer with a 55 € order from last week is entitled to free delivery: by version 1, which applied then.
The baseline is the agreed set of requirements, each in an exact version, that the team works against. For example "the requirements for the release on 16 November". The tests and the matrix are linked to it: "T-1 checks R-1, version 1". When someone says "according to the requirements", the baseline answers the question "which ones?".
Once the baseline is agreed, a change is not made at a meeting, with a single word. It follows a path.
More precisely, if you are curious
IREB CPRE covers versions, configurations and baselines in its chapter on requirements management. A configuration is a set of requirements, each in one version. A baseline is a configuration that is stable and agreed, often for one release, and changes only through the established change procedure.
In BABOK v3 the related tasks are in the Requirements Life Cycle Management knowledge area: Maintain Requirements (requirements are kept correct and with their history) and Approve Requirements (the agreement and approval after which requirements can be used as the basis for work). The term "baseline" is used in both, in slightly different words, so learn the definition from the syllabus you are taking the exam in.
The idea
Who approves the change
The path of a change has three steps, and each belongs to a different person:
- Request. Anyone can ask for a change: marketing, a customer, the warehouse. The analyst records it: what, why, from when.
- Assessment. The analyst, QA and the developers say what it touches and what it costs. This is the impact analysis.
- Decision. The person responsible for the requirement and the budget decides. In Scrum that is the Product Owner. In a large organisation it can be a Change Control Board, with the business, the technical people and QA.
The one who decides is not the one who asks the loudest, nor the developer who will change the number. The one who decides sees the cost and says "yes", "no" or "yes, but from next month".
This is change control. In an agile team it is light: changing a story that is not in progress yet is a conversation with the owner and a new line in the list. It is heavy for changing something that has already been agreed, built or released.
More precisely, if you are curious
BABOK v3 describes the assessment of changes as the task Assess Requirements Changes (in the Requirements Life Cycle Management knowledge area). How decisions about changes are made and who approves them is agreed earlier, in planning the governance of requirements (Plan Requirements Governance), and approval is the task Approve Requirements.
IREB CPRE describes the Change Control Board and the change request as part of requirements management. How formal the procedure is depends on the project: in a regulated field every change has a signature, while in a small team a record and a conversation are enough.
ISTQB CTFL v4.0.1 (section 1.4.4) lists impact analysis of changes among the benefits of traceability.
Try it
The path of a change
Put the path of the threshold change in order, from the request to the release.
The product owner decides, seeing the costImpact analysis: requirements, tests, screens, textsMarketing wants the free delivery threshold to become 60 €The analyst records the change requestThe change goes live on the date in the new versionThe tests change, the developer changes the threshold and everything passesThe requirement gets a new version and the baseline is updated
The decision comes after the assessment: the owner has to see the cost before saying "yes". The developer changes the number after the new version of the requirement, not before it. Otherwise you get the Monday from the start of the lesson.
Exercise
The threshold becomes 60 €
1. The free delivery threshold. The change is in R-1, but not only there.
Mark the links. Then choose which tests have to be reviewed when the threshold becomes 60 €. Watch where else the number 50 appears.
Tests
- T-1: A cart of 50.00 €: delivery is free.
- T-2: A cart of 49.99 €: delivery is 4.90 €.
- T-3: A cart of 120.00 €: delivery is free.
- T-4: A cart with no products: the order is refused.
- T-5: The cart holds 10 T-shirts. Adding one more is refused.
- T-6: A cart of 55.00 €: delivery is free.
Press the cell where the test checks the requirement; press again to remove the link. The arrow keys move between the cells, Space or Enter marks.
| Requirements | T-1: A cart of 50.00 €: delivery is free. | T-2: A cart of 49.99 €: delivery is 4.90 €. | T-3: A cart of 120.00 €: delivery is free. | T-4: A cart with no products: the order is refused. | T-5: The cart holds 10 T-shirts. Adding one more is refused. | T-6: A cart of 55.00 €: delivery is free. | Covered by |
|---|---|---|---|---|---|---|---|
| R-1 Delivery is free for an order from 50.00 € inclusive. | 0 | ||||||
| R-2 Under 50.00 € delivery is 4.90 €. | 0 | ||||||
| R-3 An empty cart cannot be ordered. | 0 | ||||||
| R-4 The cart holds at most 10 of a product. | 0 | ||||||
| Checks | 0 | 0 | 0 | 0 | 0 | 0 |
The reference matrix
- R-1: T-1, T-3, T-6
- R-2: T-2
- R-3: T-4
- R-4: T-5
Which tests have to be reviewed? T-1, T-2, T-3, T-6. The threshold is also in “R-2”: “under 50.00 €” becomes “under 60.00 €”, so “T-2” is reviewed too. “T-1” and “T-6” change: at 50.00 € and at 55.00 € delivery is now 4.90 €. “T-2” and “T-3” stay right, but “T-2” is no longer on the boundary. The new tests are 59.99 € and 60.00 €.
The row of R-1 gives T-1, T-3 and T-6. But R-2 depends on the same number: "under 50.00 €" has to become "under 60.00 €". That is why T-2 is reviewed too. Of the four tests, two change (50.00 € and 55.00 €) and two stay. The cart (T-5) and the empty order (T-4) do not depend on the threshold.
Test