Rating: 
Summary: Project preparation for the clueless
Review: 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.
Rating: 
Summary: A must have book on requirements !
Review: 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.
Rating:
Summary: Must have book for requirements analysis
Review: 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.
Rating:
Summary: The Bible for Requirements Analysis
Review: 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.
Rating: 
Summary: A Good High-Level Book
Review: 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.
Rating:
Summary: Cogent and complete overview of the Volere method
Review: 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.
Rating: 
Summary: Fatal Flaws
Review: 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
Rating:
Summary: Practical, effective and usable how-to manual!
Review: 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.
Rating:
Summary: A complete methodology
Review: 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.
Rating: 
Summary: Who is this book for
Review: 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.
| 
