Functional Requirement

Requirements used to be written in a lump. "Add coupons to the checkout screen" was the whole document, and whoever built it filled in the rest. Writing less looks faster, but what goes unwritten doesn't disappear — someone decides it alone, later.

So kickoff meetings always went the same way. Theo would ask what happens when the coupon code is wrong, Mia would answer on the spot, he would ask what happens when the code has already been used, and she would answer on the spot again. Ten questions turned into ten improvised decisions, half of which never made it into the notes. Two weeks later, at review, someone says an expired coupon does nothing at all, and nobody can say what was decided that day.

A one-line requirement leaves every reader with a different picture. One person imagines a red error message on the screen, another imagines a hint under the input field, and the person who wrote the line never considered a wrong code arriving at all.

A functional requirement exists to surface that gap before anything is built. Instead of one line saying what to do, you write one sentence per case describing what happens under which condition. Every sentence you add is a question that won't be asked in a meeting.

One item is a single sentence carrying a subject, a condition, an action, and a result. "When a user enters a coupon code on the checkout screen, the discounted amount appears immediately" is the basic form, and if any of the four is missing, the reader supplies it themselves.

Five slots hang off that sentence.

1. Subject — who performs the action. Whether it's a user, an administrator, or the system acting on its own changes which screens have to exist. "The coupon expires" has no subject, so it doesn't say whether someone presses a button or time simply passes.
2. Condition — when the action happens. On checkout or in the cart, for signed-in users only, and so on.
3. Action and result — what happens and what appears, written as a pair. When the result is only a data change with nothing visible, say that too.
4. Exception paths — one line for each case that isn't the happy path. Wrong code, already-used code, expired code, order total below the minimum: each gets its own outcome. The unusual situations collected here are called edge cases, and most of the questions that come back from the team come from this slot.
5. Acceptance criteria — the conditions under which the item counts as done. Written as checkable sentences, so the person reviewing the work can walk the list one line at a time.

Once there are more than about ten items, add numbers and priorities. Separating what must be there from what would be nice to have means a slipping schedule doesn't require another meeting to decide what gets dropped, and numbering means "item three" in a review is enough for two people to be sure they're looking at the same sentence.

The writer is usually a single product manager — the person who decides what gets built and why, and who owns it through launch, which makes the case-by-case calls theirs. They don't write it alone, though. Engineers know the exception paths better, so the common order is a draft circulated for them to find the cases that are missing.

There are four kinds of readers, and each one looks at a different slot.

1. Engineers — read action, result, and exception paths, then answer how long it takes. One case versus five is a different answer, so an empty exception slot makes estimates swing by a factor of two.
2. Designers — count the cases to work out how many screens they owe. Four exception lines regularly become four screens.
3. Quality assurance (QA) — the people who check quality before release. They copy the acceptance criteria and exception paths straight into a test list, so a case that wasn't written down also goes unchecked.
4. Sales and customer success — check here what they're allowed to promise a customer.

An empty slot doesn't stop the document; it stops one reader at a time. With no exception paths, engineering starts while review has nothing to judge against. With a vague subject, a designer comes back asking how many screens to draw.

"There isn't a single exception in these functional requirements. What happens when the code is wrong?"

Only the happy path is written down, so the work can't be built.

"That's a speed question, not a functional requirement. I'll put it in the slot below."

It describes a quality condition rather than a behavior, so it belongs somewhere else.

"Scope for this sprint is functional requirements one through four."

Drawing a boundary by number to agree on what ships and what waits.

The week Pagedeck was preparing its coupon feature, Mia sent Theo seven items. What came back wasn't an estimate but three questions: does a coupon return after a partial refund, which discount wins when a coupon overlaps an existing one, and what happens if the coupon expires mid-checkout.

Mia turned the three answers into items and the document grew to ten. The three added lines put four more days on the schedule — days the work always needed, which simply hadn't appeared on anyone's calendar until they were written down.

The most common mistake is reading a functional requirement as a screen description. Results usually show up on a screen, so the confusion is understandable. But what belongs here is what the product must do; where and how that lands on a screen is the next step's problem. Mix the two and you get sentences like "the coupon field sits above the pay button" in the requirements, and every layout change forces an edit to the requirements document.

The second mistake is assuming that detail takes judgment away from the people building. The guess is that tighter instructions leave less room, but what gets tighter is what to build, while how to build it stays untouched. What message an expired coupon shows is a product decision; how that screen is structured in code is an engineering one. Blur that line and the builder ends up making product decisions too, and those only surface at review.