Software Craftsmanship & Practice
Requirements & Communication
Requirements are discovered through conversation and concrete examples, not gathered once and handed off as a frozen document — a spec written too early just ossifies the team's current misunderstanding of the problem.
- "Work with a user to think like a user" — the best way to understand a requirement is alongside the people who'll live with it, not through a one-time interview
- Concrete examples surface edge cases a description never would — "show me an example of that report" beats "describe the report format"
- Document requirements as a shared project vocabulary/glossary — capture the intent behind terms, not implementation detail that will drift out of sync
- Abstractions live longer than the details built on them — capture why, since the how will keep changing
- A detailed early spec feels like reduced risk but is often a frozen misunderstanding — see Tracer Bullets And Prototyping for getting something real in front of users instead
The instinct to "gather requirements" as a discrete upfront phase treats understanding the problem as a one-time data-collection exercise, when in practice a project's understanding of what it actually needs keeps sharpening the entire way through — new edge cases surface once real users touch a real (even partial) system, and a document frozen at kickoff has no mechanism for absorbing that. Treating requirements as an ongoing conversation, not a phase that ends at a sign-off, means the team's understanding stays current instead of stale.