Five stages · one path
A requirement outlives the sprint it was filed in
What happens to a requirement between the moment someone says it out loud and the moment it reaches production — and what the analyst does on each of the five stretches of that road.
Stages
Every stage receives an artifact and hands one on
The order is not decoration. Things break at the seams, so the material is grouped by handoff rather than by role.
01
Requirements
Where a task comes from, how to tell a finished spec from a draft, and where responsibility ends.
See the material →
02
Analysis
Data model, scenarios, non-functional requirements, and tracing a requirement through to its check.
See the material →
03
Development
What the analyst does while the code is written.
See →
04
Testing
Acceptance, defect triage, disputed cases.
See →
05
Deployment
Release, migrations, feedback into the next spec.
See →
Who this is for
People already doing the work
Systems and business analysts, product analysts, and team leads who inherited the spec. There is no introduction to the profession here — only the places where a requirement usually breaks. It is not meant to be read straight through: most of the time you need one piece for one situation.
RU / EN
Glossary
The vocabulary of the profession is English while much of the work is not, which is where the expensive misreadings start. Both forms, with notes on where the translation drifts.
Open the glossary →
Index
Full contents
Everything by stage, marked for what is written and what is still in progress.
Open the contents →