Problem Frames Approach
Encyclopedia
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.
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 Interesting work is being done by Professors Lavazza and del Bianco on using problem frames with UML.
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.
The approach uses three sets of conceptual tools.
phenomena (of various kinds, including events),
problem context,
problem domain,
solution domain (aka 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.
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.
Subsequently, other researchers have described or proposed additional problem frames.
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:
The problem context contains the machine and the application domain. The machine interface is where the Machine and the application domain meet and interact.
The same situation can be shown in a different kind of diagram, a context diagram, this way:
Here is Jackson's description of examining the problem context, in this case the context for a bridge to be built:
An analyst trying to understand a software development problem must go through the same process as the bridge engineer. He starts by examining the various problem domains in the application domain. These domains form the context into which the planned Machine must fit. Then he imagines how the Machine will fit into this context. And then he constructs a context diagram showing his vision of the problem context with the Machine installed in it.
The context diagram shows the various problem domains in the application domain, their connections, and the Machine and its connections to (some of) the problem domains. Here is what a context diagram looks like.
This diagram shows:
A domain is simply a part of the world that we are interested in. It consists of phenomena — individuals, events, states of affairs, relationships, and behaviors.
A domain interface is an area where domains connect and communicate. Domain interfaces are not data flows or messages. An interface is a place where domains partially overlap, so that the phenomena in the interface are shared phenomena — they exist in both of the overlapping domains.
You can imagine domains as being like primitive one-celled organisms (like amoebas). They are able to extend parts of themselves into pseudopods. Imagine that two such organisms extend pseudopods toward each other in a sort of handshake, and that the cellular material in the area where they are shaking hands is mixing, so that it belongs to both of them. That's an interface.
In the following diagram, X is the interface between domains A and B. Individuals that exist or events that occur in X, exist or occur in both A and B.
Shared individuals, states and events may look differently to the domains that share them. Consider for example an interface between a computer and a keyboard. When the keyboard domain sees an event Keyboard operator presses the spacebar the computer will see the same event as Byte hex("20") appears in the input buffer.
In addition to the kinds of things shown on a context diagram, a problem diagram shows:
An interface that connects a problem domain to the machine is called a specification interface and the phenomena in the specification interface are called specification phenomena. The goal of the requirements analyst is to develop a specification for the behavior that the Machine must exhibit at the Machine interface in order to satisfy the requirement.
Here is an example of a real, if simple, problem diagram.
This problem might be part of a computer system in a hospital. In the hospital, patients are connected to sensors that can detect and measure their temperature and blood pressure. The requirement is to construct a Machine that can display information about patient conditions on a panel in the nurses station.
The name of the requirement is "Display ~ Patient Condition". The tilde (~) indicates that the requirement is about a relationship or correspondence between the panel display and patient conditions. The arrowhead indicates that the requirement reference connected to the Panel Display domain is also a requirement constraint. That means that the requirement contains some kind of stipulation that the Panel display must meet. In short, the requirement is that The panel display must display information that matches and accurately reports the condition of the patients.
Each problem frame has its own frame diagram. A frame diagram looks essentially like a problem diagram, but instead of showing specific domains and requirements, it shows types of domains and types of requirements; domains have general, rather than specific, names; and rectangles representing domains are annotated to indicate the type (causal or biddable) of the domain.
frames that he had identified. A variant typically adds a domain to the problem context.
Particular concerns
Composition concerns
Subsequently, other researchers have described or proposed additional problem frames.
, the software development lifecycle starts with the problem analyst, who studies the situation and:
At this point, problem analysis — problem decomposition — is complete. The next step is to reverse the process and to build the desired software system though a process of solution composition.
The solution composition process is not yet well-understood, and is still very much a research topic. Extrapolating from hints in Software Requirements & Specifications, we can guess that the software development process would continue with the developers, who would:
Requirements analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
. It was developed by British software consultant Michael A. Jackson
Michael A. Jackson
Michael Anthony Jackson is a British computer scientist, and independent computing consultant in London, England. He is also part-time researcher at AT&T Research, Florham Park, NJ, U.S., and visiting research professor at the Open University in the UK.- Biography :Jackson was educated at Harrow...
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
Open University
The Open University is a distance learning and research university founded by Royal Charter in the United Kingdom...
in the United Kingdom as part of its Relating Problem & Solution Structures research theme Interesting work is being done by Professors Lavazza and del Bianco on using problem frames with UML.
The ideas in the problem frames approach have been generalized into the concepts of problem-oriented development
Problem-Oriented Development
Problem-Oriented Development is an emerging paradigm of computing that emphasises problems as the primary subject of scrutiny by software engineers...
(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.
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.
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 (aka 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.
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:
The same situation can be shown in a different kind of diagram, a context diagram, this way:
The context diagram
The problem analyst's first task is to truly understand the problem. That means understanding the context in which the problem is set. And that means drawing a context diagram.Here is Jackson's description of examining the problem context, in this case the context for a bridge to be built:
- You're an engineer planning to build a bridge across a river. So you visit the site. Standing on one bank of the river, you look at the surrounding land, and at the river traffic. You feel how exposed the place is, and how hard the wind is blowing and how fast the river is running. You look at the bank and wonder what faults a geological survey will show up in the rocky terrain. You picture to yourself the bridge that you are going to build. (Software Requirements & Specifications: "The Problem Context")
An analyst trying to understand a software development problem must go through the same process as the bridge engineer. He starts by examining the various problem domains in the application domain. These domains form the context into which the planned Machine must fit. Then he imagines how the Machine will fit into this context. And then he constructs a context diagram showing his vision of the problem context with the Machine installed in it.
The context diagram shows the various problem domains in the application domain, their connections, and the Machine and its connections to (some of) the problem domains. Here is what a context diagram looks like.
- the machine to be built. The dark border helps to identify the box that represents the Machine.
- the problem domains that are relevant to the problem.
- the solid lines represent domain interfaces — areas where domains overlap and share phenomena in common.
A domain is simply a part of the world that we are interested in. It consists of phenomena — individuals, events, states of affairs, relationships, and behaviors.
A domain interface is an area where domains connect and communicate. Domain interfaces are not data flows or messages. An interface is a place where domains partially overlap, so that the phenomena in the interface are shared phenomena — they exist in both of the overlapping domains.
You can imagine domains as being like primitive one-celled organisms (like amoebas). They are able to extend parts of themselves into pseudopods. Imagine that two such organisms extend pseudopods toward each other in a sort of handshake, and that the cellular material in the area where they are shaking hands is mixing, so that it belongs to both of them. That's an interface.
In the following diagram, X is the interface between domains A and B. Individuals that exist or events that occur in X, exist or occur in both A and B.
Problem diagrams
The problem analyst's basic tool for describing a problem is a problem diagram. Here is a generic problem diagram.- a dotted oval representing the requirement to bring about certain effects in the problem domains.
- dotted lines representing requirement references — references in the requirement to phenomena in the problem domains.
An interface that connects a problem domain to the machine is called a specification interface and the phenomena in the specification interface are called specification phenomena. The goal of the requirements analyst is to develop a specification for the behavior that the Machine must exhibit at the Machine interface in order to satisfy the requirement.
Here is an example of a real, if simple, problem diagram.
The name of the requirement is "Display ~ Patient Condition". The tilde (~) indicates that the requirement is about a relationship or correspondence between the panel display and patient conditions. The arrowhead indicates that the requirement reference connected to the Panel Display domain is also a requirement constraint. That means that the requirement contains some kind of stipulation that the Panel display must meet. In short, the requirement is that The panel display must display information that matches and accurately reports the condition of the patients.
Problem frames
A problem frame is a description of a recognizable class of problems, where the class of problems has a known solution. In a sense, problem frames are problem patterns.Each problem frame has its own frame diagram. A frame diagram looks essentially like a problem diagram, but instead of showing specific domains and requirements, it shows types of domains and types of requirements; domains have general, rather than specific, names; and rectangles representing domains are annotated to indicate the type (causal or biddable) of the domain.
Variant frames
In Problem Frames Jackson discussed variants of the five basic problemframes that he had identified. A variant typically adds a domain to the problem context.
- a description variant introduces a description lexical domain
- an operator variant introduces an operator
- a connection variant introduces a connection domain between the machine and the central domain with which it interfaces
- a control variant introduces no new domain; it changes the control characteristics of interface phenomena
Problem concerns
Jackson also discusses certain kinds of concerns that arise when working with problem frames.Particular concerns
- overrun
- initialization
- reliability
- identities
- completeness
Composition concerns
- commensurable descriptions
- consistency
- precedence
- interference
- synchronization
Recognized problem frames
The first 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.
Required-behavior problem frame
The intuitive idea behind this problem frame is:- There is some part of the physical world whose behavior is to be controlled so that it satisfies certain conditions. The problem is to build a machine that will impose that control.
Commanded-behavior problem frame
The intuitive idea behind this problem frame is:- There is some part of the physical world whose behavior is to be controlled in accordance with commands issued by an operator. The problem is to build a machine that will accept the operator's commands and impose the control accordingly.
Information display problem frame
The intuitive idea behind this problem frame is:- There is some part of the physical world about whose states and behavior certain information is continually needed. The problem is to build a machine that will obtain this information from the world and present it at the required place in the required form.
Simple workpieces problem frame
The intuitive idea behind this problem frame is:- A tool is needed to allow a user to create and edit a certain class of computer-processible text or graphic objects, or similar structures, so that they can be subsequently copied, printed, analyzed or used in other ways. The problem is to build a machine that can act as this tool.
Transformation problem frame
The intuitive idea behind this problem frame is:- There are some given computer-readable input files whose data must be transformed to give certain required output files. The output data must be in a particular format, and it must be derived from the input data according to certain rules. The problem is to build a machine that will produce the required outputs from the inputs.
Problem analysis and the software development process
When problem analysis is incorporated into the software development processSoftware development process
A software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...
, the software development lifecycle starts with the problem analyst, who studies the situation and:
- creates a context diagram
- gathers a list of requirements and adds a requirements oval to the context diagram, creating a grand "all-in-one" problem diagram. (However, in many cases actually creating an all-in-one problem diagram may be impractical or unhelpful: there will be too many requirements references criss-crossing the diagram to make it very useful.)
- decomposes the all-in-one problem and problem diagram into simpler problems and simpler problem diagrams. These problems are projections, not subsets, of the all-in-one diagram.
- continues to decompose problems until each problem is simple enough that it can be seen to be an instance of a recognized problem frame. Each subproblem description includes a description of the specification interfaces for the machine to be built.
At this point, problem analysis — problem decomposition — is complete. The next step is to reverse the process and to build the desired software system though a process of solution composition.
The solution composition process is not yet well-understood, and is still very much a research topic. Extrapolating from hints in Software Requirements & Specifications, we can guess that the software development process would continue with the developers, who would:
- compose the multiple subproblem machine specifications into the specification for a single all-in-one machine: a specification for a software machine that satisfies all of the customer's requirements. This is a non-trivial activity — the composition process may very well raise composition problems that need to be solved.
- implement the all-in-one machine by going through the traditional code/test/deploy process.
Similar approaches
There are a few other software development ideas that are similar in some ways to problem analysis.- The notion of a design patternDesign pattern (computer science)In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that...
is similar to Jackson's notion of a problem frame. It differs in that a design pattern is used for recognizing and handling design issues (often design issues in specific object-oriented programming languages such as C++ or Java) rather than for recognizing and handling requirements issues. Furthermore one difference is that design patterns cover solutions while in problem frames problems are represented. - Aspect-oriented programming, AOP (also known as aspect-oriented software developmentAspect-oriented software developmentIn computing, Aspect-oriented software development is an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic...
, AOSD) is similarly interested in parallel decomposition, which addresses what AOP proponents call cross-cutting concerns or aspects. AOP addresses concerns that are much closer to the design and code-generation phase than to the requirements analysis phase. - Martin Fowler's book Analysis Patterns is very similar to problem analysis in its search for patterns. It doesn't really present a new requirements analysis method, however. And the notion of parallel decomposition — which is so important for problem analysis — is not a part of Fowler's analysis patterns.
- Jon G. Hall, Lucia Rapanotti, together with Jackson, have developed the Problem Oriented Software Engineering (POSE) framework which shares the problem frames foundations. Since, 2005, Hall and Rapanotti have extended POSE to Problem Oriented Engineering (POE), which provides a framework for engineering design, including a development process model and assurance-driven design, and may be scalable to projects that include many stake-holders and that combine diverse engineering disciplines such as software and education provision.
External links
- http://mcs.open.ac.uk/mj665/ is Michael A. JacksonMichael A. JacksonMichael Anthony Jackson is a British computer scientist, and independent computing consultant in London, England. He is also part-time researcher at AT&T Research, Florham Park, NJ, U.S., and visiting research professor at the Open University in the UK.- Biography :Jackson was educated at Harrow...
's home page - http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html has papers and articles on the Problem Frames Approach