Site Network:

Processplatsen - home for iPB

Agile development of business processes

- easy to draw a process map
- easy to design WEB forms
- easy to run as a WEB application

A book that destroys the myths

Review of book "Discovering Requirements: How to Specify Products and Services"
by Ian Alexander, Ljerka Beus-Dukic, Wiley 2009.

An excellent and practical book on requirements engineering (RE) that can be recommended for both novices and experience professionals. I cannot judge the value of this book in general, but from my experience, this book is very valuable for everybody engaged in software development. It has helped me to analyze some of our past projects and understand the drawbacks of our system development process, which we hopefully can correct in the future.

I like this book because it destroys many myths some of which are obvious for professionals, but not all. The destruction of the most obvious myth is in the book title. The requirements cannot be just gathered but need to be discovered, and discovering them is a profession that may or may not mix with the experience in a specific application domain. A professional requirement engineer can do a better job in the previously unknown for him/her domain than an ordinary experienced professional in this domain. The discovering process can be compared with the one of a field linguist writing a grammar for a language that exists only in the spoken form. An experience field linguist can do the job even when he/she cannot speak the language, but a native speaker unless he/she is also a field linguist cannot do it. This book presents a number of practical methods for what is in its title – discovering requirements.

One of the not so obvious myths is expressed by a phrase that can be found in many standard manuals: “You need to give a customer what they need not what they want”. The answer that indirectly follows from this book is that you cannot give a customer what they need unless they also want it. The book has a special focus at finding all stakeholders of the future product/service and make them agree on the common understanding of what they need/want. Missing an important stakeholder may put the whole project at risk. Converting the wants to needs requires special technique of finding rationales behind each “want”, and this technique is also in the focus of the book.

Other myths that the book destroys concern modern techniques, such as modeling languages, e.g. use cases, software tools, e.g. groupware, and scientific methods of choosing an optimal alternative, e.g. weighting. These techniques are often marketed as a solution for all possible problems, however, the book advices to use them with a great caution. Over relying on these techniques may result in the focus being moved from discovering requirements to something else, e.g. syntax of a specific modeling language, or details of the product, or user-interface design. Besides, using these techniques may consume too much valuable time from the requirement team. The book recommends using simple tools and techniques and use common sense rather than scientific methods.