(with Donald C. Gause)
* ISBN: 0-932633-13-7 320 pages hardcover
Dorset House Publishing
(translated into Japanese, Portuguese, German, Chinese)
This volume is now available as a 2-part ebook.
Sample and/or Buy the 2-part ebook through:
KINDLE
Barnes & Noble
Smashwords
“provides an excellent set of principles amply illustrated by relevant and thought-provoking examples.” – Barry Boehm, UCLA
“Anyone who wants to build a product should understand this book.” – Watts S. Humphrey, Software Engineering Institute of Carnegie Mellon University
“Consciousness raising for systems analysts.” – Tom DeMarco, Principal, Atlantic Systems Guild
“It’s likely that this book will not only give you concrete ways to improve our requirements gathering process, but will also change the way that you look at requirements.” – Elisabeth Hendrickson, Quality Tree Consulting
“Twelve years after it first appeared, this book is completely relevant to today’s development projects.
“. . . most companies would benefit greatly from improving the way they define requirements. This book will help you do that, and I recommend it to anyone who has anything to do with software development.” – Richard Mateosian, IEEE Micro
“. . . a superb new book on systems analysis. . . . you simply must read and absorb this gem. It complements every brand-name systems analysis methodology currently being practiced.” – Ed Yourdon, American Programmer
“This extraordinary book grabbed me from the Preface through to its end. Well written, readable, and paced comfortably. . . . Highly recommended. . . . sure to change how you develop requirements for your projects.” ohn L. Berg, Computer Standards & Interfaces
“. . . makes a very important, serious subject fun and easy to read.” – Bill Loveless, PC News & Reviews
“The Gause and Weinberg book is full of tricks for eliciting from users what they cannot express without your help and for testing to see if your understanding of user needs is correct.
“It is impossible to overemphasize the value of this. Errors that you make in eliciting user requirements can be very expensive to fix. Any software engineering book will tell you this. What the software engineering books don’t tell you is that it also can be expensive to give users what they say they want instead of what they need.” – J. Adrian Zimmer, Editor, Journal of Software Maintenance
“There are not very many technical books on specification from over a decade ago that people still keenly read, enjoy, and recommend to their colleagues, but this is such a one . . . it takes a clear head to reflect on what is really happening, and then to look ahead to what ought to be done about it. It is even better if the book is not only visionary and sharp on the essential principles of a domain, but also delightfully funny and spicy. This book is.” – Ian Alexander, http://i.f.alexander.users.btopenworld.com
“There is no book in the software industry before or since Exploring Requirements that has as much to say about the integration of creativity with the software design process. I have been in the systems industry, in a variety of positions since 1974, and this book is my all time number one reference.” – Jim Adamski, [email protected]
A classic that will be around a decade from now
by Mike Tarrani from Tustin, CA USA (Source: Amazon.com)
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.
Essential Reading
by Daniel Read from Atlanta, GA USA (Source: Amazon.com)
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.
Preface
“There’s no sense being exact about something if you don’t even know what you’re talking about.” – John von Neumann
Development is the process of transforming someone’s desires into a product that satisfies those desires. This book is about the requirements process–the part of development in which people attempt to discover what is desired.
To understand this process, the reader should focus on five critical words: desire, product, people, attempt, and discover.
First, consider the word “desire”. Some readers would prefer that we say “attempt to discover what is needed,” but we don’t know how to figure out what people need, as opposed to what they desire. Besides, people don’t always buy what they need, but they always desire what they buy, even if the desire is only transitory. We do observe, however, that by clarifying their desires, people sometimes clarify what they really need and don’t need.
By “product”, we mean any product that attempts to satisfy a complex set of desires. One reason the desires are complex is that they come from many people. When we create a product to satisfy our own desires–as when we build a garden, for example, or a bookcase — we don’t often need an explicit requirements process. We simply build something, look at it, and make adjustments until we are satisfied.
But “people” might include many different people, and discovering who “people” are is a major part of the requirements process. When many people are involved–and when the product is large–the kind of iterative process used to discover personal requirements may simply prove too drawn out, too costly, and too risky.
What about “attempt”? If we’re writing a book, shouldn’t we be more certain, more certain, more positive? Shouldn’t we guarantee results? Well, we’ve used the requirements techniques in this book to help our clients develop all types of products–computer hardware, computer software, automobiles, furniture, buildings, innovative consumer products, books, films, organizations, training courses, and research plans. Nobody yet has demanded money back, but we can’t prove no client ever will, because we do not know how to make product development into an exact discipline.
Before working with us, many of our clients hoped that product development was an exact discipline. Many of those clients were in the software business–a business that has been plagued by ill-founded fantasies of an exact discipline for development products. We like to quote John von Neumann because many of our clients consider him to be the founding father of software. They pay attention when he says, “There’s no sense being exact about something if you don’t even know what you are talking about.”
If people don’t know what they want, no development process–no mater how exact, how clever, or how efficient–will satisfy them. And that’s why we do requirements work–so we don’t design systems that people don’t want.
Effectiveness always comes before efficiency. But even if efficiency is your hot button, the most important route to efficiency in development is to eliminate those products nobody wanted in the first place. Another way to put this is,
Anything not worth doing is not worth doing right.
Which brings us to “discover,” the most critical word. In this book, we’re trying to help people discover what’s really worth doing.
Dwight Eisenhower once said, “The plan is nothing; the planning is everything.” We agree, and we also extend the same thinking to the requirements process:
The product is nothing; the process is everything.
Or, put another way,
The discovery is nothing the discovering (the exploring) is everything.
which explains the title, Exploring Requirements.
A data dictionary, for example, is a way of preserving the definitions that are painstakingly derived with the aid of some of the methods in this book. In practice, however, hardly anybody reads the data dictionary, or possibly any of the documents that are developed in the requirements process. That observation bothers some people, but not us because we believe that
The document is nothing; the documenting is everything.
If you watch how people really develop systems, you’ll see that the process of developing requirements is actually a process of developing a team of people who:
1. understand the requirements
2. (mostly) stay together to work on the project
3. know how to work effectively as a team
We believe that if one of these conditions is not met, the project will probably fail. Of course, there are many other reasons why a product development project might fail, and there are many books about methods to avoid such pitfalls. This book, however, will concentrate on these three critical but neglected human aspects of the requirements process:
1. developing a consistent understanding of requirements among all participant
2. developing the desire to work as a team on the project
3. developing the necessary skills and tools for working effectively as a team to define requirements
Because these topics are somewhat neglected in the systems development literature, Exploring Requirements can be used as a supplement to any requirements process that you now use, formal or informal. Most of the chapters are designed as standalone modules, each presenting one of more tools or methods to enhance your requirements process. You can read the book from cover to cover, or read only the one chapter that’s most needed at any given moment. Either way, it should help you do a better job of knowing what you’re talking about.