Problem Frames: Analysing & Structuring Software Development Problems (Paperback)

~ Michael Jackson (Author)

Editorial Reviews

Product Description

This book is about Problem Frames - a concept developed by Michael Jackson. It is a practical book which demonstrates how to classify problems that occur during the development of software and how to recognise the correct solution to each problem

From the Inside Flap

Software development problems
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.

Problem frames
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

See all Editorial Reviews

Product Details

• Paperback: 416 pages
• Publisher: Addison-Wesley Professional (November 17, 2000)
• Language: English
• ISBN-10: 020159627X
• ISBN-13: 978-0201596274
• Product Dimensions: 9.2 x 7.4 x 0.9 inches
• Shipping Weight: 1.7 pounds
• Average Customer Review: 4.5 out of 5 stars  See all reviews (6 customer reviews)
• Amazon.com Sales Rank: #990,055 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

29 of 29 people found the following review helpful:

5.0 out of 5 stars A useful new approach to software requirements analysis, February 24, 2001

By	Stephen Ferg (Arlington, VA USA) - See all my reviews

"Problem Frames" is best regarded as volume 2 of a two-volume work whose first volume is Jackson's earlier book, "Software Requirements and Specifications". Before tackling "Problem Frames" you should dip into SRS. SRS is a relatively small book, an easy and enjoyable read, and very accessible. Then, if you find that you like SRS and want more, you should move on to "Problem Frames".

I tried out the Problem Frames Approach on a couple of my own software development problems, and found out that, just as Jackson asserts, it is a lot easier to think clearly about several small and relatively simple problems than it is to think about one big inchoate problem. Jackson calls this "separation of concerns", and PFA gives you the theoretical justification - and the tools - for doing it. And it works; it produces real and helpful insights and makes requirements analysis much more manageable.

Jackson's method of exposition is detailed discussion of illustrative examples. This means that you have to devote some effort to carefully following the details of many specific examples. If you do, then "Problem Frames" repeatedly passes the Aha! test.

This book and the Problem Frame Approach represent a major advance in the way we approach computer requirements specification. "Problem Frames" is as seminal a work for requirements analysis as Design Patterns was for object-oriented design. Anyone who is seriously interested in computer software requirements analysis -- and especially if you are familiar with Jackson's earlier works -- will absolutely want to study this book.

20 of 21 people found the following review helpful:

5.0 out of 5 stars A highly useful book for architects and analysts, March 2, 2001

By	Daniel Duffy (Netherlands) - See all my reviews

This is an excellent book. Michael Jackson resolves a number of major problems by drawing a distinction between the description of the problem domain and the description of the solution domain. This is needed because current object-oriented techniques (based on UML, for example) tend to be solution-oriented in the early stages of the software development lifecycle. This mindset can lead to maintainability problems later. Another 'gem' is that Jackson develops a scheme for decomposing a problem into simpler subproblems. This 'divide and conquer' approach has been known to mathematicians for hundreds of years. Structured analysis methods use similar techniques but they have seemingly been forgotten (or never learned?) by the OO community where the objects are there 'just for the picking' (to quote Bertrand Meyer). This reviewer now realises that life is not so simple. I have benefited from Jackson's problem frames and have applied them as a 'front-end' to UML in order to structure medium and large systems. In particular, viewing a specific application (such as a home heating system, ATM ...) as an instance of a more general category is very useful as it allows us to gain insights into the current problem. I have specialised the frames to discover domain categories for process control, manufacture, MIS, access control and tracking. This book could trigger a number of developments. For example, discovering and documenting structural and behavioural patterns in this phase of the software development lifecycle could would be a good idea. In particular, looking at requirements as goals instead of jumping directly into the over-hyped use cases seems like a good idea as well. To this end, it might be worth looking at a number of methods that are mentioned in the book, for example KAOS.

24 of 26 people found the following review helpful:

5.0 out of 5 stars A solid approach to identifying and analyzing problems, April 22, 2001

By	Mike Tarrani "www.tarrani.com" (Deltona, FL USA) - See all my reviews (TOP 500 REVIEWER)    (REAL NAME)    (COMMUNITY FORUM 04)

Short and sweet: this book is about structuring and analyzing problems, not about solutions. In fact, from the beginning the author discusses the difficulty of focusing on problems and the tendency to jump to a solution before the problem is completely understood.

The structured approach that Mr. Jackson provides starts with bounding the problem and drilling down into subproblems, called problem frames. I like his approach to bounding problems because it shows how to identify and isolate the problem and place it into its proper context. This forces you to focus on the problem and not drift off into a premature solution. I also like how he breaks down problems into manageable chunks by placing subproblems into domains through the use of projections (where subproblem domains overlap) and partitions (where associated phenomena are isolated). This allows you to see the whole problem in its magnificent splendor, which is the first step towards tackling each of its parts.

As Mr. Jackson's approach evolves you will find patterns emerging. If you are a proponent of design patterns you will appreciate how he breaks problems into classes and five basic frames. This is a powerful concept because as you gain experience using problem frames you will be able to quickly classify problems and approach them in a consistent, repeatable manner. This part of the book greatly influenced my way of thinking about problems, and the material is reinforced by examples given in subsequent chapters, as well as chapters devoted to variant and composite frames.

This book is ostensibly about problem frames and methods as they relate to software development. However, the approach given in the book has much wider applications. I was able to relate it to physical devices, processes and procedures. Moreover, Mr. Jackson's approach itself can be decomposed into a collection of useful tools and techniques that, taken individually, will prove invaluable in requirements analysis, design and related endeavors. I am giving it 5 stars only because I cannot give it more.