Review By: Sameer Khanwalker
11/27/2002Most books or articles treat software requirements in a cavalier fashion. This book is both extensive and intensive. It is one of those rare books that look at software requirements engineering in its totality. For a change, here is also a book that practices what it preaches. It is very neatly organized into four parts.

The first section lays the groundwork in six chapters that deal with the fundamental issues in requirements engineering and introduces a notation that is very precise. Even those who have not worked with methodologies in the past will find this notation pretty simple to use. The chapter on problem framing begins with the knight’s tour, an excellent example, for framing the requirements for the solution to a given problem.

The second section focuses on analysis. Merely putting down the end-user requirements on paper is not enough unless they are analyzed and converted to a form that the designers will understand. This part is the most important in requirements engineering, but it is also the one where most software engineers fumble.

The next section deals with documenting the requirements and is a well-written section with plenty of good insight. The section on writing for the hostile reader, for example, elevates documenting requirements to almost an art form. Here you are forced to think beyond technicalities and write so that not only are you understood but also, paradoxically, not misunderstood.

The final section contains examples of two extremely well-thought-out requirements documents. The bug log requirements was a good example because it is an application that touches virtually everybody in a software organization.

The good news first, and most of it is good news about this book. It’s a very good book and is a must for any requirements specialist, project manager, designer, developer, QA specialist, or tester. A good requirements document sets the tone in a project and runs like a silver lining throughout the project. This book will definitely help in organizing your thoughts, removing the cobwebs, ironing out deficiencies in your own requirements gathering and analyzing process, and providing you with knowledge that you never realized was required in the first place. This book is groundbreaking in the sense that it treats requirements engineering as a true engineering discipline and not as a requirements gathering exercise. It definitely has a place on the desk of every software engineer worth his or her name.

It may seem odd, therefore, to find flaws, but there are a few here. One is the usual flaw that most authors suffer from: getting carried away in the criticism of something while commenting about your own expertise. This book takes the criticism of functional decomposition a bit too far. There are far too many critical references to a methodology that, while not the best in the world, definitely serves a purpose. The very first example that the author uses to criticize the methodology itself is wrong. I do not think any software engineer will try to use functional decomposition on a problem that has an almost totally mathematical and logical base. In his attempt to find fault with the methodology, the author makes a typical mistake by stepping off on the wrong foot.

This book also would have been more useful had the author spent a little time on the skills that a requirements engineer needs. Indeed, it would have dispelled many myths and brought in a sense of reality. Most projects assign the requirements-related tasks to novices. Sometimes the novices are not even engineers, and the results are almost always disastrous. Despite these flaws, it is a book that is a must in any software project.