Software Requirements And Specifications

Michael Jacksonhas worked in software for over thirty years, during which time he has been involved in all aspects of program and system development. In 1971 he started his own company offering courses, project support and tools for software developers. He now works as an independent consultant in London, and works part time in software development at AT&T Research in New Jersey. He played the leading role in developing the JSP and JSD methods of program and system more >>

Michael Jacksonhas worked in software for over thirty years, during which time he has been involved in all aspects of program and system development. In 1971 he started his own company offering courses, project support and tools for software developers. He now works as an independent consultant in London, and works part time in software development at AT&T Research in New Jersey. He played the leading role in developing the JSP and JSD methods of program and system develpment.

Software Reqiuirements and Specifications is the latest book from Michael Jackson, one of the foremost contributors to software development method and practice. The book brings together some 75 short pieces about principles and techniques for requirements analysis, specification and design.

The ideas discussed are deep, but at the same time lightly and wittily expressed. The book is fun to read, rewarding the reader with many valuble and novel insights. Some sacred cows, including top-down development, dataflow diagrams and the distinction between What and How, are led to the slaughter. Readers will be provoked--perhaps to fury, perhaps to enthusiasm, but surely to think more deeply about topics and issues of central importance in the field of software development.

There are new ideas about problem structuring, based on the concept of a problem frame, leading to a clearer notion of complexity and how to deal with it. And other important topics include:

• Principles for evaluating development methods
• New approaches to capturing and describing requirements and specifications, based on the relationship between the software system and the problem context
• The technology of desciption in software, including new ideas such as designations, the separation of descriptive moods and the scope and span of description
• Incisive information about the proper role of mathematics and formalism.

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 << less