Mastering the Requirements Process Review

This post is a review of the book "Mastering The Requirement Process" by Suzanne and James Robertson.

The book describes a process for gathering and validating requirements based on the similar processes used and observed by the authors from many software projects. There are many forms and templates in the book to aid the process. The process described does seem a thorough way of gathering and recording requirements though I don't have any experience of other well-documented requirements processes to compare it to. On a first flick through the book, some agile enthusiasts may be put off with the large amount of forms described and process description but the authors very sensibly describe in each chapter, how they would adapt the chapter's contents depending on the agility of the team using the process and as the authors repeatedly state, regardless of how agile you are, if you don't find the correct requirements you won't be making the right product.

Here are some of the points that I found most interesting or were more abstract than the majority of the book:

• The book defines 3 types of requirements; functional - things the software must do; non-functional - qualities it must have; and constraints - global issues that shape what can and can't be done. It's a useful mini checklist to use for inspiration, as the initial excitement of a project is normally about the functional requirements, so a reminder that you need to plan for other things is welcome.
• Another repeated point of the book is that all requirements should be testable. Obviously some requirements are going to be easier to test than others but the authors aren't afraid to suggest such ideas as testing whether 90% of a panel of potential users can complete a simple task in 10 minutes, as a way of quantifying usability requirements which are the normally the hardest requirements to turn into measurable goals.
• Requirements can be reused between projects. As with code, it is suggested that there will have to be some adaptation but you can imagine that reuse of usability requirements would be very possible in products that target the same group of users for example.
• You need to strip away the current technology to get to the essence of the work. This often leads to products which are much simpler to use than their predecessors and can lead to innovative products which do the work in a very different way.
• Some useful suggestions are made for finding potentially missing requirements. Firstly a requirements to cover what happens when expected external events do not happen. Secondly, for every data class (obviously, I mean class in a high level sense) in the application, if there are requirements that describe reading, writing of updating it, then to check that there is a requirement covering creating of instances of that class.

In conclusion, I would say that the book is most useful to have as a reference rather than for explicitly learning too many high level concepts. The checklists and forms in the book provide a very thorough framework for capturing requirements. I can see the book being very useful for people working on their own projects, where it will help make you consider the product from other perspectives, and on the other extreme, also useful for people working in large organisations who need a strict framework and process for gathering requirements for large products. I am planing on using the process described in the book for a personal project, so I'll update this review when I have some feedback on how that worked.

Link to buy the book on Amazon.com