Customer Reviews

Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices (ACM Press)

5 star:		(14)
4 star:		(1)
3 star:		(0)
2 star:		(2)
1 star:		(0)

 

 

Each of Jackson's books has expanded on the previous one. PRINCIPLES OF PROGRAM DESIGN was about program design. SOFTWARE DEVELOPMENT was about systems development (specifically, for information systems). Now, SRS takes it further, and considers techniques for specifying different kinds of systems, and systems that require multiple viewpoints to specify them.

One of the main points of the book is to promote the idea that many systems must operate in multiple "problem domains" and so require multiple techniques in their specification. (Does your information system also have security/access requirements in addition to its functional requirements? Then you have a "multi-frame" problem, and you should read this book.)

The second major emphasis of the book is on describing the "application domain" -- the real world where the system's users conduct business -- before embarking on designing the system. That is, on understanding the problem befor you jump into trying to solve it. If you've ever worked on a huge system development project that turned out to be a catastrophy because half way through the project you discovered that there was a whole area of user requirements that you didn't even know about, then you should read this book. Find out what went wrong and get some ideas about how to avoid it in the future.

This is an excellent book about specifying computer systems, and I can recommend it to anyone. It is especially highly recommended if you enjoy thinking about software development at a fairly high, abstract level (a level above the one where you are designing code and database structures).

A great deal of software uses the "where the arrow lands, draw the target" approach. Jackson presents formal terms and techniques to pursue an alternative. Anyone collecting requirements and writing specifications will find benefit from this book. His discussion of various problem frames is wonderful.

The book is written in tool box style, and Jackson makes clear that he believes in fitting the right method to the task at hand.

Thought provoking and well written, the book borders on philosophy (epistemology) and predicate logic in places, something I enjoyed. Jackson's analogy between predicate logic and assembly language is most apt.

Highly recommended.

I'm a technical neophyte but I have to communicate ideas concerning software development to developers. Jackson's book takes a complex subject and puts it in simple terms. He creates common ground for the technical and non-technical to communicate. A must for implementation, business analysts, and project managers if you to translate the customers needs to the developers process.

I loved this book. It is one of the rare books that can be read for education or for entertainment. The book is written for software engineers and architects. Jackson's thesis is that most of the battle in software engineering is in describing the problem to be solved, not in solving it. When the problem is clearly represented, then the solution often falls out. He presents universal techniques that are independent of analysis and design method. He provides systematic, disciplined methods for thinking about and communicating about problems of any sort. Thoughtful readers will enjoy it greatly.

This book approaches to attack the essence of Software Construction rather the accidents. It is arranged as a lexicon(dictionary) so browsing for a specific topic is simple. It also provides a nice vocabulary for specifying software systems.

Main themes seem to be: 0. People who make software should become good at describing the domain, the domain-system boundary and the system itself. Talks about partial descriptions, multiple descriptions etc.

1. Strong problem focus. Knowing what to solve is more important than how to solve the wrong problem.

All in all well worth for the language, insights and original content.

Let's face it, writing a book about software requirements is tough. Michael Jackson does a great job here exposing the core disciplines, the historical growth of the process and introduces some great approaches to the probem space (notably his Problem Frames). The book is succinct, to the point and written in language that just about anyone can follow. The Predicate Logic sections are the only areas where he assumes any prior knowedge with regards to following the notation.

The only reason I gave this book four out of five stars is becuase the author got too cute with the structure of the book. The chapters are listed in alphabetical order based on chapter title. The book is presented as a "Lexicon" so I'm sure this was why the book was ordered in this way. Still there where many chapters that, in my opinion would have been more powerful if they had been grouped together.

This is not a good enough reason not to buy read and enjoy this book. I strongly urge anyone interested in the topic to do so. I just wish an editor had taken the time to encourage Jackson to create sub sections .

I would like to thank you the author for: 1. For his technique of PROBLEM FRAMES, a sound method for a run-of-the-mill practitioner to deal with comlexity and chaos while defining a future system. Like any truely great ideas, Problem Frames is a very simple and elegant tool. 2. Crisp and engaging style of writing 3. Intellectual breadth You can start this book from any essay - the most of them are no more than 3 pages long - and you will enjoy everything you learn.

Folks who like this book (like me!) will want to know that Jackson has published a follow-on book in which he expands on the central themes of this book. The follow-on book is called "Problem Frames", and of course it is available on Amazon.

I bought this book based on the rave reviews listed here. I was looking for insights into the requirements specifications process based on case studies, experience, etc. The topics discussed are very abstract, and the organization of the book (in alphabetical order of topics) contributed to this abstraction. One of the topics I found extremely interesting throughout the book was the use of mathematical notation to accurately specify relationships and concepts. In my own software engineering consulting practice with Fortune 500 firms, the use of mathematical notation in requirements specifications, such as is used for mathematical and logical proofs, is rarely used, primarily because most users, stakeholders, and developers cannot read or understand mathematical notation with respect to logic! Nevertheless, the book's treatment of mathematical notation in software specifications is refreshing and a keen reminder that the purpose of requirements specifications is precision and to eliminate misinterpretations. If you are looking for a textbook that provides insights into the practice and successful techniques of requirements engineering through case studies and anecdotes, I recommend reading other texts that are aligned with methodologies and techniques such as UML, CRC, etc.

I have to concur with the other reviewers here: Jackson presents an excellent collection of immensely valuable ideas in this little book. What makes his ideas so valuable to software developers is that he isn't "locked in the beige box" - he is able to see the larger "system view" picture of software development. This allows him to interpret the role of software development concepts correctly and place them in the correct position of importance with respect to one another. In other words, he knows what's important, what's not, and what's hype.

Add to this the easy-to-read way in which he writes and the easy-to-digest form of the book and you have an indespensible resource for software development.