Functional and non-functional requirements, and traceability

Two kinds of requirement, one requirements model

A functional requirement says what the system must do: a behaviour, a transformation of some input into some output, something a user or another system can ask for and watch happen. A member can cancel a reservation up to one hour before the pickup window opens is functional. You verify it by exercising the feature.

A non-functional requirement says how well, and under what constraints. Read it as a standard the system has to meet or a limit it has to stay inside: how good, how fast, how safe from attack, or what boundary somebody outside the project has already drawn around it. Those four readings are the usual taxonomy — quality, performance, security, constraint. The locker opens within three seconds of a valid scan is non-functional; so is member personal data is encrypted at rest; so is the reservation flow meets WCAG 2.2 AA. Both kinds are genuine requirements, both belong in the requirements model, both must be elicited, specified, validated and traced, and both are testable when written properly.

The difference that matters most in practice is where they live. A functional requirement usually sits inside one feature. A non-functional requirement usually cuts across many of them, and it usually drives the architecture rather than the function list — you cannot bolt a three-second response time onto a design that decided to round-trip every scan through a central server.

Why the non-functional ones are the hard ones

Stakeholders are lopsidedly good at describing function and bad at describing quality, because quality is what they assume rather than what they request. Nobody asks for a system that is usable; they notice its absence afterwards. Yet a system can be functionally complete and still be unusable, insecure, unaffordable to run, or illegal to ship — which is why non-functional requirements are so often the ones that decide whether the project succeeds at all.

They also conflict, with each other and with the functional set, far more often than functional requirements do. Encrypting every scan payload and opening the locker within three seconds are both reasonable and are in tension. So the non-functional set has to be prioritised, not merely collected.

Finding them deliberately: the two-phase method

Because they will not simply be volunteered, use a method. In the first phase you establish a set of software engineering guidelines for the system — best practice, plus the architectural style and the design patterns you intend to use — and you develop a list of candidate NFRs covering areas such as usability, testability, security and maintainability. Lay the NFRs out as columns and the guidelines as rows, and compare each pair, classing the relationship as complementary, overlapping, conflicting or independent. In the second phase you use that matrix to prioritise, applying decision rules that say which guidelines you will implement and which you will reject, so that what you end up with is a homogeneous, internally consistent set rather than a wish list.

Traceability: an instrument, not paperwork

Traceability means documented links between software engineering work products. It is realised as a traceability matrix: requirements label the rows, work products — design elements, components, test cases — label the columns, and a cell is marked where a link exists.

Describe it as documentation and you have missed what it is for. It provides continuity as a project moves from one phase to the next, whatever process model you are using; it is the evidence that every requirement has actually been taken into account by something; it is how you perform impact analysis when a requirement changes; and it is how you choose which tests to re-run. Its known weakness is decay — as the number of requirements and work products grows, keeping the matrix current becomes real, deliberate work, and a matrix nobody maintains is worse than none because it lies.

Worked example — three of each, and what one change costs

BorrowBox ships with three functional requirements in the core loop — reserve an available tool for a two-hour pickup window, cancel a reservation up to an hour before it opens, and charge a late fee for each overdue day — and three non-functional ones: the locker opens within three seconds of a valid scan, the service is available 99.5% of the time between 07:00 and 22:00, and the reservation flow meets WCAG 2.2 AA. Each functional requirement is verified by exercising the feature; each non-functional one needs a different instrument — a timed measurement on the target hardware, uptime monitoring across a release quarter, an accessibility audit plus testing with assistive technology.

Now change one. The board asks for a two-second locker response. Read the row: it names the architecture decision that pushed token validation to the locker's edge controller, two components, and nine test cases. That is your impact analysis, your cost estimate and your regression subset, in one line — and it is why the matrix is an instrument rather than an artefact.