I've been reading and studying this book for over 4 months as the main book of a requirements engineering subject of a master in informatics.

Most chapters in this book are good (7.- Functional requirements / 8.- Nonfunctional requirements), others are gorgeous (3.- Project Blastoff), and others just a little poor (5.- Trawling for requirements).

But the most interesting part of this book are the 164 pages of the two annexes. They are just a excellent way for approaching to the requirements process with many examples that can guide anyone to a final solution in any requirements problem.

I decided to read Mastering the Requirements Process (2nd Edition) because, while I am an experienced software developer/consultant, I have always struggled with writing requirements. It's not the writing itself that I find difficult it's the feeling that I'm wasting my time. You see, while I know that well documented requirements are critically important in any project, I often feel like I'm somehow missing the point when I sit down and struggle through a requirements document. I don't mind working hard and I don't mind wasting time but I can't bear the though of working hard to waste time! So, I was excited to read "Requirements are not meant to place an extra burden on your project. Instead, they are there to make your project run more smoothly" in chapter one. Yes! Exactly!

In this book I found a very thorough and well-presented requirements process. Robertson and Robertson clearly speak from years of experience.

The contents are as follows:
Chapter 1 What Are Requirements?
Chapter 2 The Requirements
Chapter 3 Project Blastoff
Chapter 4 Event-Driven Use Cases
Chapter 5 Trawling for Requirements
Chapter 6 Scenarios and Requirements
Chapter 7 Functional Requirements
Chapter 8 Nonfunctional Requirements
Chapter 9 Fit Criteria
Chapter 10 Writing the Requirements
Chapter 11 The Quality Gateway
Chapter 12 Prototyping the Requirements
Chapter 13 Reusing Requirements
Chapter 14 Reviewing the Specification
Chapter 15 Whither Requirements?

You could teach a full college course from this text. Rather than use the full Volere process, I plan to merge pieces of it into my company's existing methodology. For me, I was happy just to walk away with some new methods to 1) make my requirements useful and 2) ensure my requirements are complete.

[...]

Highly recommended.

[A review of the SECOND EDITION, 2006.]

The main context of this book is for software projects. If you are reading these words, you probably hail from that environment. But the authors do explain that the processes they describe are applicable to almost any project.

This is not a software book, per se. Not a line of code appears here, as far as I can tell. Most programmers know that design is important, and should usually precede any coding. The book's contribution is about that design and its prelude. Namely the gathering and determination of what the requirements might be. The authors point out that this makes the book in no small part a sociological text. About how to get a group of people together, and to solicit their contributions and perceptions into the project's requirements. Managing the dynamics of this is the purview of sociology [and psychology]. Without a solid performance here, subsequent design and coding may rest on quicksand.

The book does acknowledge that recent technological innovations like blogs and wikis can lead to quicker feedback. And hence contribute to a more interactive and iterative scenario of updating requirements as the project proceeds. All in the Agile spirit that many teams are now using. Just remember that the blogs and wikis are not a substitute for physically getting the team together. Much of the dynamics and feedback in the processes given by the book do really require that physical presence, to enhance the members' contributions.

From my experience and industry research, poor quality or insufficient requirements documents cause problems in the majority of software projects. This applies whether buying a package or commissioning development. Learning and carefully following the process in this book is the best way I know to eliminate this risk, as 8 years of experience has shown me.

Well-structured and pleasant to read, this book covers comprehensively all the aspects of producing an effective requirements specification. As a process it is also highly scalable, which means you can use it for a 3-day requirements gathering project just as well as for the 3-month project.

This requirements process has Unified Modelling Language (UML) as a component, more specifically the use case models. It also integrates well with the Rational Unified Process, though it is not compliant. My main concern is that this process ignores activity diagrams from UML, which I have found to be a useful tool in requirements gathering.

