1. LECTURE 12: Problem Frames Part I: Decomposition
Michael A. Jackson's home page:
Ivan Marsic
Rutgers University

2. Topics Typical System Requirements and Problems → Analysis Reuse
Five Problem Frames:
Transformation
Simple Editing
Required Behavior
Information Display
Commanded Behavior
Frame Concern

3. Why Problem Frames?
Because the best way to start solving your problem is by understanding it first.
Problem frames help us analyze and understand the problem that we are to solve.
Problem frames are the building blocks of SE problems
They are the most basic user stories or use cases
Purpose: problem frames allow reuse of existing generic analyses of typical problems
Benefits: speed up the analysis and make the result more complete

4. Software Engineering Problem
User has business goals in the problem domain
System-to-be will help the user achieve these goals
Problem domain can be imagined or physical world
System-to-be
User’s business goals determine the system requirements
User
Requirement
Problem Domain

5. Requirements and Specification
Problem domain
Software (Solution) domain
Describes
Specifi cation
Requirements
Program (System)
Customer
Specifies
Analyzes
Develops
Software Engineer

6. Problem Domain: How Electronic Lock Works
We may need separate descriptions/models of door vs. lock.
Door state is what the user cares about; lock is one way of achieving it.
Computer
Lock
Voltage:
HIGH
Physical domain (lock) description; used in specification
LOW
lock armed
lock disarmed
lock armed
Semantic meaning defined by user’s goals; used in requirements
The behavior of the system-to-be determined not only by user’s actions but also by the context (“situation”).
E.g., what in case of power failure?
- By default armed
- By default disarmed (e.g., fire exit)

7. Analyst’s Task: Three Descriptions
The requirement
The problem domain
What user wants:
When valid keycode entered + Unlock pressed, open the lock;
Automatically lock after a period of time.
The specification
How problem domain behaves:
What software-to-be will do:
If entered number matches one of stored numbers + Button-1 pressed, put HIGH voltage on Output-port-1;
Start a timer countdown;
When the timer expires, put LOW voltage on Output-port-1.
Armed
Concern: can the entered number have more digits than a valid keycode? If yes, which digits are considered? What if the user attempted using invalid keys and gave up before reaching the limit? Can the automatic locking be disabled if needed? What if the door is not shut when the lock is being armed?
LOW /
HIGH /
Disarmed
Concern:
It is not obvious that this is the only or even “correct” solution to the requirement-posed problem.
Electromechanical lock
Problem Frames tell us what each description should contain and how to verify the concern.

8. Problem Framing
Problem framing means dividing the problem at its “seams” into smaller sub-problems
The difficulty is in recognizing the “seams”
Problem frames are derived from commonly occurring software requirements
They afford ready-made templates for requirements analysis and system specification
We look for such basic problems to help us discover the “seams” of our problem

9. Complex Problem Decomposition
Software-to-be
Problem Domain
Business Goal
(User’s Requirement)
(a)
Frame Approach:
Split the big “black box” into several smaller “black boxes”, each addressing a subset of the requirements and representing a mini-project.
During the analysis, we consider each subproblem separately.
Problem decomposition
Requirement ii
Requirement i
Requirement
iii
Requirement iv
Domain B
Domain A
Domain C
Domain D
(b)
Domain E
Subsystem 1
Subsystem 2
Subsystem 3
Subsystem 4
Software-to-be 9

10. Typical Software Eng. Problems
1.a) System transforms input document to output document
1. User works with computer system
(problem domain is “virtual”, not physical)
REQ-1: Map input data to output data as said by given rules
IN doc
User
System
OUT doc
1.b) User edits information stored in a repository
System
Problem domain
User
REQ-2: Allow repository editing, where “repository” is a collection of data
User
System
Repository
2. Computer system controls the (physical) problem domain
(user not involved)
REQ-3: Autonomously control a physical object/device
System
Problem domain
User
3.a) System observes the problem domain and displays information
3. Computer system intermediates between
the user and the problem domain
REQ-5: Monitor and display information about an object
User
System
Problem domain
3.b) System controls the problem domain as commanded by the user
User
System
Problem domain
REQ-4: Interactively control a physical object/device
User
System
Problem domain

