Chapter 16. Requirements: Documentation or a Conversation?
At the end of the day, if the software doesn't meet the user's needs, it is still lousy software, regardless of how it was created.
The traditional software engineering approach to software development assumes that requirements are relatively static. As such, it is assumed that requirements can be documented, agreed on, and then signed off with change control procedures put in place to control scope creep on projects.
Unfortunately, the studies that exist suggest that requirements change. Data from Capers Jones suggests that more than one percent of requirements change for every month of project duration [Jones, 1994, p. 93]. No wonder there have to be special practices in place for freezing ...
Get Questioning Extreme Programming now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
