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

~ Michael Jackson (Author)
Key Phrases: controlled domain, structured analysis, simple control frame, Analog Devices, Operation Requests, Nurse's Station (more...)

Editorial Reviews

Product Description

With a spice of wit and illuminating illustration, this collection of 75 short pieces deals with topics in the field of software requirements analysis, specifications and design. The author emphasizes the need to structure and analyze problems, not just specify a solution.

From the Inside Flap

The practice of the book's title is the practice of software development, especially of the requirement and specification activities that often precede programming. The principles are those that I believe should govern software development and the methods by which we try to make it easier and more effective. And the prejudices are the settled personal opinions that I have formed over some years of thinking about these things.

The central theme of the book is the relationship of method to problem structure on one side and to description on the other. To deal with a significant problem you have to analyse and structure it. That means analysing and structuring the problem itself, not the system that will solve it. Too often we push the problem into the background because we are in a hurry to proceed to a solution. If you read most software development texts thoughtfully, you will see that almost everything in them is about the solution; almost nothing is about the problem.

On the other side, description is important because it is the clay in which software developers fashion their works. Methods are, above all, about what to describe; about tools and materials and techniques for descriptions; and about imposing a coherent structure on a large description task.

This book does not explain or advocate one particular development method. Nor is it a survey of methods, or an encyclopaedia of techniques and notations. It explains what I hope and believe are useful ideas and insights--both my own and other people's. It is arranged as an alphabetically ordered set of short pieces forming a lexicon, or a kind of specialized dictionary. Because many of the ideas are neglected or simply unfamiliar, the selection of topics, the content and some of the terminology are unconventional. This is not in any way meant to be a standard reference work.

I chose the dictionary form for two reasons. First, because a more structured arrangement would have seemed to promise a unity and a completeness that I cannot attain. This is a collection of ideas and insights, not a new method. Second, putting the same point more positively, because I believe that many of the ideas in the book can be applied piecemeal in many different development contexts. They can be used to make local improvements in established methods, and to shed light on some of the local difficulties and problems that are met in any development.

Software development should be a thoughtful activity. You should think not only about the problem and its solution, but also about the way you're tackling it. Some software developers and method users behave as if they were bicycle riders. When you are riding a bike you shouldn't think about what you're doing. If you do think about it you'll probably fall off. But software development isn't like bike riding. You'll be a much better developer if you think consciously about what you're doing, and why. This book is intended to help you.

When you encounter a difficulty in software development, what you need above all is a set of appropriate conceptual tools. Perhaps you're trying to describe something that stubbornly refuses to fit cleanly into your description; or to disentangle the simple problems that you feel sure must lie beneath the intractable complex problem that is holding you up. The right conceptual tools help you to think consciously about what you're doing, often just by providing names for concepts that you already had but never articulated. So when you're struggling to get a description right it's helpful to be able to ask yourself: Have we got the right description span here? Are we sure we understand the designations well enough? Have we made a spurious classification? And when you're dealing with a problem complexity it's helpful to be able to ask yourself: Is this a multi-frame problem? Is there a problem frame misfit here? Are we trying to look at shared phenomena from the point of view of only one domain?

I hope that the lexicon form of the book will work to underline its nature. It is offered as a resource from which you can take what you want, not as another orthodoxy that demands acceptance or rejection as a whole. The arrangement of the book, I hope, will encourage you to browse and skip from piece to piece, and I don't expect it to be read straight through. Inevitably, this has led to some repetition, but not enough, I hope, to seem tedious. I have tried to make each piece self-contained but, of course, that is not always possible, especially for some of the pieces about less familiar ideas--such as problem frames. So there is a full index, and cross-references, capitalized in the text, from each piece to other relevant pieces. If you're feeling puzzled by a piece it may be a good idea to follow some of the cross-references in its earlier paragraphs before reading on.

If you prefer to read more systematically, you could start with the Introduction, which comes, out of alphabetical order, at the beginning. The Introduction lays out some of the main ideas, and puts them in context. Then you can follow the cross-references from the Introduction to anything that catches your interest, and so onwards from one piece to another. There is a bibliography that expands the short and informal references--both to books and to their authors--appearing in the text and adds a few bibliographical notes.

