Requirements, User Stories & Acceptance Criteria

Every product starts with someone saying “we need a thing that does X.” That sentence is a product requirement — a plain statement of what the product must do or be. The trouble is that requirements on their own are slippery. “Make checkout faster” sounds clear until three people picture three different things. This lesson is about turning that fuzzy wish into something a team can pick up, build, and prove they finished.

The chain is short and worth memorising: a requirement captures the need, a user story frames it from the customer’s point of view, and acceptance criteria define exactly what “done” looks like. Get this chain right and you stop the classic disaster where engineering builds precisely what was asked and the customer still says “that’s not what I meant.”

From need to story to “done”

Think of it as a funnel. The need is wide and vague at the top; by the bottom it’s narrow, testable, and unarguable.

The requirement: the raw need

A requirement is just the need stated honestly: “Customers abandon their basket because checkout takes too long.” It does not say how to fix it, and it should not. Its job is to capture what and why, leaving the how to the people who build it. Good requirements are written in the customer’s language, not in solution-speak. “Add a one-click button” is already a solution in disguise; “shorten the time it takes to pay” is the real requirement.

The user story: the need, told as a person

A user story rewrites the requirement from the point of view of the person who has the need. The classic shape is three parts: As a [type of user], I want [some goal], so that [some benefit]. For our checkout example:

As a returning shopper, I want to pay without re-entering my card details, so that I can finish buying in seconds.

That single sentence does a lot of quiet work. The As a names who — and forces you to admit a new shopper has a different need from a returning one. The I want names the goal in human terms. The so that captures the benefit, which is your sanity-check: if you can’t finish the “so that,” the story probably isn’t worth building. Notice it still says nothing about buttons, screens, or code. A story is a promise to have a conversation, not a spec.

Acceptance criteria: the definition of “done”

A story tells you what someone wants; acceptance criteria tell you how you’ll know you delivered it. They are a checklist of conditions that must all be true before the work counts as finished. Write them so that anyone — a tester, a product owner, the customer — can read each line and answer yes or no without arguing.

For the returning-shopper story, acceptance criteria might be:

• A returning shopper who is logged in sees their saved card at checkout.
• They can complete payment without typing their card number.
• If the saved card is expired, they are clearly asked to update it.
• A first-time shopper still sees the normal full payment form.

If two reasonable people can disagree about whether a criterion is met, it is not yet acceptance criteria — it is still a wish.

Notice that good criteria also cover the edges: the expired card, the brand-new shopper. That is where most “but it doesn’t work” complaints come from. Spelling out the unhappy paths up front is what separates a story that ships cleanly from one that bounces back and forth for a week.

Spot it: requirement, story, or criterion

Read each statement and decide what it is — then tap a card to check.

Sort the parts

Drag each statement into the bucket where it belongs — requirement, user story, or acceptance criterion.

How to use it

Next time someone hands you a vague ask, run the chain out loud. Start by repeating the requirement back in plain terms: “So the real need is that returning customers find checkout slow — is that right?” Then reframe it as a story: “As a returning shopper, I want… so that…” and watch whether the room nods or frowns. Finally, ask the question that saves projects: “How will we know it’s done?” and write the answers as a checklist everyone can see. When a teammate says “that’s basically finished,” you can point at the list and ask which boxes are actually ticked. Those three moves — restate the need, frame the story, list the criteria — turn hand-waving into something a team can confidently build and confidently call done.