Over the past 30+ years, the way we investigate, analyze, capture and communicate requirements has changed at a much slower rate than the way we do the rest of software development. Use cases shifted things a bit and the more recent user stories have had some impact, but while the productivity of design and development activities have improved dramatically over the last 30 years, comparatively, requirements activities are still stuck in the quill pen era.
Improving requirements activities means adopting different ideas about what it means to investigate requirements, to reappraise what it means to communicate requirements and to fundamentally rethink the role of requirements in software development projects.
Being aware of the distinction between explicit and implicit constraints helps, but it is not enough.
- Some requirements can just be documented, they are well known and understood (the explicit constraints)
- Some requirements emerge as part of conversations (the implicit constraints)
- Some requirements do not really exit yet, they have to be invented