I approached this book with interest, a Microsoft book on software specifications? I could hear the jokes already… This is a fascinating book. It takes specifications almost to the level of project management. Not only does it cover the requirements of the software but the test requirements as well. If you can’t write a test spec then the requirements are not complete. One chapter I like is where it discuses prototypes. The premise is customers never know what the want but they know what they don’t want! So do prototypes to show them what they asked for to find out what they really need. Most forms of engineering have prototypes software engineering is no exception. This came up in a paper on 61508 where it stated that 44% of failures in safety critical control applications came from errors in specifications.
On the subject of project management there are discussions on planning releases, which features go in which release etc. partitioning and future requirements you have to cater for now etc. Also version control is obviously touched on especially in the terms of controlling the requirements documentation. Controlling versions of software is one thing but making sure everyone is using the same version of the specifications for the software and the testing is another.
There are plenty of examples that show the author has done this for real… theoretically accountants don’t get involved in software specification but some of the discussions will be of use to engineers and project managers who have to argue with higher management, and for tools and time to do things. Of course risk analysis, risk, benefit, costs, priority are all covered in several areas along with comments on side effects.
There are views on things from several perspectives, which is useful for a project manager to understand where the others are coming from. One of the stakeholders is “maintenance programmers”. Something not often thought about when doing the specification.
Another acceptable section is an adequate selection of commonly used, state of the art words, and the problems they can cause if they are not suitably (and precisely) defined, as much as practicable under the right conditions… It is a acceptable attempt at clarification. English can be so ambiguous!
This is a cookbook of ideas and methods, tip and techniques rather than a single regime. Requirements are looked in respect of both UML Use Cases and structured methods and using in general the V model so it should be relevant for most users. Also there are sections on how to tighten up any process you currently have. There are symptoms with possible causes and remedies. This makes this book useful for virtually everyone who does not have a complete and smoothly running system.
The book is readable and easy to read. It is also easy to dip into as the chapters are self-contained on a subject area so it is worth reading the preface for the guidance notes.
I would say that this book would cover not only general software requirements for most projects or companies but also project management and high-end test strategies for small companies or projects where there are no other systems in place. It is pragmatic and real world. It is a book you can dip into for ideas and inspiration. I thoroughly recommend it.