System Requirements: Link Each Need to a Design and a Test

Turn a need into something you can check

“The loan desk needs a better system” describes dissatisfaction, but it does not say what a successful solution must do. A useful requirement names an observable outcome. A design explains how to produce that outcome. A test supplies a starting state, an input and an expected result so someone can check whether it happened.

This fictional equipment-loan desk keeps only item identifiers and quantities. It is a paper exercise about decisions, not a live borrowing service. It does not collect borrower names, contact details or other personal records. All quantities refer to complete items, so fractional requests are invalid.

Three people, three needs

• The desk operator needs to recognise a valid item request.
• The storekeeper needs to avoid issuing more items than are available.
• The reviewer needs a clear decision that can be compared with the stock calculation.

For the exercise, the agreed starting stock is K11: 8, K22: 3 and K33: 0. Reset to those quantities before every independent acceptance check. Requests are processed one at a time. Returns, reservations, purchases and tracking individual borrowers are outside this small model.

These boundaries matter. A request to “show who borrowed K11” cannot be answered from quantities alone. Adding a name field without discussion changes the problem, the data collected and the checks required. The first version should be judged against the needs actually agreed.

The requirement–design–test matrix

Assign stable identifiers so a change can be followed through the work. R1 names a requirement, D1 its design choice and T1a a particular check. The numbers are convenient classroom labels, not a prescribed assessment format. One requirement can need several tests because different inputs follow different paths.

For R1, check the ID before the quantity. If both are invalid, report the unknown ID first and leave every stock quantity unchanged. For a known ID with invalid quantity, show its unchanged available quantity. This explicit priority avoids two testers expecting different error messages for the same request.

The paper form

Separate supplied input from calculated output. A remaining-quantity box is not a number the operator chooses. Complete the following form with a pencil; use the starting stock list to fill the lookup result.

In words, look up the item, validate the quantity, compare the quantity with availability and calculate only after acceptance. Report the entered ID and quantity alongside the decision. For an unknown ID, “not listed” is the remaining-stock response; zero would incorrectly suggest that the item exists with no stock.

Worked case 1: an invalid request

Start with K11 available = 8 and a request for 1.5 items. K11 exists, but 1.5 is not a whole number. R1 therefore requires rejection with all stock unchanged. R2’s subtraction must not run. The output reads: K11; requested 1.5; reject invalid quantity; remaining 8.

A design that rounds 1.5 to 2 silently changes the request. That would be a different requirement and needs an explicit agreement. Validation is a decision about whether the supplied value meets the rule; it should not invent an acceptable replacement.

Worked case 2: enough stock, then too much

For independent test T2a, reset K11 to 8 and request 3. Since 3 ≤ 8, accept and calculate 8 − 3 = 5. For T2b, reset again to 8 and request 9. Nine exceeds availability, so reject and retain 8. Subtracting first would create −1, which is neither a valid balance nor an acceptable intermediate saved result for this rule.

Also test equality: requesting all 8 must be accepted, leaving 0. If a design used quantity < available instead of quantity ≤ available, ordinary requests might pass while this exact-stock request fails. The boundary comes from the agreed requirement.

Worked case 3: check the report, not only the arithmetic

For K22, 2 items from 3 leaves 1. Correct subtraction alone does not satisfy R3. A report that says only “Done” omits the item, request and balance. Conversely, a report saying “Accept; remaining 1” is misleading if stored stock still says 3. Check both the decision output and the resulting stock on paper.

The following acceptance record is a worked simulation of the corrected paper design. “Observed” means the result of walking that design, not evidence from a deployed application. Each row also checks that the entered ID and quantity appear in the result and that other items remain unchanged.

A passing row provides evidence for its linked requirement under those conditions. It does not establish performance under many simultaneous users, recovery after a power failure or suitability for real personal data. Those would need separately agreed requirements and tests.

Three decisions to practise

1. “The desk must be fast” is proposed as a requirement. Is it testable? Not yet. Ask which action, what maximum time, which equipment and what starting conditions are intended. A possible agreed paper criterion is “The result contains the decision and remaining quantity after one completed request.” That is observable, but it does not claim a response-time guarantee.
2. A test checks that requesting 9 from 8 displays a refusal. What is missing? Verify that K11 still holds 8 and the other items retain their starting quantities. R2 requires preserved stock, so checking only the message can miss a serious design fault.
3. A reviewer asks to add equipment returns. Should a return button simply be added? No. Record the proposed change and agree its rules first, including permitted quantities and the maximum stock. Then add or revise requirement IDs, the design and acceptance checks. The existing issue-only tests cannot establish correct return behaviour.

Keep the evidence connected

When a test fails, record the input, expected result and observed result rather than rewriting the expectation to match the design. Check whether the requirement is genuinely ambiguous. If it is changed by agreement, update the linked design and checks together. Retain a clear distinction between a changed need and a corrected implementation.

Reference for traceability

NASA’s Requirements Verification Matrix guidance explains linking identified requirements with a verification approach. The desk scenario, requirement wording, design and acceptance record here are original.