Requirements that work
A requirement is only useful if a developer can build it and a tester can prove it. This lesson turns the phone-order findings into a set of requirements Lagoon Digital can estimate and test: functional and non-functional requirements with numbers, business rules kept apart in a decision table, a data dictionary, and the requirements for the move itself.
By the end you can
- Sort a requirement into business, stakeholder, solution (functional or non-functional) or transition, and say why the class matters
- Rewrite a vague request into atomic, testable requirements with a source and an acceptance measure
- Make non-functional requirements measurable, using the ISO/IEC 25010 quality model as a checklist
- Write business rules once, as rule statements and a decision table, and turn the table into code and tests
- Define the data the solution needs, and the transition work that gets people and data across
The everyday picture
Think of ordering a birthday cake from a bakery. "A nice big cake, not too sweet" is what you want, but the baker cannot bake it. The order slip the baker can use says: chocolate sponge, 24 cm round, serves 16, less sugar in the icing, "Happy 40th Ama" in blue, ready Saturday at 10 am. Each line is one thing, and you can check each one when you pick the cake up.
The bakery also has house rules: 48 hours' notice, a deposit of half the price. They hang on the wall, the same for every customer, and only the owner changes them. If the bakery moves to a new shop next month, there is a third list: move the ovens, keep the old phone number working. That list disappears after the move. Requirements work the same way: what the solution must do, the rules it must follow, and what the move needs.
Four classes of requirement, one chain
In Stakeholders and elicitation you found five reasons shops still phone, and in Modelling processes you drew the to-be process. Now you write down what must be true for that future to work. The BABOK Guide sorts requirements into four classes, and each answers a different question.
- Business requirements say why the organisation is doing this, as goals and measures. BR-01: raise the share of partner orders placed in the Partner app from about 62% to 75%, and cut corrections after delivery from about 125 to under 60 a week.
- Stakeholder requirements say what a group of people needs from the change. SR-01: a shop owner can reorder the regular items while serving customers, in about a minute. SR-02: finance credit control can approve or decline a one-off credit increase without email.
- Solution requirements say what the solution must do or how well. Functional requirements describe behaviour: FR-07, the cart shows the shop's available credit before checkout. Non-functional requirements describe qualities: NFR-02, the cart with 30 lines opens within 2 seconds for 95% of opens on the slowest supported phone.
- Transition requirements say what is needed to move from today to the future, and then they expire. TR-01: all 40 sales reps are trained in rep mode before the first rollout wave.
The classes form a chain. Every solution requirement should point up to a stakeholder requirement, and every stakeholder requirement up to a business requirement. That link is what you will use for traceability in From change control to acceptance. A requirement with nothing above it is a feature nobody asked for. A business requirement with nothing below it is a goal nobody is working on.
Quick check
"During the 8 weeks of rollout, reps can still take phone orders and the back office still keys them in." Which class is this?
It describes a temporary state during the change and will be removed once the app is the normal channel. Calling it functional would leave a requirement in the product backlog that nobody should build into the app.