Top critical review
One person found this helpful
3.5 stars... worth reading but reads like a verbose work instruction
on November 16, 2012
I did not find this book as good as other reviewers seemed to think.
To give a bit of a background, I'm work on a fairly complex robotics system with both hardware and software components. Determining system requirements is one of the major tasks that I perform on a daily basis.
I did find this book useful, as after reading it I had a much better perspective from the 5000 foot level of how requirements affect the entire business organization and product development process. It really drills down the importance of understanding what it is you are trying to build before designing a product. This book is 100% useful to engineers that focus on hardware as well as software - don't be fooled by the title.
My main gripe with the book is that it reads like an overly verbose company work instruction (imagine a dry and somewhat boring employee orientation manual). There are entire pages of material that could have been summed up much better in a paragraph or so, or with an effective picture. Many of the flow charts in the book for example read like your typical overly complex and useless business process charts that no one would ever actually reference when they do their job.
For the record, I don't have a problem with flow-charts, but they need to be simple to be effective, and despite what I stated above, there are a couple flow-chart gems in the book.
On to the specifics...
Section I of the book focuses on a very general overview of requirements, roles that different people perform in relation to requirements (i.e. designers, product managers, project managers, system analyst, testers, etc.). I found most of this material to be useless, except for comparing how my company structured itself versus standard practice across the industry. I imagine that anyone working at a company with any sort of formalized requirements process wouldn't get too much out of this section either.
Section II is a bit better. It begins with a focus on the business aspects of requirements. Without a clear scope document and business vision, the requirements are meaningless. It goes on to argue the importance of customer feedback during the requirements development process. I think some clearer explanation on gathering customer feedback, with specific case studies for how to drill down customer desires into tangible features to incorporate into a product would have gone a long way here... but I generally agree with the philosophy. Much of the use case / customer feedback chapters were too general to be useful though.
Section II also covers good practices in documenting requirements. I took this part for granted because my company has many of these practices already in place, but had I been working for a smaller company or startup, I would have found these organizational tips to be invaluable. This is really great material if you don't have any formalized process in place.
Section III covers a lot of issues related to version control, changing requirements during the development process, maintaining traceable requirements... This section is boring, and could have benefited by being more concise as well. Reading it did give me a better perspective of the requirements process however.
Section IV, a very short section, was really one of the best parts of the book. It ties together the other sections in some of the effective flow charts of the book as to how requirements management is a PROCESS, and one that lies at the heart of good product development. If you've ever been through a project and had a gut feeling that major decisions were being rushed without due consideration, or that the wrong tasks were being prioritized, this section will crystallize how things should have gone in that project. It covered a few things I hadn't seen before, such as measuring requirements volatility, which is a good way to get a handle on how well the product is defined over a long period of time.
Finally in the appendices, there are a couple hidden gems that cover the maturity level of a company, and what level of requirements management are actually NEEDED by company depending on the project. For a simple project, requirement management tools would be major overkill.
Overall a good book for managing requirements. People that work on large, technically challenging projects in large groups / organizations would find this book especially useful. It suffers though from being way too long for the information that it is trying to impart.
My review might a little harsh, as I could see myself re-reading a couple selected parts of this book from time to time, but I simply would never rate this book anything close to 5 stars, and I'm surprised by how high other reviewers have esteemed this book.