This is a decent book on using software requirements to help center and guide the running software projects. The Robertsons break no new ground here that wasn't probably better explained in their "Mastering the Requirements Process" for the requirements aspects of the book. As a project management book, I think that requirements are important but so are many things in running a project. I have found the Robertsons approach a bit too simplistic and I think that shows on the project management side as well.
The key message here is that if you get the requirements right, the project will fall into place and run much better. Requirements are key to getting good estimates, scheduling, aligning stakeholders, testing, etc. Well this is true, but hard. The Robertsons talk Agile talk but don't do the Agile walk. One of the keys to Agile is that full, complete, or even mostly complete requirements are a myth. Learn a little, build a little. The Robertsons change that to learn a lot, build a little. Not quite the same. I personally agree that we should learn more about the problem space of a software project than what some Agile methods call for. Then again, I don't reference Beck and Folwer as much as the Robertsons do.
What I personally am having difficulty doing is agreeing to the Robertsons advice to "invent" requirements. To me this is a slippery slope not worth going down. I think the requirements analyst's job is to fully understand the business problem space, perhaps better than the stakeholders themselves. I would like to leave it to the designers to invent the solutions. Sometimes that is the same person and that is OK by me. However, I think as an activity list, they should be different categories.
So, if you have read "Mastering the Requirements Process" and you are primarily interested in requirements techniques, there isn't much need to buy this book. If you are into project management and want a different viewpoint from many of the PM books out there, this may work for you.
