Reviews for Writing Better Requirements

1. DIY Requirements Analysis: a great primer

   Rated 4 out of 5 stars, February 12th, 2006

   I bought this book as an introduction myself when planning a user-led approach to web software design. I found it told me much of what I needed to know in terms of what to do, how to do it and why it was being done. I immediately bought copies for all my team. It is comprised of short sections and plain language, and avoids putting pseudo-scientific rigidity on what is essentially a structured human process. I now find it a useful book to give to 'lay' people in our business who want to understand what a user requirements led design process is all about.

2. A book for every requirements engineer

   Rated 5 out of 5 stars, October 12th, 2002

   This is a very useful little book for anyone attempting to write technical requirements. It at all times remains practical rather than theoretical. It contains a small number of well chosen exercises, which makes it ideal as an aid to teaching requirements writing, and yet sits comfortably beside the keyboard as an ongoing reference for practitioners - especially with its concise glossary of terms.

   The book focuses on what is often the weakest area in requirements writing: the expression and organisation of user requirements - those that come before system requirements, and which describe more of the problem to be solved than of the system that is to be the solution. It uses the concept of scenarios as a means of obtaining and organising requirements. Indeed, the book is itself structured almost as a mini scenario, in which stakeholders are identified, interviewed; requirements documents are structured; requirements statements are written; and all is reviewed.

   Because the book is about writing requirements rather than managing them, there are many topics it chooses not to cover in any detail. Examples are requirements traceability and managing change in requirements. However, there is an excellent annotated "further reading" list at the end, which has the merit of not being too long.

   The only criticism I have concerns the example requirements in the appendix. I find it hard to identify the actual requirements from amongst the elements of the scenarios. Examples in the book sometimes use the affirmative "shall" to indicate a statement of requirement, sometimes just the present tense, e.g. "The pilot controls the aircraft's angle of climb with one hand." In the appendix, the word "shall" seems to be avoided completely, and, left only with the present tense, it is difficult to distinguish scenario steps from requirements. Are the statements "Call center operator tries to disconfirm intrusion by calling householder" and "Alarm notifies failure to call center" both requirements on the burglar alarm?

   In summary, "Writing Better Requirements" should be on every requirements engineer's desk (not shelf!) It could and should serve as a constant reminder of some common sense principles that lead to a more effective expression of requirements.