Software Requirements And Specifications
Addison-Wesley Professional, 1st edition, (August 1995)Abstract
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.
Description
zotero