Requirements and User Stories

From need to task

A business need is usually stated as a wish (“customers should be able to download invoices”). Your job is to turn it into something that can be built and verified. The path often runs from a need, to a story, to a few technical tasks.

The user story format

As a <type of user>
I want <some goal>
so that <the benefit>.

Example: “As a customer, I want to download my invoice as a PDF, so that I can attach it to my expense report.”

The “so that” part matters most. It tells you the real goal, which often allows a simpler solution than the one first imagined.

Acceptance criteria

Acceptance criteria say when the story is done. They should be specific enough to test. A common style is Given, When, Then:

Given I am logged in and have an invoice from last month
When I choose "Download PDF"
Then I receive a PDF with the invoice number, lines and total

Without criteria, “done” means different things to different people.

Do not confuse them with the Definition of Done. Acceptance criteria belong to one story. The Definition of Done is the team’s shared checklist that applies to every story (for example reviewed, tested, documented, deployed to test). A story is finished only when it meets both.

Functional and non-functional

• Functional requirements describe behaviour: what the system does.
• Non-functional requirements describe qualities such as performance, security, availability and accessibility. They are easy to forget and expensive to add late.

Questions to ask

• Who is the user, and what are they trying to achieve?
• What happens in the error and edge cases (no data, no permission, very large input)?
• What is out of scope for this story?
• How will we know it works? See Why Testing Matters.
• Can it be split into a smaller piece that delivers value on its own? See Incremental Problem Solving.

Stories are often grouped into larger epics, and sized with estimation. Questions asked early cost less than rework later.

Try it

Take a ticket you have been given or can find in your team’s backlog. Rewrite it in the user story format, add three acceptance criteria and list two questions you would ask the author before starting. If you cannot write the criteria, the requirement is not clear enough yet.