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 O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.