"Requirements" are essential for creating successful software because they let users and developers agree on what features will be delivered in new systems. Karl Wiegers's Software Requirements shows you how to define and get more out of software requirements with dozens of "best practices" and tips that make this book a valuable resource for both software project managers and developers.
The book's common sense approach provides exemplary project management skills tailored to gathering (and refining, implementing, and eventually tracking) software requirements. While the book often cites recent software engineering studies, the focus always returns to practical management techniques. A case study for a chemical tracking application frames the book, and most chapters begin with anecdotes that demonstrate situations in which users and developers misunderstand each other about a software project's ultimate goals. (If you've ever worked in the field, these stories will probably sound all too familiar.)
This book teaches you how to improve the software design process, with dozens of tips on getting better design input from your customers and then using these requirements to generate a variety of design documents. There are numerous templates and sample documents too—a big help for the busy software manager.
Several standout sections cover negotiating difficult steps in the process, particularly how to manage shifting requirements as projects move forward and keep the various users and stakeholders content throughout the software process. Late in the book, the author surveys today's software management tools and shows how to pick the right ones for your organization.
Topics covered: software requirements specifications (SRS); business and user requirements; risk management; the requirements process; sample documents and templates; requirements development: elicitation, analysis, specification, and verification; rights and responsibilities for software customers; best practices; project management tips; process assessment and improvement; types of users; product champions; use cases and other diagrams; tips for prototyping; managing requirements change; change centered boards (CCBs); evaluating and using requirements tools; requirements traceability matrix; impact analysis.
Review By: Gena O'Flaherty 07/08/2010
Software Requirements 2nd Edition provides a detailed explanation of software requirements gathering, implementation, and maintenance. The book contains 416 pages plus 100 more pages including several appendices, a glossary, and an Index. At first glance, the book's size may be a deterrent for anyone looking to quickly pick up how to gather, implement, and maintain requirements. Upon closer inspection of the book's presentation, it is possible that the book could have been condensed to a smaller size without sacrificing content with the use of a smaller font and thinner paper stock.
Wiegers uses UML as the method of choice to explain how software requirements fit into a software development lifecycle. It would have enhanced the book if the author had included more than just one method. He provides good definitions of terms always with examples. This helps the reader to mentally apply the concept to a real-world scenario. The book contains a software requirement specification template, but also explains each section of the template in detail. Many books on the market fail to provide these details.
He includes an important section entitled "Ambiguous Terms to Avoid" which is essential in writing clear requirements. The clearer the requirements are, the more testable the software is. Surprisingly, Weigers also includes a section on Decision Logic Tables, a tried-and-true technique that has been around for over forty years. This technique is rarely mentioned in today's publications. Wiegers writing style is just the right blend of technical aptitude and credibility; however, it tends to be a little dry on humor at times.
Wiegers 2nd Edition is a complete reference on the topic of Software Requirements. His writing style is direct and to the point while providing different views of industry problems. The book is very well organized, presenting an overview of specific terms and then going into more detail of each of the terms. The book could use more complex graphical representations. The aim of the author may be to keep it simple, but the sheer size of this book prepares the reader for hefty explanations and diagrams to go with it.
The Chemical Tracking System example used throughout the book is of particular interest to those in the pharmaceutical industry, but may be a bit boring to others. I was very glad to see that he included Decision Logic Tables as part of his organization of requirements against use cases. However, he needed to get into more detail when showing how to collapse the true/false combinations to get the resulting table that is diagrammed in the book. It would have been better if he had also mentioned that the use of a DLT is one method in determining the number of test cases that need to be designed and executed. Perhaps referring the reader to another source on the topic such as Herman McDaniel's "An Introduction to Decision Logic Tables" would be additionally helpful.
Wiegers is clearly a proponent of the idea that requirements are necessary for effective testing, but gives a conflicting warning on p.274 to "Watch out for testers who claim that they can't begin their work until the requirements are done." While this may be true in some respects, testing without requirements is never a good idea, an opinion he supports earlier in the book.
As a tester reviewing this book, I kept asking questions as to whether a certain topic would be included. Each time, I was pleasantly rewarded to find that all my questions were answered. "Software Requirements" is the complete reference on the topic and has found a home on my bookshelf.