This is one of the best books on the subject of computer software development that I have ever read. The style is engaging and very creative; a pleasure to read. They explain something that I have tried to do many times myself but I was never quite able to hit the nail on the head until I encountered their ideas. I like this book because it has an abundance of ideas, most of them good. You can cut out what you don't want if their process is too elaborate for you, on a smaller project say. On larger projects it could well be a life saver. Read this book and you could well become the respected 'requirements genius' of your organisation, bringing direction where there was chaos.

Every software project I have ever worked on has had fundamentally the same problem; poor requirements. After reading this book my requirements documents were rated 9 or 10 out of 10 by a software development team. We had a traceable, understandable and very thorough process which enabled us to write the correct software straight off. Of course only an oracle can predict how requirements will change as your organisations business needs change so your requirements can still become wrong over time. The subject of changing requirements has been the focus of eXtreme Programming and other Agile methods; perhaps the authors might consider adding a chapter on how to integrate their process and template with Agile?

The chapter on 'Event Driven Use Cases' explains how to arrive at more innovative products by considering the product boundary. I really enjoyed this. Its very creative. Don't believe that having a fixed requirements process means that you will have a dull product. Quite the opposite, the authors show how the process can really support your own creativity and invention.

Incidentally, one of the other reviews states that this book is flawed because it doesn't take into account the architecure of the implementation. Thats the whole point. A good specification seperates the what from the how. The how part is technical design and I really hope that these two authors go on to write a book on that subject too. In short, brilliant, buy it right away!

This book is pretty good but it has two fatal flaws:

1) All requirements are treated at the same level. There seems to be no recognition of decomposition and definition. There is no explicit recognition that some requirements exist at the system level, some at the segment level, some at the sub-system level, etc., and that lower level requirements must be derived from higher level requirements.

2) The Robertsons go from requirements to specifications without ever considering system implementation concepts or architecture. Specifications can be written only if there is a concept or architecture against which the specification may be written. The specification for tracking migrating animals will be different if one has a concept based on tracking animals using radio collars than if the concept is to track them using acoustic sensors, visual observation, infrared sensors, etc.

FCP

This is a must read book if you are involved in the software lifecycle process. The book is suited for both experts and novices in the requirements elicitation process. It contains the concepts, the process, and a "quality gateway" complement. The resulting specifications document is complete enough. It isn't an abstract book, but a practical one that follows a sample case from its conception to the final document delivery to the project management team (though it doesn't contains project management concepts). There are a few ambiguous sections in the proposed document, but they aren't an obstacle for its implementation. Additional documentation and tools are available on Volere's web site.

The title of the review says it all. I don't keep very many of my business books, but this one is clearly a keeper. They not only include the entire template for the Volere method, they do a good job of explaining the most difficult portions. I had the experience that whenever I had a question, it would be answered within pages of popping into my head. Also full of excellent recommendations for further reading.

Wary of "star inflation?" Me too, yet this book gets five stars from me.

A very readable book, Mastering... gave me concrete guidelines for a topic that seems too nebulus at times. I read this book at the same time I was doing requirements gathering for a relatively simple project. This book caused me to make *specific* changes to our requirments document template and ask our customers questions I wouldn't have otherwise.

I think this book has just right amount of depth and detail to be read "in isolation" (of other books or prior experience) and help one do a competent job of requirements gathering. However, you the reader must do your part.

You'll have to cogitate just a little! Requirements gathering is thoughful process, not a science with rigid algorithms. There is no pretentious scientification in this book. And yes, "use case" is not given much more than a simple definition (although the concept is fundamental to the authors' process); but how many books do I need to read on Use Case to understand that a customer's business process can be divided into logical or physical modules, each of which in turn can be divided...

This book will give the novice what (s)he needs to actually do requirements gathering; and it definitely gave me points to ponder when doing my project. You won't be an expert after reading this book any more than you'll be a pro golfer after reading a book by Tiger Woods. Practice makes perfect! Reading this book is an excellent way to learn what to practice.

