Problem analysis or the problem frames approach is an approach to software requirements analysis. It was developed by British software consultant Michael A. Jackson in the 1990s.
History The problem frames approach was first sketched by Jackson in his book Software Requirements & Specifications (1995) and in a number of articles in various journals devoted to software engineering. It has received its fullest description in his Problem Frames: Analysing and Structuring Software Development Problems (2001). A session on problem frames was part of the 9th International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ)] held in Klagenfurt/Velden, Austria in 2003. The First International Workshop on Applications and Advances in Problem Frames was held as part of ICSE’04 held in Edinburgh, Scotland. One outcome of that workshop was a 2005 special issue on problem frames in the International Journal of Information and Software Technology. The Second International Workshop on Applications and Advances in Problem Frames was held as part of ICSE 2006 in Shanghai, China. The Third International Workshop on Applications and Advances in Problem Frames (IWAAPF) was held as part of ICSE 2008 in Leipzig, Germany. In 2010, the IWAAPF workshops were replaced by the International Workshop on Applications and Advances of Problem-Orientation (IWAAPO). IWAAPO broadens the focus of the workshops to include alternative and complementary approaches to software development that share an emphasis on problem analysis. IWAAPO-2010 was held as part of ICSE 2010 in Cape Town, South Africa. Today research on the problem frames approach is being conducted at a number of universities, most notably at the Open University in the United Kingdom as part of its Relating Problem & Solution Structures research theme The ideas in the problem frames approach have been generalized into the concepts of problem-oriented development (POD) and problem-oriented engineering (POE), of which problem-oriented software engineering (POSE) is a particular sub-category. The first International Workshop on Problem-Oriented Development was held in June 2009.
Overview
Fundamental philosophy Problem analysis or the problem frames approach is an approach — a set of concepts — to be used when gathering requirements and creating specifications for computer software. Its basic philosophy is strikingly different from other software requirements methods in insisting that:
The best way to approach requirements analysis is through a process of parallel — not hierarchical — decomposition of user requirements. User requirements are about relationships in the real world—the application domain – not about the software system or even the interface with the software system.
It is more helpful ... to recognize that the solution is located in the computer and its software, and the problem is in the world outside. ... The computers can provide solutions to these problems because they are connected to the world outside.
The moral is clear: to study and analyse a problem you must focus on studying and analysing the problem world in some depth, and in your investigations you must be willing to travel some distance away from the computer. ... [In a call forwarding problem...] You need to describe what's there – people and offices and holidays and moving office and delegating responsibility – and what effects [in the problem world] you would like the system to achieve – calls to A's number must reach A, and [when B is on vacation, and C is temporarily working at D's desk] calls to B's or C's number must reach C.
None of these appear in the interface with the computer.... They are all deeper into the world than that.
The approach uses three sets of conceptual tools.
Tools for describing specific problems Concepts used for describing specific problems include: phenomena (of various kinds, including events), problem context, problem domain, solution domain (a.k.a. the machine), shared phenomena (which exist in domain interfaces), domain requirements (which exist in the problem domains) and specifications (which exist at the problem domain:machine interface). The graphical tools for describing problems are the context diagram and the problem diagram.
Tools for describing classes of problems (problem frames) The Problem Frames Approach includes concepts for describing classes of problems. A recognized class of problems is called a problem frame (roughly analogous to a design pattern). In a problem frame, domains are given general names and described in terms of their important characteristics. A domain, for example, may be classified as causal (reacts in a deterministic, predictable way to events) or biddable (can be bid, or asked, to respond to events, but cannot be expected always to react to events in any predictable, deterministic way). (A biddable domain usually consists of people.) The graphical tool for representing a problem frame is a frame diagram. A frame diagram looks generally like a problem diagram except for a few minor differences—domains have general, rather than specific, names; and rectangles representing domains are annotated to indicate the type (causal or biddable) of the domain.
A list of recognized classes of problems (problem frames) The first group of problem frames identified by Jackson included:
required behavior commanded behavior information display simple workpieces transformation Subsequently, other researchers have described or proposed additional problem frames.
Describing problems
The problem context Problem analysis considers a software application to be a kind of software machine. A software development project aims to change the problem context by creating a software machine and adding it to the problem context, where it will bring about certain desired effects. The particular portion of the problem context that is of interest in connection with a particular problem — the particular portion of the problem context that forms the context of the problem — is called the application domain. After the software development project has been finished, and the software machine has been inserted into the problem context, the problem context will contain both the application domain and the machine. At that point, the situation will look like this:
… excerpt ends here. Continue reading the full article.






