Customer Reviews

Writing Better Requirements

5 star:		(2)
4 star:		(1)
3 star:		(1)
2 star:		(2)
1 star:		(0)

 

 

It's a short and to the point book on what requirements should contain; it's like a cliff-notes version of other requirements gathering books. We ordered one for our whole team and made it required reading! For anyone who doesn't have the time nor the patience to weed through 300 pages to get to the point, this is the book for you.

It is rare when you come across a project management book that is easy to read, short and full of valuable information but Writing Better Requirements meets this criteria. I like simple and to the point!

The Book Provides Practical Advice

The book provides good practical advice on writing requirements. Alexander and Stevens follow their own advice for writing requirements in the book by using simple words that contribute to the books readability. The book is written in a manner that will not intimidate non-technical personnel so it may given to the entire project team, including customers and users. (Wait... I just had a novel idea...we should teach our customers and users how to write requirements.)

Here are five of many valuable tips from Writing Better Requirements

1. Perspective on the requirements effort. The authors state approximately 5% of the project effort and up to 25% of the schedule duration should be put on project requirements.

2. Guidance on structuring requirements. Improper structuring is identified as a primary cause of poor requirements. The structuring discussion includes a useful table that documents problems and solutions for structuring requirements. For, example, the authors characterize one problem as Some requirements can be applied simultaneously or in any order and provide the common sense solution of Mark whether sections in the structure are sequences, parallels or alternatives. Overall the authors provide some good alternatives to challenges on how to effectively structure requirements.

3. Plenty of exercises. Another valuable aspect of this book are the exercises provided after a lot of the sections in the book. The exercises provided are well thought out and solutions are included at the end of the book. In addition to the exercises examples are provided to clarify and reinforce key points.

4. Guidelines on conducting a requirements workshop. Important guidelines on how to conduct a requirements workshop are discussed including room lay out and facilitation tips. The book has a good glossary of terms.

5. Lists of other sources of requirements. The book includes a nice list of other sources of requirements. One of these sources that is often overlooked is problem reports from the previous system. The authors state these problem reports can often be turned around into requirements. This is a powerful method to ensure improvement of the future system.

Writing Better Requirements should be a part of every project managers library. I give it 5 of 5 stars! Make your life easier and give it as a holiday gift for your users and customers.


Dr. James T. Brown PMP PE CSP
Author - The Handbook of Program Management

I found this book to be very helpful in developing an overall process sense of requirements development. This book provided an excellent synopsis of "why" good requirements are important and what the pitfalls are when such is lacking. The examples were both relevant and descriptive. As an overall initial treatise on requirements, this book was terrific. As such, the focus is perhaps more upon managers and leaders of teams, rather than the actual developer of detailed requirements. Ideally there would be a follow-on companion volume with greater detail to better aid the actual developer of requirements including checklists and several case studies, as well as more detailed examples. But I completely recommend this book. Vance Hilderman, March 2010.

I was looking for hard-nosed, technical, product requirements guidance. I found that this was just the Customer side. It does cover the basics, and much of this is common to both customer and technical requirements. These include the concept of the stake-holder, use-cases, it even spent a paragraph or two on traceing. It has no mention of requirements language (predicate logic, Z notation) it only taught natural-language lessons with examples rather than teaching some of the underlying technical aspects of language. In fact, the example requirements throughout the book weren't very tightly written with complete unambiguity, testability and achievability. It had no sense of systems engineering methodology with an eye towards partitioning, performance, harms, error handling, misuse accommodation ... Finally, it did the worst thing I know of for a reference book, which is that it asked the reader to solve example problems without a (real) chance for a conversation.

I expected much more from this book. If you are looking for reference material for a school paper, it is ok. If you are looking to standarize your institutions Requirements Gathering, it will not help much. I guess I should not have expected as much. Was very disappointed.

There were some good thoughts about writing better requirements, but, for the price that you pay for the book, I expected more substance. Most of the suggestions are just good common sense.