Problem Frames

1. PROBLEM FRAMES
Joseph k Raj
M. Tech 1st Sem

2. HISTORY OF PROBLEM FRAMES
• Problem frames is an approach to Software Requirements Analysis. It
was developed by British software consultant Michael A. Jackson in
the 1995.
• It has received its fullest description in his Problem Frames: Analysing
and Structuring Software Development Problems (2001).

3. PROBLEM FRAME
• It is a description of a recognizable class of problems, where the class of
problems has a known solution
• It provide a conceptual language for recognizing familiar problems in the client’s
requirements.
• A recognized class of problems is called a problem frame.
• What happens if you just start building right away?
• You could build the wrong system
• You could discover a critical issue late in development.

4. DOMAINS
In problem or
context diagrams
In problem frame
diagrams
Machine
Domain
Given
Domain
• The system to be built
Machine
Domain
Causal
Domain
• Behavior might be partial
 Behaves predictably
 But might fail
C
Given
Domain
 Behaves unpredictably
 Often a human user
Biddable
Domain
B
Designed
Domain
Lexical
Domain
 Data repository
 Physical embodiment ignored
X

5. CONTEXT DIAGRAMS
Given
Domain 1
a
Machine
Domain
c
d
b
Given
Domain 2
• Show the relevant domains in the problem
• Lines show shared phenomena (events, states)
•
•
•
•
a – states shared only by machine and domain 1
b – states shared only by machine and domain 2
c – states shared only by domains 1 and 2
d – states shared by all three domains

6. RECOGNIZED PROBLEM FRAMES
• Required Behaviour
• Commanded Behaviour
• Information Display
• Simple Workpieces
• Transformation

7. REQUIRED BEHAVIOUR
• 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.
Control
Machine
b
Controlled
Domain
a
Required
Behaviour

8. COMMANDED BEHAVIOUR
• There is some part of the physical world whose behaviour 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.
b
Operator
a
Control
Machine
Commanded
Behaviour
c
Controlled
Domain
d

9. INFORMATION DISPLAY
• There is some part of the physical world about whose states and behaviour 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.
b
Real World
a
Information
Machine
DisplayReal World
c
Display
d

10. SIMPLE WORKPIECES
• A tool is needed to allow a user to create and edit a certain class of computer
processing text or graphic objects, or similar structures, so that they can be
subsequently copied, printed, analysed or used in other ways. The problem is to build a
machine that can act as this tool.
b
User
a
Ending
Tool
Command
Effects
c
Work
Pieces
d

11. TRANSFORMATION
• 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.
b
Inputs
a
Transform
Machine
IO
Relation
c
Outputs
d

12. EXAMPLE: ONE-WAY TRAFFIC LIGHTS
• The repairers put one unit at each end of the one-way
section and connect it to a small computer that controls the
sequence of lights. Each unit has a Stop light and a Go
light. The computer controls the lights by emitting RPulses
and GPulses, to which the units respond by turning the
lights on and off. The regime for the lights repeats a fixed
cycle of four phases. First, for 50 seconds, both units show
Stop; then, for 120 seconds, one unit shows Stop and the
other Go; then for 50 seconds, both show Stop again; then
for 120 seconds the unit that previously showed Go shows
Stop, and the other shows Go. Then the cycle is repeated.

13. ONE-WAY TRAFFIC PROBLEM DIAGRAM
Lights
Controller
a
b
Light units
Light cycle
• a: { RPulse1, GPulse1, RPulse2, GPulse2 }
• b: { Stop1, Go1, Stop2, Go2 }
• Exclamation point shows which domain controls events
• a: LC ! { RPulse1, GPulse1, RPulse2, GPulse2 }
• b: LU ! { Stop1, Go1, Stop2, Go2 }
• Notice that we carefully distinguish pulses from lights