Book Review: Mastering the Requirements Process

In an era where managing requirements could seem to be limited to writing user stories with a “as a … I want … so that” format on a post-it, it could be strange to publish a 500 pages book on this topic. However, people that want to improve their knowledge of software requirements topic will find a very valuable resource in the book “Mastering the Requirements Process” by Suzanne and James Robertson. It explores in details the relationship between the IT and business part of software development projects.

Although the book is based around the proprietary Volere format, the content is really open and useful for anybody that has to deal with software requirements. The book is well written and well-structured with many examples to see how the concept can be applied in practice. Many sidenotes help to relate the different part of the book together, or provide pointers to other material that could be interesting about the current topic. My favorite part is the description of the Brown Cow Model. This is a quadrant based on four simple criteria (How/What, Now/Future) four views that guide business analyst and users at different stages of the software requirements discovery process.

I will recommend this book to every business analyst or software developer that has to interact with users to discover, express, validate and prioritize the business needs.

Reference: “Mastering the Requirements Process” (3rd edition), Suzanne Robertson and James Robertson, Addison-Wesley

Quotes

The primary reason for wanting written requirements is not to have written requirements (although that is often necessary), but rather to write them. Writing the requirement, together with its associated rationale and fit criterion, clarifies it in the writer’s mind, and sets it down in an unambiguous and verifiable manner. To put that another way, if the business analyst cannot correctly write the requirement, he has not yet understood it.

The scope is the extent of the business area affected by the product. Because it is defining a part of a real-life organization, the scope points to the stakeholders – the people who have an interest in, or an effect on, the success of the work. The stakeholders, in turn, decide the goals, which is the improvement the business wants to experience when the product is installed. There is no particular order to deciding what these factors should be. Most projects start with scope, but it is not obligatory – you use whatever information is to hand first. You have to iterate between the three factors until you have stabilized them, but this is almost always a short process when your organization knows why it wants to invest in the project.

We know from experience that the exceptions have the potential to necessitate a great amount of remedial rework if they are not found at requirements time, so look carefully for things that could go wrong. You can ignore the scenario in which the work is struck by a meteor, but almost anything else is possible.

The description of a requirement is unfortunately, often stated in terms of a solution. We all unconsciously talk about requirements in terms of how we think they should be solved, based on our personal experience of the world. The result is a statement that focuses on one possible solution – not necessarily the most appropriate one – and usually hides the real requirement.