From the Inside Flap
The central goal in a software development problem is to create the software for a computer system that will serve some useful purpose in the world. This book is about analysing and structuring problems of this kind.
These problems are found in many different contexts and forms. If you are doing software development you might be building a system to act as a repository and access mechanism for information about bank accounts and loans. You might be developing a telephone exchange to switch local calls. You might be creating a tool for writing and editing texts and diagrams; or a control device to maintain cruising speed in a car; or a compiling machine to transform Java programs into bytecode. Almost any part of the human and physical world can furnish the raw material and the context for a software development problem.
Because computers can serve so many purposes, and play the central role in solving so many different kinds of problem, the practice of software development is less specialised than the established engineering disciplines. For the individual developer, and the individual development project, there's a lot more variety. That's why you should usually start by describing and structuring your problem in a way that's rarely necessary in other engineering disciplines, where the diversity of problems to be solved is much smaller. The automobile engineer designing a sports car does not need to ask whether the car must be capable of carrying 15 people, travelling underwater, carrying a ten-ton load, or moving backwards at 100mph. The phrase 'sports car' specifies both the problem and its acceptable solutions closely enough to answer those questions and many others.
But as a software developer you are rarely solving an immediately recognisable and well understood problem. Usually, you must begin by asking: What kind of problem is this? What, exactly, is the problem about? What purpose is being served in the world? What behaviour and properties must the computer have to achieve that purpose? Often, software development seems to start at square one.
When you analyse a problem you see what kind of problem it is, and identify the concerns and difficulties you will have to deal with to solve it. The concerns in a Java compiler will be very different from the concerns in a car braking system. You have different things to think about. Different kinds of descriptions must be made, and fitted together into differently shaped arguments. Problem analysis takes you from the level of identifying the problem to the level of making the descriptions needed to solve it.
But most realistic problems are too big and complex to handle in just two levels like this. Another level is needed: structuring the problem as a collection of interacting subproblems. If your structuring is successful, the subproblems will be smaller and simpler than the problem you started with, and their interactions will be clear and understandable. Then you can analyse each subproblem separately, as a simple problem on its own, and make the descriptions it needs.
The central idea of this book is to use problem frames in problem analysis and structure. They help you by defining different simple problem classes. When you structure a larger, realistic problem, you choose the subproblems so that each one is a problem of the simple kind defined by some problem frame. Then, when you analyse the subproblem, you see what concerns it raises according to the problem frame that fits it. The frame shows you what you must do to solve it.
A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions. They do this by emphasising the world outside the computer, the effects that are required there, and the relationships among things and events of the world by which your customer will ultimately judge whether those effects have been achieved.
Problem frames share much of the spirit of design patterns. Design patterns look inwards towards the computer and its software, while problem frames look outwards to the world where the problem is found. But they both identify and describe recurring situations. They provide a taxonomy within which each increment of experience and knowledge you acquire can be assigned to its proper place in a larger scheme, and can be shared and accessed more effectively. So just as in object-oriented design a familiarity with design patterns allows you to say 'we need an instance of the decorator pattern here', so in problem decomposition a familiarity with problem frames allows you to say 'this part of the problem is a workpieces problem'. Having identified a part of a problem with a recognised problem frame, you can draw on experience associated with the frame.
The problem frame idea was first published in book form in my book Software Requirements & Specifications, where it was sketched in outline as one of a small number of related topics. This book puts more flesh on that skeleton. A number of elementary and composite problem frames are discussed and illustrated, along with a number of flavours and variants, and some of the concerns they raise are examined. The use of problem frames in decomposing realistic problems into subproblems is also explored and illustrated.
A focused view
Some people think that this notion of software development problems derives from a perspective that is too sharply focused and too narrow. They point out that computer systems, and the process of software development itself, almost always exist in a complex and fluid social, political, ethical and economic environment. When you are discovering the requirements for a system you are likely to be engaged in a process of social negotiation among conflicting groups of stakeholders; when you make a decision about system functionality you may be implicitly favouring one group over another; when you enlarge the system scope you are often giving political power to one group at the expense of another; when you analyse the purposes to be served by the system you are exploring its economic and organisational consequences.
So, from this point of view, the major concerns in software development are social and political, organisational and economic. Thinking in terms of problems doesn't do justice to these concerns. It's true that these concerns are important in many developments, but nonetheless we are going to ignore them in this book. We are not going to discuss how to elicit requirements, how to make the business case, how to manage the project, facilitate meetings, or negotiate compromise. We will ignore these things, not because they are unimportant but simply because they are not the subject matter of this book. If you want to understand anything, you mustn't try to understand everything.
Instead, we are going to try to understand some more sharply focused ideas in problem structure and analysis in the context of software development. Our chief topics will be the material, observable effects that the system should bring about in the world, the computer behaviour that will achieve those effects, and the connection between them. In short, the topics that are often called functional requirements, software specifications, and the path by which you get from one to the other.
Focusing on problems
It is not easy to focus on problems in software development. One reason is that they have some precise and some imprecise aspects, all competing for your attention. Like Odysseus on his ship coming home from Troy, you are sailing between Scylla and Charybdis, and must try to steer a middle course.
If you are attracted by the arguments of the people who regard our view of problems as far too formal and narrow, you may be dragged off to the right, into the world of purely human problems - the imprecise world of sociology and ethnography, where nothing is ever completely certain or completely exact. That's an important world, but it neglects the software and its development.
However, if you find that problems are less exciting than their software solutions, you are more likely to veer off to the left, towards the much more precise world of programming - of variables and methods and object classes, where boolean values are always either True or False, and never anything in between. Progamming is also important, but it won't be useful if no one has analysed the problem and worked out what the programs must do.
In the problems discussed in this book, there are plenty of precise and plenty of imprecise ingredients. We will try to do justice to both, to steer the proper course for understanding and analysing problems.
Formality and informality
If you steer the proper course between Scylla and Charybdis, and succeed in focusin
From the Back Cover
¿Understanding and using problem frames will likely become an essential skill of all good software system designers. Jackson's book provides a beautifully crafted pathway into this world.¿¿David Garlan, Associate Professor, Computer Science Department, Carnegie Mellon University
¿In 'Problem Frames' I believe that Michael Jackson has taken the mysticism that surrounds design patterns and constructed a much more accessible technique utilizing a frame metaphor.¿
¿Warren Keuffel, Senior Contributing Editor, Software Development Magazine
It is tempting when approaching a software development problem to rush headlong into the trap of thinking too soon about the solution. Software development problems are about the world outside the computer ¿ the real environment in which the system must have its effect ¿ and demand consideration of the surrounding characteristics, relationships and context. Problem frames are a tool for classifying, analyzing and structuring such software development problems. Whereas object oriented patterns are primarily concerned with solutions, problem frames focus on the problem itself, enabling you to understand and address it clearly and directly.
This book is a must-have for all IT professionals facing software development problems on a daily basis. If you are a systems analyst or requirements engineer it will provide an essential, practical guide from the task of identifying the problem to making the descriptions needed to resolve it.
It will help you:
- decompose complex problems into simpler sub-problems and see how the subproblems fit together
- build up a repertoire of simple, clear and easily applicable problem classes which you can access and reuse, drawing on the experience associated with each class