11. Typical System Requirements
REQ-1: Map input data to output data as said by given rules
REQ-2: Allow repository (or document) editing, where “repository” is a collection of data
REQ-3: Autonomously control a physical object/device
REQ-4: Interactively control a physical object/device
REQ-5: Monitor and display information about an object
Critical insight: there are known approaches for analyzing each of these requirement types, including the information that should be specified for each type

12. Example: Problem Decomposition
REQ1: Keep door locked and auto-lock
REQ2: Lock when “LOCK” pressed
REQ3: Unlock when valid key provided
REQ4: Allow mistakes but prevent dictionary attacks
REQ5: Maintain a history log
REQ6: Adding/removing users at runtime
REQ7: Configuring device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries
PROBLEM DOMAIN
(5) Device preferences
(6) Photosensor
(7) Light
(3) Key
(1) Tenant
(4) List of valid keys
(3) Lock
(8) Alarm bell
(11) Log of accesses
Software-to-be
(2) Landlord
(10) Tenant accounts
(9) Desktop computer
Difficult to consider the whole system at once… 12

13. Example: Problem Decomposition
REQ1: Keep door locked and auto-lock
REQ2: Lock when “LOCK” pressed
REQ3: Unlock when valid key provided
REQ4: Allow mistakes but prevent dictionary attacks
REQ5: Maintain a history log
REQ6: Adding/removing users at runtime
REQ7: Configuring device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries
REQ1, REQ2, REQ3, REQ4
REQ3
PROBLEM DOMAIN
(5) Device preferences
(6) Photosensor
Subsystem-2
(7) Light
(3) Key
(1) Tenant
Subsystem-1
(4) List of valid keys
(3) Lock
REQ4
Subsystem-3
(8) Alarm bell
(11) Log of accesses
Software-to-be
(2) Landlord
REQ5, REQ7, REQ8, REQ9
(10) Tenant accounts
Subsystem-4
(9) Desktop computer
 Decompose the system based on its requirements 13

14. Problem and Solution Domain
This we need to find
(solution)
This is given
This is a condition to satisfy
(a)
Software-to-be
Problem Domain
Business Goal a b
Domain properties
envisioned by the requirement
(b) b
Software-to-be a
Problem Domain
Business Goal
Specification
Domain properties
sensed by the software-to-be
Requirement
a: specification interface phenomena (system inputs/outputs)
b: requirement interface phenomena (user goals and interaction)
Description of what actually happens in the problem domain versus in what form it will appear as system input; as well as what output will the system issue versus what should happens in the problem domain.
Description of what the user is trying to achieve in the problem domain and how is the user supposed to interact with the system to make it happen. 14

15. Notation Syntax for Problem Frames
C – causal domain
predictable causal relationships among its causal phenomena such as physical laws or business contracts or social norms
B – biddable domain
usually people: unpredictable, incoercible
X – lexical domain
a physical representation of data (i.e., symbolic phenomena)
[C] - causal phenomena
events, states; directly produced or controlled by an entity; can give rise to other phenomena in turn
[E] - events
[Y] – symbolic requirement phenomena
values, and truths and states relating only values; symbolize other phenomena and relationships among them
Causal domain C
Biddable domain B
Lexical domain X
The key point is not so much about the specific symbols, but rather about the concepts and issues that need to be symbolized/represented regardless of the visual language that is used. a
System
Problem
Domain
a: S ! E1
PD ! C2

16. Example: Problem Decomposition
[ Case Study 1: Safe Home Access ]
REQ1: keep door locked and auto-lock
REQ2: lock when “LOCK” pressed
REQ3: unlock when valid key provided
REQ4: allow mistakes but prevent dictionary attacks
REQ5: maintain a history log
REQ6: adding/removing users at runtime
REQ7: configuring device activation preferences
REQ8: inspecting the access history
REQ9: filing inquiries
Required Behavior
Commanded Behavior
Information Display (database is the “display”)
Simple Editing
Simple Editing
Information Display
Simple Editing 16

