I found this on the shelves of the college library. The writing has the feel and layout that you find later in the QSM 4-volume series.
The book explores why so much goes wrong in "gathering" requirements, and employs fascinating experiments, models and metrics to get a better handle on the human communication difficulties involved.
Recommended.
--BobLee November, 2002
Ambiguity. Too many ideas. Not enough ideas. Precisely solving the wrong problem. Ignoring expectations. Fear of ending. -- lb
Okay, so what does go wrong when gathering requirements?
I will speak in terms of building software and systems which is what I do.
The error starts with the idea of "gathering", as if requirements literally grew on trees to be picked up from the ground where they fell. Or to be "gathered" like a group of people, a tourist group perhaps. "OK, people. Let's gather round the flag here, and it's off to the bus again once we have a headcount." Requirements that are clear, concrete, consistent, relevant, valuable, and implementable neither grow on trees nor collect themselves. Creating requirements is a synthetic act. "What would be a useful artifact, in this little piece of the world?" It's a process of inventing a possible future, really, one with chocolate cake in it a few hours from now, because I have you imagine now a future clearly enough that it can be made real.
Developing requirements is at least these things:
Software requirements formalisms (the IEEE template, for example) inventory one set of considerations, and can lead to stimulating some of these conversations. Techniques for formal analysis of requirements can help address completeness, consistency, and precision. That's good stuff, actually, to help us build what we set out to build. But these formalisms don't guarantee that anyone will give a damn about the thing we built, to it's fine consistent specs. Other methods focus on requirements in context, getting buy in and exploring points of view, and imagining wonderful futures. These tools don't guarantee that the artifact imagined is buildable, or the imaginings are self-consistent, or even comprehensible.
There are even techniques - processes and handbooks - for requirements "gathering" from interested parties, forms and templates, and scripts for meetings, and sorting / collating criteria for all the administrivia of moving requirement statements from potential users of the thing, through into a consolidated, indexed pile. That's also good and useful, and sometimes a system is viable - makes sense to build - only if you can get a fair number of the requirements nailed down fairly well, fairly early in the process. Assembling requirements early has it's risks, as does discovering them later along the way. So requirements are also risks, and timing, and about how you choose to manage ambiguity and change.
What can go wrong with gathering requirements? Treating it only like "gathering" and becoming focused on the formal correctness are the two biggest failure modes. This book, ExploringRequirements, is about the process of exploring requirements. It's about ways to discover the needs, and do the synthesys, and know when you don't quite have something, and build relationships while you're doing it. This book is an interesting combination of the study of human interaction with a catalog of common fallacies, packaged as stories and techniques. If you choose to internalize the contents of this book, your thinking will be broader, deeper, and clearer because of it. Any time we contemplate acting intentionally there are requirements involved. It's helpful to have some ways to get clear about what you are trying to do.
-- JamesBullock
![[Home]](/wiki.gif)