ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1949 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Software Requirements: Styles and Techniques
Soren Lauesen
0 201 74570 4
Silvia de Beer
Appeared in:
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