17. Example: Problem Decomposition
[ Case Study 2: Investment Fantasy League ]
REQ1: view market prices and volumes
Domains: exchange, display
REQ2: place a trade
Domains: investor, tradable-securities, pending-trades
REQ3: execute trades when conditions matched
Domains: exchange, pending-trades
REQ4: generate periodic report
Domains: portfolio, report
REQ5: generate leaderboard
Domains: all-portfolios, leaderboard
REQ6: view leaderboard
Domains: leaderboard, display
REQ7: start a trading group/clique
Domains: investor, group
REQ8: invite to a trading group/clique
Domains: investor, friends, group
Information Display
Simple Editing
Required Behavior
Transformation
Transformation
Information Display
Simple Editing
Commanded Behavior 17

18. Basic Frame 1: Required Behavior
System outputs to the environment
Description of the domain’s required behavior
Control Software
CS!C1
Controlled Domain C3
Required Behavior
CD!C2 C
Environment inputs to the system C
Causal domain X
Lexical domain
Causal phenomena
Events
Symbolic requirement phenomena
[C  ]
[E  ]
[Y  ]
Key:
Example: Execute a Trading order
Control
Software
Controlled
Domain
Required
Behavior
Broker Software
Stock Exchange
Trading order handling rules a b C
a: BS! {Execute[i], Cancel[i]} [C1]
b: SE! {Submit[i], Revoke[i], [C3]
Fulfilled[i], Failed[i], Expired[i]}
SE! {PriceQuotes, Ack[i], Failed[i]} [C2] 18

19. Required Behavior - Frame Concern Checklist
Required Behavior Frame Checklist
Frame requirement: Autonomously control an object (“domain”)
Describe the business goals to be achieved
Description of the controlled domain:
Describe the (relevant) behavioral rules of the domain
Specification of the system-to-be:
What inputs the system will receive and outputs produce
Capabilities of the available “sensors” (inputs):
Sensed parameters: type, sampling rate, precision, …
Capabilities of available “actuators” (outputs):
Actuation parameters: type, acting rate, strength, …
What the three descriptions of a “Required Behavior” Frame should contain
[ Case Study 1: Safe Home Access — REQ1: keep door locked and auto-lock ]
Required behavior frame concern: To describe precisely (1) how the controlled domain currently behaves; (2) the desired behavior for the domain, as stated by the requirement; and, (3) what the machine (software-to-be) will be able to observe about the domain state, by way of the sensors that will be used in the system-to-be.
Business goal for REQ1:
The lock will be armed electronically and periodically checked that it remains so until explicitly disarmed
If the user unlocks, but forgets to lock, the lock will be automatically disarmed after a specified interval
Description of the electromechanical lock (problem domain):
A low or none voltage keeps the latch extended (“armed”);
A high voltage causes mechanical retraction of the latch (“disarmed”) and remains retracted until low voltage.
Capabilities of available “sensors”:
The lock device will report current status when queried via USB protocol, using a command
Capabilities of available “actuators”:
The lock device’s latch will extend or retract, as commanded via USB protocol, using a command 19

20. Requirement: REQ1 - keep door locked and auto-lock
“Unlock” pressed [valid-key] /
after autoLockInterval/
“Lock” pressed /
Unlocked
entry: start autoLock timer
do: countdown
Need “entry” and “do” state activities for countdown timers

21. Problem Domain Properties: How Electronic Lock Works
Computer
Lock
The system-to-be will set one of its output lines to “high voltage”, but only the human user will know the semantic meaning of this action (i.e., “disarm the lock”)
Voltage:
HIGH
LOW
lock armed
lock disarmed
lock armed
This information is not given.
These are deliberate decisions that the developer needs to make, based on understanding of the problem domain. It is not enough to consider how the physical device behaves; we may also need to consider state laws, public safety policies, etc.
What in case of power failure?
- By default armed
- By default disarmed (e.g., fire exit)

