Writing Better Requirements
Experience has shown us that investment in the requirements process saves time, money, and effort. Yet, development efforts consistently charge ahead without investing sufficiently in the requirements process. We are so intent to develop the technical solutions that we are unwilling to take the time and effort to understand and meet the real customer needs.
Review By: Roland PJ Aucoin
07/08/2010The objective of this book is to provide a guide for new writers for improving written requirements. It introduces the importance of requirements, the audience of these requirements, the users of these requirements, the different names for and types of requirements, and the challenge of the actual requirement writing process.
This book delivers practical experiences and prudent, conservative guidelines for improved, documented requirements. The terms used are sufficiently generic to accommodate a wide range of reader application background. The book is also sufficiently focused and technical to provide the depth and foothold that new and inexperienced requirement documenters need.
Every project and product starts its life with the gathering and recording of requirements. The better the collection and clarity of the documented requirements, the better the product.
This is an easy book to read, well directed to the intended audience: new requirements writers. It gives several practical guidelines, and includes many real-life experiences as examples. The authors show requirements gathering happens in iterations, not all at once. They present many ways to approach and resolve issues. They use generic definitions and steps, but focus on achieving correct results. Overall the flow is very logical and has a good pace. The book is organized to reinforce the points in the exercises. It also contains many “best practices.”
The authors focus on "checklists, traceable requirements, quality (not perfection)," and checks and reviews—often missed or assumed in generating requirements but critical to project success. Section 5.5, "Exceptions," is an excellent topic to address, as it is often overlooked in requirements. I do caution on section 6.3, negotiating scope—one needs a lot of experience in metrics to resource and scope without design. In my work, I first get complete requirements, then do some design, then resource and negotiate scope to get construction approval. It is too difficult to do it in any other order.
The best description of the book is in the Foreword by Dr. Ralph Young: "Ian Alexander and Richard Stevens are interested in helping you to evolve requirements that meet the customer's needs. They have provided an approach that is based on experience and lessons learned from decades in 'the school of practical experience.'"