Contents
The five stages a requirement passes through
Each stage receives an artifact from the one before and hands its own to the next. Things break at the seams.
01 — Requirements
How a task becomes a task
- 01.1 Definition of Ready: a finished spec and its imitation The signs that a task should not be taken into a sprint yet. →
- 01.2 Scope boundaries: what is inside the work and what merely sits nearby The unnoticed stakeholder, and a spec with no edge. →
- 01.3 Where a task comes from: interviews and the questions that uncover the real need Request, need and problem; the last case instead of the general rule. →
- 01.4 Goal and success metric: writing down “why” so acceptance has something to compare The baseline before release, the counterweight, and metrics that mislead. →
02 — Analysis
A requirement becomes a description
- 02.1 Traceability: linking requirement, implementation and check Why the matrix dies, and where the chain actually breaks. →
- 02.2 Scenarios and exceptions: the main flow takes an hour, the alternatives a week Six questions for every step, and who decides what happens off the main flow. →
- 02.3 The data model for analysts: entities, relationships and the data dictionary Three questions per entity, relationships as business rules, the data dictionary. →
- 02.4 Non-functional requirements you can actually test Property, value, conditions, method — and where to get the number. →
- 02.5 Describing an integration: the API contract from the analyst’s side What to do with each error, the unknown outcome, and retries without duplicates. →
03 — Development
What the analyst does while the code is written
- 03.1 Requirement change mid-development: edit the spec or file a new task Telling an edit from new work, and not losing the change on the way. →
- 03.2 Developer questions about the spec: a question log, and where the answers go An answer exists only once it is written in the ticket. →
- 03.3 Demos during development: what to show before it’s done without getting a new spec What to show, how to run it without promises, where the remarks go. →
04 — Testing
Checking what was actually ordered
- 04.1 Bug or omission in the spec: triaging disputed defects Four kinds of divergence, and who decides when the spec is silent. →
- 04.2 Acceptance criteria: from requirement to check, Given/When/Then, and when you don’t need it Boundaries, negative cases, and a table of examples instead of a retelling. →
- 04.3 Test data: who describes it, and why “it works on staging” States rather than records, time as data, and old records. →
05 — Deployment
The task reaches the user
- 05.1 What to check after a release: the first day in production for an analyst A check plan, old data, and the rollback decision made before the deploy. →
- 05.2 Data migration: field mapping, dirty records and reconciliation after the move A rule for every field, decisions on dirty records, a reconciliation table. →
- 05.3 Feedback from production: tickets and incidents as a source of new tasks A channel from support to the analyst, and which complaints become tasks. →
Templates
Ready-made forms for the pieces
Forms you can copy into your own spec. Each links to the piece that explains why it is built the way it is.