User stories, functional specifications and acceptance criteria

Writing requirements that can be built, tested and signed off.

In this lesson

User stories with IDs and priorities
Acceptance criteria in Given/When/Then
Functional specs and traceability

Key points

As a <role>, I want <capability>, so that <benefit>
ID, MoSCoW priority, source, owner, status
Given/When/Then criteria for normal and exception paths
Traceability: requirement → solution → test → UAT result

Real-world example

A dispute about 'credit limit blocking' nearly derailed a go-live: the client meant 'block delivery', the consultant had configured 'warn on order'. The second project used Given/When/Then criteria signed in Sign; the same requirement was unambiguous and passed UAT first time.

Questions and answers

What goes in a developer handover beyond the story?

Fields, screens, rules, security, edge cases, test data and acceptance criteria.

Which document links requirements to tests?

The traceability matrix.

Read the full lesson, worked example and quiz