Customer Reviews

Mastering the Requirements Process (2nd Edition)

5 star:		(18)
4 star:		(6)
3 star:		(2)
2 star:		(2)
1 star:		(2)

 

 

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.

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.

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.

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 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!

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, <i>Mastering...</i> 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 <i>Use Case</i> 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 <i>excellent</i> way to learn <i>what</i> to practice.

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.

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.