EC-14.1 Requirements and Constraints, Written Down

What this is and why it exists

Almost every failed student project failed here, before any building started, because nobody wrote down what the thing had to do.

This topic is the cheapest intervention in the whole area. An afternoon of writing at the start regularly saves a term.

It is also the entry point for the capstone, which is why it carries no prerequisite of its own. A reader can arrive here first and it will still make sense.

The vocabulary

Requirement — something the system must do, stated so it can be tested.
Constraint — a limit you cannot move, such as cost, size or a mandated interface.
Preference — something someone would like, which may be traded away.
Stakeholder — anyone whose interests the design affects.
Functional requirement — what the system does.
Non-functional requirement — how well, under what conditions, and at what cost.
Baseline — an agreed set of requirements at a date, against which changes are recorded.

The mental model

A requirement is testable or it is not a requirement.

The system shall be fast is not testable, because two people will disagree about whether it was met and neither will be wrong. The system shall respond within two hundred milliseconds for ninety-nine out of a hundred requests is testable, because there is an experiment that settles it.

The practical technique is to write the test alongside the requirement. If you cannot describe the test, the requirement is not yet written, and discovering that now costs a sentence rather than a term.

Three kinds of statement get mixed together and separating them is most of the work.

A requirement is what the thing must do. A constraint is a limit you cannot move: a budget, a package size, a mandated connector. A preference is what somebody would like and would trade away for something else.

Mixing them is how a project acquires impossible goals. Every preference has been promoted to a requirement, and the set as a whole cannot be satisfied. Asking, of each line, whether the project fails without it usually sorts them in ten minutes.

Stakeholders are more numerous than they first appear. The user, the person who pays, the person who maintains it, and the person who has to certify or approve it.

Discovering the fourth of these late is a common and expensive surprise. Anything involving mains voltages, radio transmission, or data about people has an approval step, and its requirements are not negotiable once the design is finished.

Then there is the requirement that is really a solution. It must use a particular sensor is almost always somebody's earlier decision arriving disguised as a constraint.

Ask what that sensor is for. The answer is the real requirement, and it usually reopens the design to alternatives that are cheaper or available.

Non-functional requirements are where projects actually fail. Power, size, cost, temperature range, expected lifetime, safety, and who has to be able to service it.

These rarely appear in the original request, because the person asking assumes them. They decide whether the finished thing is usable, and eliciting them is a large part of what the first conversation should be for.

Finally, the baseline. Agree a set of requirements at a date, and record every change against it.

Without a baseline nobody can say whether a project is late, because the target has moved without anyone noticing. A project with changing requirements and no baseline is always on schedule and never finished. That is the state most student projects are in until the deadline arrives.

What you should now be able to explain or do

Write a requirement that has a test, and reject one that does not.
Separate requirements, constraints and preferences in a list somebody handed you.
Identify the four kinds of stakeholder, including the one who approves.
Recognise a solution disguised as a requirement and recover what it was for.
Elicit the non-functional requirements nobody thought to state.
Baseline a requirement set and record changes against it.

Check yourself

How do you tell whether something is a requirement?

Ask what test would demonstrate it. If you cannot describe the test, it is a preference or an aspiration, and it will be argued about at the end instead of now.

A brief says the design must use a particular sensor. Is that a requirement?

Usually not. It is somebody's earlier solution. Asking what the sensor is for recovers the real requirement and reopens the choice to alternatives.

Which stakeholder is most often discovered late?

The one who has to approve or certify the work. Their requirements are not negotiable and arrive after the design is finished, which is the expensive time to find them.

What does a baseline give you?

A fixed target to measure against. Without one, requirements drift, the project is never measurably late, and nobody notices until the deadline.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Requirements and Constraints, Written Down: work through the checklist