Required reading: Gause and Weinberg show how to ask for what you want
By David Walker (Google profile)
"So, what do you want it to do?"
This looks like such a simple question. But this query - posed every day about Web sites, other software, indeed about buildings and cars and furniture and all sorts of designed objects - is one of the toughest questions that can be asked of an organisation. It triggers the requirements process. A thirteen-year-old book by Donald Gause and Gerald Weinberg, "Exploring Requirements" ($US44.95 at Amazon), shows how to manage that process. Most Web developers and managers haven't read it, and should.
Like the man startled to find he had been speaking prose all his life, most of us have taken part in a requirements process, and many of us don't know it. Requirements analysis is actually a life skill that can be applied particularly often in your working life. If you've had an architect design renovations, or a friend build you a PC, or a large consulting firm build you a business reporting system, then you've been on the end of a requirements process, formal or informal. If you've ever designed or built something, and seen a disappointed look on the recipient's face, you've experienced requirements failure. If you've ever had a client rave about how great a Web site is, you've achieved requirements success.
Like that other classic, DeMarco and Lister's "Peopleware", "Exploring Requirements" makes ample use of large numbers of measurements collected over many years - like the numbers showing that programers are quite good at producing what they are actually asked to produce, if only they are asked to produce it. This data allows Gause and Weinberg to enunciate a simple principle: you'll quite likely get what you want, as long as you say what it is.
Saying what you want, though, takes surprising amounts of both discipline and technique. It requires people to think about their own needs in a ruthlessly structured way, to listen to others' needs, to understand how their business is now and imagine what it could be in five years' time. No wonder that success in IT-related requirements processes is rare, and that failure is the norm.
The continued popularity of "Exploring Requirements" springs partly from its authors' simple but thorough style: they explain the key challenges concisely and clearly. Their breadth helps too: their chapters cover everything from holding effective meetings to scoring client preferences to measuring ambiguity. Context also plays a role: Gause and Weinberg always explain why their preferred solutions work better.
And the book shows a sense of fun, notably in its periodic anecdotes about fictional and slightly dysfunctional requirements processes for a pair of products called Superchalk and Do Not Disturb.
But the enduring strength of Gause and Weinberg's book can only be fully explained by their willingness to talk about requirements at an emotional level - about what a tough, confronting, challenging task it is for so many of the people involved, and about the perils and delights of having one person understand what another person is thinking, hoping and sometimes hiding even from themselves. Mindreading is tough, and Gause and Weinberg aren't afraid to admit it.
For instance, Gause and Weinberg include an entire chapter on setting expectations, teaching designers to identify the possible and the impossible early so as to minimise a client's disappointments.
Their last substantive sentence demonstrates perhaps most clearly their focus on the emotional challenge of requirements work:
"The purpose of requirements work is to avoid making mistakes, and to do a complete job. In the end, however, you can't avoid all mistakes, and you can't be omniscient. If you can't risk being wrong, if you can't risk being inadequate to the task you've taken on, you will never succeed in requirements work. If you want the reward, you will have to take the risk."
Understanding other people is hard - hard enough to justify reading 300 well-written pages about it. These are the 300 pages to read.