January 2002 Book Review

Mastering the Requirements Process

Authors: Suzanne Robertson & James Robertson

Hardcover: 352 pages (1 edition)
Publishers: Addison-Wesley Pub Co
ISBN: 0201360462

An excerpt from the back cover nicely introduces this book, "It is widely recognised that incorrect requirements account for up to 60% of errors in software products, and yet the majority of software development organisations do not have a formal requirements process. Many organisations appear willing to spend huge amounts on fixing and altering badly-specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place"

Suzanne and James Robertson have created a very readable book for requirements novices. This does not mean that requirements experts will not have much to learn from their approach as well as from some cutting edge topics in the book such as requirements reuse, requirements patterns, traceability, fit, and a use case driven approach.

The book details the processes of requirements gathering in the "Volere requirements process model". As a reader, one is taken through a step-by-step approach, complete with checklists, templates, discussions, and a case study, which all helps to gently and thoroughly guide one into using this important process.

Topics covered in the book:

  • Volere Requirements process Model

  • Project blastoff
  • Determining requirements
  • User and stakeholders
  • Project constraints
  • Requirements constraints
  • Use cases
  • Business events
  • Adjacent systems
  • Innovation
  • Trawling for requirements
  • Apprenticing
  • Interviews and videotape
  • Functional and non-functional requirements
  • Fit criteria
  • Quality gateways
  • Traceability
  • Prototyping and scenarios
  • Low and high fidelity prototypes
  • Patterns and requirements reuse
  • Improving the requirements gathering process

I personally enjoyed the discussions on requirements fit. The authors suggested that if a requirement could not be made measurable or testable in some way, then perhaps it was not a requirement after all! This reinforced my view that if a requirement is not testable, it should be made testable or deleted!

Project managers wishing to build quality products, on time and within budget, would do well to recommend this book to their business analysts.


Wayne Mallinson


 

<< December 2001
February 2002 >>