39 of 39 people found the following review helpful:
5.0 out of 5 stars
A classic that will be around a decade from now, March 26, 2001
This review is from: Exploring Requirements: Quality Before Design (Hardcover)
In the decade since I last read this book I've gained a wealth of experience in requirements elicitation and management. So why bother re-reading the book and taking the time to write a review? Because I strongly believe that this is one of the classics and should be *required* reading by anyone in the IT profession (it also crosses over into just about any profession).
What makes this book a classic? After all, we practitioners have software tools such as DOORS and Requisite Pro, advanced techniques such as quality function deployment, specialized modeling languages such as UML, and a keener understanding of the importance in business rules.
All of these innovations and advances are technical in nature. The authors address something much deeper and more fundamental that will apply a decade from now: human nature and critical thinking. They lead you to an understanding of these keys to exploring requirements, and they do so in with subtle humor, common sense and clear writing. One example of how they delve into the deeper subjects of human nature and critical thinking is a true story about an advertisement for a "cockroach killer" that is guaranteed to be 100% effective. After your initial chuckles die down you begin to see things in a different way. The authors lead you from this humorous story into one discussion or example after another and how they apply to requirements. By the time you finish this book you will begin looking at the requirements process in a different way, and perhaps, the world around you as well. You will also approach the requirements elicitation and management process differently - all of a sudden those wonderful requirements management software tools and techniques will become the infrastructure of the process instead of the necessities for performing that they too often become.
This is not a technical book. If you are looking for advanced techniques look elsewhere. This book is about shaping how you see things, think and apply principles to "techniques". I personally believe it will remain a classic for many years to come, and strongly encourage IT professionals, regardless of their technical specialty, to read it.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
44 of 46 people found the following review helpful:
5.0 out of 5 stars
Essential Reading, July 24, 2000
This review is from: Exploring Requirements: Quality Before Design (Hardcover)
By no means have I read everything there is to read on the subject of software requirements, but I've not read anything better than this book. What I really like about this book, and about Weinberg's writings in general, is that it does not get bogged down in a bunch of academic methodology mumbo jumbo. Gause and Weinberg's approach is imminently practical and free of buzzwords and complicated steps and models and CASE tools. No special equipment or licensing is required in order to take the advice in this book and make a huge difference in your current and future projects.
That said, do not let me give the impression that this book is vague or that it does not get into specifics or that it does not contain some useful step-by-step approaches. It is not vague at all, and it gets into plenty of specifics. What impresses me the most is the way it achieves complete coverage of the subject without bogging down or becoming boring. After reading this book, it is very likely that you will not feel the need to read much else on the subject of software requirements.
Now, what is most amazing is this: this is *not* specifically a book about *software* requirements. It is about any kind of requirements for any kind of project that requires a design, be it a new and better mousetrap or a large software system. My comments have used the term "software requirements" because this is why I read the book, and why I think a lot of people will read it. But this book is for anyone who must specify the requirements for something that must be designed and/or built, no matter what field you are in. The lessons here are so univeral that it does not matter which context you use them in. Essential reading.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
22 of 22 people found the following review helpful:
5.0 out of 5 stars
Required Reading: Gause & Weinberg teach how to ask and get, May 27, 2002
This review is from: Exploring Requirements: Quality Before Design (Hardcover)
"So, what do you want it to do?"
It 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" 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 requirement 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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
