Summary of "Requirement Specification vs User Stories • Dave Farley • GOTO 2023"

Overview

Dave Farley (Continuous Delivery) explains why poor requirements are a major cause of software failure and how user stories—when used correctly—fix the core problem.
Core message: requirements should state what users need (the “what”), not prescribe how the system should be built (the “how”). User stories are an effective tool to keep that separation.

Definition of requirement

“A condition or capability needed by a user to solve a problem or achieve an objective.” — IEEE

Requirements should be brief, outcome-focused, and avoid implementation detail.

The common problem Many organizations treat requirements as detailed, implementation-focused specifications (“painting by numbers”), which locks in design and makes later changes costly.
Developer responsibility Teams should own product outcomes, not just code. Users and product owners often only know vague goals; translating those into executable behavior is the development team’s job.
Agile & user stories User stories are not separate from requirements — they are requirements when written correctly: outcome-focused and non-technical. Stories act as a “shortcut” to force separation of what vs how.
Practical example Consider firmware/device-driver for a scientific instrument with a 6-hour calibration. Instead of specifying UI steps, think of user goals (for example, “start calibration and get confirmation so I can go surfing”). That reframing surfaces useful requirements such as progress feedback, early failure notifications, monitoring, and retry behavior.
Stories vs interface Focus on the user’s mental model and goals (what they need to be aware of, what actions they need to take if something fails), not on UI controls or internal processes.

Capture outcomes, not implementations: avoid mentions of databases, input fields, button clicks, or other system-specific technical details.
Keep stories succinct and intentionally high level: accurate enough to capture the goal, vague enough to allow multiple solutions.
Use plain language so non-technical stakeholders can read, prioritize, and cut scope effectively.
Structure stories like real stories: title, characters (users), narrative (context & need), and resolution (what success looks like).
Test a story by imagining a completely different system delivering the same outcome (voice control, thought control, different UI). If it still makes sense, it’s likely a good story.
Watch for team behaviors that demand over-specification (e.g., refusing work unless detailed specs are provided) — this signals a need to rebuild trust and exploration skills.
Separate requirements discovery (explore user goals, iterate) from design/implementation (generate multiple solution options). Eradicate tendencies to conflate what and how.

Clearer communication for non-technical stakeholders, enabling better prioritization and scope reduction.
Better context for technical teams, supporting deeper understanding and freedom to choose appropriate solutions.
More durable requirements that change only when user goals change.
Easier experimentation and iteration: lower cost to change implementation when the desired outcome is well defined and decoupled.

In highly constrained technical problems (for example, strict communication protocols), it can be harder to find a high-level story, but usually a user-focused goal can still be identified.
Avoid blaming product owners or users for vague requirements — it is expected they will be imprecise; development is the process of translating those vagueries into working systems.

Write user stories that describe user outcomes / outcomes-of-value.
Remove implementation details from stories.
Use stories to enable conversations and iterative discovery.
Developers must be active participants in defining product needs, not only implementers.
Validate stories by imagining alternative implementations and by ensuring they are understandable to non-technical reviewers.