I have been in the IT industry for 20 years and this is by FAR the best book on the Requirements Analysis process I've every seen. I've had it since it first came out, and have used the Volere process to successfully run several software development projects. They were all successful. Both the Design and Test teams LOVED the resultant Requirements Specification because they knew exactly what to code and exactly what to test to prove the requirements were met. My only complaint is that it takes a lot longer to document a Spec. to this degree of detail, but if you can convince "the powers that be" to take the time to do it, it will save a lot of time and expensive re-writes later.
Even if you don't use the Volere method to write your specs., it's worth the read for the knowledge gained on the analysis process itself.

This is the best book on requirements gathering and analysis yet written. The authors are practiced at what they preach and inspire an attitude of inquiry that is the soul of the requirements engineering art. Read this book.

I like this book because it approaches the "Why" questions of requirements gathering. I see it as a complement and prequel to more practical books like "Writing Effective Use Cases" and "Use Cases: Requirements in Context". This is more of a business analyst book than a technical book.

This is an academic document of someone who has participated on the process of gathering requirements.

The detail of every chapter, the context of the user, roles, the things to consider, the tips, the relations to other systems, the different kinds of requirements, the guides, the testing, all is there and complete. But it belongs to the classroom.

I was looking for a book that I can lend to the people in my organization so we can improve in our actual development process. There are no tips on how to use formats like the Use Case, it does not even appear on any page. Nor does it show the actual deliverables to the analysis and development team or suggestions on traceability for testing on the final product.

The writer has taken care on keeping things open so people could discuss, improve or use alternate approaches. But software development needs standards and method, there are no suggestion on how you can improve on these.

A little background information before I begin: I ordered this book for a specific project - specifying generic computer application non functional requirements for my coorporation. The book does not claim to be useful in the particular area, but I took a chance and bought it anyway.

That being said, I found it surprisingly useless. The language is chatty, repetitive and at worst, tiresome. The illustrations are numerous and large, some of them helpful, others not.

The information and toolset given in this book are quite sound, but I must admit that I had expected something, that went beyond what I was taught as a computer science freshman some 10 years ago sprinkled with a bit of common sense.

I cannot say wheter this book might not be great for other purposes, but from a computer science perspective, the useful information amounts to something that would fit in a thin pamphlet.

This is not only the best book on requirements gathering that I've found, it is one of the best books on *any* aspect of software development that I've ever read. It is clear, focussed, well-written, full of extremely powerful concepts, and illustrated with useful examples and formal models of all aspects of the requirements gathering process and requirements-related information. As a result, I not only gained tremendous insight into how to improve the requirements gathering process at our company, I also learned by clear example how to make best use of each of the modeling formalisms the authors recommend.

I've never written an on-line review before, but this book was so superior that I felt I had to take the time and share my enthusiasm. I hope you find it as valuable in your projects as we are finding at our company.

Great book. Written in easy to understand language. Usable methodologies, templates, and examples. Good information on Use Case. I will continute to use this book as my requirements analysis bible.

This is the best book on requirements gathering I have ever read. When I finished it, I asked for and received the authors' permission to use the Volere template for a couple of test cases in my job (I specialize in requirements gathering) and have used it for one very large and another very famous client, with excellent results. While it doesn't especially lend itself to Internet projects, it significantly cuts down the time it takes me to gather requirements, and adds a level of consistency to the requirements documents my colleagues and I produce. Definitely worth the money.

For my own opinion, the best book on requirements! Even if it is based on Gause & Weinberg work on "exploring requirement", this book is about a very well formalized and described process for requirements. On each step, activities and artifacts are explained and true guidelines help you to achieve the work. Last but not least, you get two book in one: a user guide and a reference manual. If you had to build requirements (even with UML, like me), choose this book.

This excellent treatment of the requirements process provides practical, step-by-step guidance. Given the impact of requirements specification on the success or failure of software products, the value of this timely book is tremendous. The generous examples supply the necessary concreteness for individuals and organizations to put the specific process into practice. Essential reading should also include a general requirements text, such as "Exploring Requirements" by Gause and Weinberg, before or in parallel with this book.