Problem frames approach

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.

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[3] was held as part of ICSE 2006 in Shanghai, China.

The Third International Workshop on Applications and Advances in Problem Frames (IWAAPF)[4] was held as part of ICSE 2008 in Leipzig, Germany.

IWAAPO broadens the focus of the workshops to include alternative and complementary approaches to software development that share an emphasis on problem analysis.

[5] IWAAPO-2010 was held as part of ICSE 2010 in Cape Town, South Africa.

[6] 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[7][8] 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.

... [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. [11] None of these appear in the interface with the computer....

In a problem frame, domains are given general names and described in terms of their important characteristics.

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.

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.

It consists of phenomena — individuals, events, states of affairs, relationships, and behaviors.

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.

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 tilde (~) indicates that the requirement is about a relationship or correspondence between the panel display and patient conditions.

Jackson also discusses certain kinds of concerns that arise when working with problem frames.