Another way of using the book is by taking a tour around one theme or topic at a time. I've prepared some itineraries of tours you might take. Most of them are quite short and don't try to include everything about their themes. You can take them in any order. As with most tours, the time needed will depend on how long you spend on the places of interest. Some places of interest appear in more than one tour. If you visited a place on a previous tour, you could stay on the bus. On the other hand, you might see something you hadn't noticed on your first visit.

Whatever your approach to this book I hope it will be useful to you: that you will find something in it to help you in your work, to illuminate a difficulty you have struggled with, to offer amusement or insight, to provoke you to thought, or in any other way to repay you for having opened it.

Michael Jackson
May 1995

Acknowledgements

Much of my working life so far has been occupied with devising, teaching, and using software development methods. In the 1970s and early 1980s I was deeply involved in the JSP method of program design and the JSD method of system development. Some of the themes and ideas of this book emerge indirectly from the successes of that work; some from its failures. I learned a lot from the many people I worked with during those years--especially from John Cameron.

I also learned a lot, although I did not always realize it at the time, from some people whose ideas about method were diametrically opposed to my own. As Mark Twain said: "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to twenty-one I was astonished at how much the old man had learned in seven years".

Many of the ideas in this book have been formed and sharpened during several years of cooperation with Pamela Zave. Particularly, they have been influenced by her approach to multiparadigm specification, and have benefited from the insightful work that she has done in cooperation with Peter Mataga on specifying telephone switching systems.

Daniel Jackson has helped me in more ways than I can count. He read the whole book in at least two of its versions and commented in detail on every part of it. He explained many things I had not known or had misunderstood. He discussed many of the topics with me at length. And he has always been ready to offer advice, encouragement, and constructive criticism at just the right moments. As a small recompense I have stolen a quotation by Niels Bohr from his PhD thesis.

Some of the ideas in the book have been aired at meetings of the Software Development Research Group of the University of the West of England, Bristol. I am grateful to the other members of the group--Barry Cawthorne, Ian Beeson, Richard McClatchey, Steve Probert, Tony Solomonides, and Chris Wallace--for their interest and help. Chris Wallace introduced me to the work on patterns in object-oriented design.

Tom DeMarco helped me generously with many acute and sensitive comments. His suggestions have removed many stumbling blocks from the reader's path.

Much of the treatment of Dekker's algorithm follows the presentation in Dick Whiddett's book Concurrent Programming for Software Engineers.

Andy Ware of Addison-Wesley has been unfailingly tolerant and courteous to an unreasonable and curmudgeonly author. And Susan Keany has been an agreeable and efficient production editor. It has been a pleasure to work with them both.

To all these people, and to everyone else who has helped me, I am very grateful. 0201877120P04062001

See all Editorial Reviews

Product Details

• Paperback: 228 pages
• Publisher: Addison-Wesley Professional (September 2, 1995)
• Language: English
• ISBN-10: 0201877120
• ISBN-13: 978-0201877120
• Product Dimensions: 9.1 x 6 x 0.6 inches
• Shipping Weight: 13.6 ounces (View shipping rates and policies)
• Average Customer Review: 4.6 out of 5 stars  See all reviews (17 customer reviews)
• Amazon.com Sales Rank: #116,774 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

12 of 12 people found the following review helpful:

5.0 out of 5 stars A must-read if you like to base practice on sound theory, October 1, 1998

By	Stephen Ferg ([e-mail]) (Washington, DC, USA) - See all my reviews

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).

15 of 16 people found the following review helpful:

5.0 out of 5 stars A powerful, pithy discussion of specifying solutions, May 8, 1999

By	David Stengle (Princeton, NJ USA) - See all my reviews (REAL NAME)

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.

11 of 11 people found the following review helpful:

5.0 out of 5 stars Spec writing for non tech, April 3, 2000

By A Customer

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.