What Good Requirements Look Like (and How to Write Them) | Projan Blog Use cases<br>Engineering & TechnologyProductCreative & StrategyBusiness DevelopmentConsultingFounder EducationPublic Sector & Non-profit<br>Integrations Pricing Blog<br>Log in Sign Up<br>A good requirement states one thing that someone can check. It names who does what and under what conditions, and it says what must be true rather than how to build it. The quickest test is to read it back and ask how you would demonstrate it had been met. If nobody in the room can answer, it is a wish.

This is about the individual requirement on the page: what a strong one looks like, and how to write one. Which document it belongs in, and how you get the information out of people, are separate jobs. Everything below works one sentence at a time.

What do good requirements look like?

A good requirement is short, singular and checkable. The widely agreed quality attributes are that it should be unambiguous, testable, necessary, feasible, complete, consistent with the rest of the set, and traceable to a reason. They appear in ISO/IEC/IEEE 29148, the requirements engineering standard, though nobody needs the standard in front of them to use them.

Unambiguous. Two people reading it separately build the same thing.

Testable. You can describe how you would demonstrate it is met.

Necessary. Delete it and something a user or the business needs stops working.

Feasible. It can be built inside the constraints you have, not the ones you wish you had.

Complete. It does not rely on a fact that exists only in someone’s head.

Consistent. It does not contradict another requirement in the same document.

Traceable. Six months later you can say who asked for it and why.

That list is easy to nod at and hard to apply. Here it is applied to five ordinary sentences.

Weak versionWhat goes wrongStronger versionUsers can export and email reports.Two obligations in one line, so half can fail while the line is ticked.Split it. “A user can export a report as CSV.” and “A user can email an exported report to any address in their own organisation.”Reports must be approved before publication.No actor, so at build time somebody picks one.A finance manager must approve a report before it can be published.The system supports relevant file types.Unbounded set, so the reader decides what relevant means.Uploads accept PDF, PNG and JPEG files up to 10 MB. Anything else is rejected with a message naming the accepted types.A confirmation email is sent when an order is placed.Silent on failure, so the failure path gets invented under pressure.A confirmation email is sent within 60 seconds of an order being placed. If the send fails, the order remains valid and the failure is queued for retry.Admins can manage users.”Manage” hides five behaviours with different permissions.An admin can create, deactivate and reset the password of any user in their own organisation. Admins cannot delete users.<br>Notice what the stronger versions cost. Each needed a decision: which formats, whose approval, what happens on failure, whether deletion is allowed at all. That is the actual work. The writing is the cheap part, which is why vague requirements are so popular.

Testability is the test that catches everything else

If you cannot describe how you would demonstrate a requirement is met, it is not a requirement. It is a preference, and it should be written down as one so nobody gets held to it in a release review.

Two sentences fail this more often than everything else combined.

“The system should be fast.” Fast where, for whom, doing what, under what load? Made testable it becomes something like: “Order search returns results in under two seconds for 95% of queries with 200 concurrent users.” Three decisions had to happen to write that. Someone chose the operation that matters, someone chose the percentile, and someone accepted the number. Until then, fast means whatever the reader hopes, and readers are optimistic.

“The interface should be intuitive.” This one does not survive being made testable, which is useful information. It can become a usability target with a task attached: “A user who has not seen the product before completes a booking unaided, verified with five participants in moderated testing.” Usually it becomes nothing instead, because someone has to say who the user is and which task counts, and nobody wants to be the person who narrows it.

That is the honest part. Making a requirement testable does not improve the writing. It forces a decision someone has been postponing. The vagueness was doing a job: it let a meeting end.

The numbers are not really a writing decision either. Somebody has to accept them, and that somebody is rarely the person holding the keyboard. Where getting them all in a room is the obstacle, Projan asks in Slack or Microsoft Teams instead, requesting the figure behind each adjective and recording who agreed to it before the requirement is exported to Jira.

Where no...