A requirement states a user need, constraint, or capability that software is expected to satisfy. It should describe what users need rather than prematurely prescribing implementation details. section 1.2 section 1.2.4
Requirements become unreliable when one product owner gathers stakeholder input, translates it into implementation-focused user stories, and hands them to isolated developers. Direct collaboration creates shared understanding and reduces assumptions and quick fixes. section 1.2
Use requirements as a basis for collaborative design:
- Involve stakeholders and developers together instead of relying on a single handoff. section 1.2
- Separate user needs from technical requirements and implementation decisions. section 1.2 section 1.2.4
- Treat requirements as changeable because users often revise their assessment after interacting with a feature. section 1.2.4
BigScreen’s back-office reporting
Back-office users needed comprehensive theater-performance data and accurate handling of extended movie runs. Instead, they depended on developers for database queries and Excel exports, while extended runs were entered as new movie schedules. The resulting workaround produced cumbersome analysis, inaccurate data, and inaccurate metrics. section 1.2
Figure 1.4 Detailed diagram of the Waterfall process
Compare requirements treated as a fixed handoff with the changing feedback loop characteristic of software development. section 1.2.4
