Chapter 10. Specify Collaboratively
Traditional software specifications come with one problem: They need special care to do them well. Once you have nailed them down, though, they quickly become obsolete for different reasons that you may be able to influence or not. For example, if a competitor releases a new feature in its software, your requirements may change in an instant in order to keep your market share. Since this is clearly a nontechnical decision, someone with a business background has to at least participate in that decision.
The more diverse opinions you can get in your requirements process, the clearer the picture of the application gets. In general, there are at least three different perspectives that you should include. On the ...
Get ATDD by Example: A Practical Guide to Acceptance Test-Driven Development 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.
