The title gives a correct summary of this book; it deals with styles and techniques to write software requirements. It is not a cookbook of how to write your software requirements but a summarisation of styles and techniques. The first time I paged through this book I noticed that from page 439 onwards the book solely consists of examples of requirement specifications, all on a grey background. The examples only seem to be there to increase the page count. For someone who uses this book as self-study, the example requirements specifications do not seem to be very useful. However, this book is set up so that it can be used in courses. The exercises that are based on those requirements specifications might actually be quite useful. Another visual impression was the many white odd pages, because the editor chose to start the sections on an even page.

The first half of the book is interesting for people who are actually writing requirements, e.g. people who write Requests for Proposals (RFP), proposals and functional requirements as a first step during a development process. The book concentrates on writing requirements for simple business processes and it does not cover very technical systems.

During the second half of the book I lost my interest somewhat. The author repeats himself a few times and fills many pages with trivial explanations. The most important observations that the author has to offer are in the first four long chapters. He explains that you can write goal-level, domain-level or design-level requirements and that requirement roles can differ depending on the project type; in-house development, Commercial Off The Shelf deployment, subcontract, etc. The author has a fairly traditional view of requirements specifications, probably because of his background and prefers the traditional E/R model above UML. Other traditional diagramming techniques are also explained in his book.Management& Leadership