22. Required Behavior - Domain Model -
System outputs to the environment
Description of the domain’s required behavior
Control Software
CS!C1
Controlled Domain C3
Required Behavior
CD!C2 C
Environment inputs to the system
Problem Frame checklist helps with identifying the conceptual software objects during Object-Oriented Analysis
Sensor1 Descriptor
- sampling Rate
- precision
- …
Actuator1 Descriptor
- acting Rate
- magnitude
- …
Control Rule
- constraint 1
- constraint 2
- …

23. Basic Frame 2: Commanded Behavior
CS!C1
Controlled domain C
CD!C2 C3
Control software
Command behaviors
Operator B
OP!E4 E4
Example: Submit a Trading order
Controlled domain A C
Command
behavior a b
Control software C D B c c
Operator
a: TS! {Create[i]} [E1]
c: TR! {Submit[i], Cancel[i],
Executed[i], Expired[i]} [Y3]
b: TR! {PriceQuotes, Submit[i]} [Y2] 23

24. Commanded Behavior - Frame Concern Checklist
Commanded Behavior Frame Checklist
Requested user commands:
List of desired user commands and their parameters
Command applicability under different scenarios:
Description of scenarios for which each command is applicable
Consequences of unacceptable commands:
What should happen if the user tries to execute a command that is not supported or not allowed in the current scenario
Document what the user will be able to do and how the system will help them do, or what the user should not do and how the system will prevent these actions
[ Case Study 1: Safe Home Access — REQ2: lock when “LOCK” pressed
REQ3: unlock when valid key provided
REQ4: allow mistakes but prevent dictionary attacks]
Commanded behavior frame concern: To identify (1) all the commands that will be possible in the envisioned system-to-be; (2) the commands that will be supported or allowed under different scenarios; and, (3) what should happen if the user tries to execute a command that is not supported/allowed under the current scenario.
“Sensible commands” are commands that make sense in a given context. This is part of a requirement, not part of domain description because the notion of “sensible” is defined by people rather than being inherent to the domain. The domain will not necessarily “reject” unreasonable commands. [Jackson PF-2001, p.115]
Requested user commands (REQ2, REQ3):
Lock, Unlock(key, door-ID)
Command applicability under different scenarios (REQ2 - REQ4):
Lock has no restrictions (always applicable)
Unlock applicable only if numOfAttemps  maxNumOfAttempts
Consequences of unacceptable commands (REQ4):
When entered key does not correspond to the door-ID, increment numOfAttemps (block if > maxNumOfAttempts)
When not applicable, Unlock will be ignored 24

25. invalid-key [numOfAttemps  maxNumOfAttempts] /
Requirement: REQ3, REQ4, REQ5 - unlock when valid key provided but allow few mistakes
invalid-key [numOfAttemps  maxNumOfAttempts] /
signal-failure
invalid-key /
signal-failure
Accepting
entry: start quit timer
do: countdown
invalid-key
[numOfAttemps  maxNumOfAttempts] /
sound-alarm
Locked
timer-expired /
signal-reset,
set numOfAttemps := 0
“Lock” pressed /
valid-key /
signal-success
Blocked
valid-key /
signal-success
Unlocked
Need “entry” and “do” state activities for countdown timer

26. Safe Home Access
Requirement: Unlock the door for tenant and alarm on dictionary attack
Requirement 1: Unlock the door for tenant
Tenant
TN!Y1
TN!Y3 B
Transform software
Lock Ctrl Software
Open door
Lock Device
LC!Y2
LD!Y4 C
Requirement 2: Alarm on dictionary attack
Burglar
BG!Y1
BG!Y3 B
Transform software
Monitor Software
Alarm on dict. attack
Alarm
MS!Y2
AL!Y4 C

