You Shouldn't Necessarily Build What The Client Asks For

Discovering the requirements for any software application is hard, even if the people building it are going to be the people using it. In Chapter 6, Testing, I explored the notion that everybody has their own idea of what the software should do, and in Chapter 7, Architecture, the fact that some requirements are not made explicit. So, if you just asked everyone for a list of things the software should do and built that, it'd be rife with conflicts and probably wouldn't do everything that any one person wanted from it.

While it's an inaccurate way of finding out what software should do, asking people is one of the easiest and most accessible methods. You can interview people with either a directed questionnaire or an open-ended discussion, finding out what they think of the system of interest and hopefully teasing out some of those tacit requirements. You can also get a group of people together, as a round-table discussion...