27. Basic Frame 3: Information Display
Real
world C
RW!C1 C3
Information software
Display ~ Real world
Display C
IS!E2 Y4
Example: Place a Trading order
Real world A C
Information
software
Display ~
Real world a c C D B C b d
Display
a: TS! {Create[i]} [E1]
c: TR! {Place[i], Cancel[i],
Executed[i], Expired[i]} [Y3]
b: TR! {PriceQuotes, Place[i]} [Y2] 27

28. Information Visualization - Frame Concern Checklist
Information Display Frame Checklist
Required information to observe:
Capabilities of available “sensors”
Required information to visualize:
Visualization description
Rules for visualization of the observed information:
The transformations needed to process the raw observed information to obtain displayable information
[ Case Study 1: Safe Home Access
— REQ5: maintain a history log
(database is the “display”) ]
Information display frame concern: To identify (1) the information that the machine will be able to observe from the problem domain, by way of the sensors that will be used in the system-to-be; (2) the information that needs to be displayed, as stated by the requirement; and, (3) the transformations needed to process the raw observed information to obtain displayable information.
[ Case Study 1: Safe Home Access — REQ8: inspecting the access history ]
Information to observe for REQ8:
Database records of past accesses
Required information to visualize for REQ8:
Access information will be displayed as stored, without post-processing
Rules for visualization for REQ8:
Render the result of the query as an HTML table 28

29. Basic Frame 4: Simple Editing
ET!E1
Work
pieces X
WP!Y2 Y3
Editing tool
Command effects
User B
US!E3 E3
Example: Place a Trading order
Workpieces
Trading order X
Command
effects a c
Editing tool
Trading software
Order placing rules
Trader B b d
User
a: TS! {Create[i]} [E1]
c: TR! {Place[i], Cancel[i],
Executed[i], Expired[i]} [Y3]
b: TR! {PriceQuotes, Place[i]} [Y2] 29

30. Simple Editing - Frame Concern Checklist
Simple Editing Frame Checklist
Data structures:
Data types of elements (“workpieces”) of the document
Requested commands:
List of all possible user commands and their parameters
Command applicability under different scenarios:
For each command, exactly describe the preconditions for execution
Consequences of unacceptable commands:
What should system do if the user tries to execute a command that is not supported/allowed under the current scenario
[ Case Study 1: Safe Home Access
— REQ9: filing inquiries ]
Simple editing frame concern: To describe precisely (1) the data structures of the workpieces; (2) all the commands that will be possible in the envisioned system-to-be; (3) the commands that will be supported or allowed under different scenarios; and, (4) what should happen if the user tries to execute a command that is not supported/allowed under the current scenario.
[ Case Study 1: Safe Home Access — REQ6: adding/removing users at runtime ]
Data structures for REQ6:
Database tables for each user, containing name, demographics, apartment number, keycode, …
Requested commands for REQ6:
Add new tenant
Modify information of existing tenant
Move tenant to a past-tenants table (no permanent deletion allowed)
Command applicability under different scenarios:
Applicable for a user type Landlord 30

31. Basic Frame 5: Transformation
Inputs X
IN!Y1
IN!Y3
Transform software
Transform Software
I/O Relation
Outputs X
TS!Y2
OU!Y4
Example: REQ4 - generate periodic report
Inputs
Investment Portfolio X
Transform Software a c
I/O Relation
Report Generator
Reporting rules b d
Periodic Report X
Outputs
a: IP! {Shares[i], Price[i], Balance} [Y1]
c: IP! {Stock[i], Balance} [Y3]
d: PR! {Line Data} [Y4]
b: RG! {Report Line, Char} [Y2] 31

32. Transformation - Frame Concern Checklist
Transformation Frame Checklist
Input & output data structures:
Data types of elements of the input document & of output doc
Traversal rules for data structures:
E.g., breadth-first or depth-first
Mapping rules for elements of data structures:
How an input element is mapped/transformed to an output element
Transformation frame concern: To describe precisely (1) the data structures of the input data and output data; (2) how each data structure will be traversed (travelled over); and, (3) how each element of the input data structure will be mapped/transformed to obtain the corresponding element in the output data structure. 32