1. Building System Models for RE
Chapter 15
A Goal-Oriented Model Building Method in Action

2. Building multi-view system models systematically and incrementally
Heuristic rules & patterns for building goal models (Chap.8-9)
Heuristics, derivation rules for building object models (Chap.10)
Heuristics, derivation rules for building agent models (Chap.11)
Heuristics, derivation rules for building operation models (Chap.12)
Heuristics, derivation rules for building behavior models (Chap.13)
Rules for inter-model consistency (Chap.14)
How are these integrated => constructive method for building entire system model ?

3. A goal-oriented method for building multi-view models

4. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
SafeTransportation
NoTrainSameBlock

8. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
SafeTransportation
NoTrainSameBlock
2. Domain analysis:
derive/structure objects On
Train
Block
0:1

10. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
3. S2B analysis:
enriched goals
(alternatives)
SafeTransportation
NoTrainSameBlock
SafeComd
2. Domain analysis:
derive/structure objects On
Train
Block
0:1

12. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
3. S2B analysis:
enriched goals
(alternatives)
SafeTransportation
NoTrainSameBlock
SafeComd
2. Domain analysis:
derive/structure objects On
4. S2B analysis:
enriched objects
from new goals
Train
Block
0:1
Driving
Command

13. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
3. S2B analysis:
enriched goals
(alternatives)
SafeTransportation
NoTrainSameBlock
SafeComd
2. Domain analysis:
derive/structure objects On
4. S2B analysis:
enriched objects
from new goals
SafeAcceler
Train
Block
0:1
Driving
Command
5. Responsibility analysis:
agent OR-assignment

15. Load analysis
for goal elicitation

16. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
3. S2B analysis:
enriched goals
(alternatives)
SafeTransportation
NoTrainSameBlock
SafeComd
2. Domain analysis:
derive/structure objects
1-5. Obstacle & conflict
analysis On
4. S2B analysis:
enriched objects
from new goals
SafeAcceler
Train
Block
0:1
Driving
Command
5. Responsibility analysis:
agent OR-assignment

18. Goal-oriented model building in action
1. Domain analysis:
refine/abstract goals
3. S2B analysis:
enriched goals
(alternatives)
SafeTransportation
NoTrainSameBlock
SafeComd
2. Domain analysis:
derive/structure objects
1-5. Obstacle & conflict
analysis On
4. S2B analysis:
enriched objects
from new goals
SafeAcceler
Train
Block
0:1
Driving
Command
5. Responsibility analysis:
agent OR-assignment
Send
Command
:OBC
6. Operationalization
& behavior analysis
OnBoardController

21. Goal-oriented model building in action
SafeTransportation
NoTrainSameBlock
SafeComd On
SafeAcceler
Train
Block
0:1
Driving
Command
At any time:
abstraction
(e.g. from scenarios)
Send
Command
:OBC
OnBoardController

22. Goal-oriented model building in action: a mine safety control system
System as-is
Miners are exposed to multiple hazards while working inside a mine. These include life-threatening levels of percolating water, carbon monoxide, methane, and airflow.
Currently, dedicated supervisors have to alert miners inside the mine for prompt evacuation when any of those levels is estimated to be dangerous.
Sumps are placed at selected places in the mine for water collection. Each sump is equipped with a pump. The water level in each sump must be regularly checked by dedicated operators to see if the water level is not too high. When this level is too high, the corresponding pump must be turned on to pump the water out of the mine.
To avoid the risk of explosion, pumps may not be operated when the methane level exceeds some critical threshold.
The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern.

23. Goal-oriented model building in action: a mine safety control system
System to-be
To address these problems, a distributed safety control system will be installed. Each sump will be equipped with water level sensors in order to detect when the water is above a high or below a low level, respectively. A software-based controller shall turn a pump on whenever the water in the corresponding sump has reached the high water level, and off whenever the water has reached the low water level.
The mine will also be equipped with sensors at selected places to monitor the carbon monoxide, methane, and airflow levels. An alarm shall be raised, and the operator informed within one second, whenever any of these levels has reached a critical threshold, so that the mine can be evacuated promptly.
Human operators can also control the operation of the pump, like previously, but within limits. An operator can turn the pump on or off if the water is between the low and high water levels. A special operator, the supervisor, can turn the pump on or off without this restriction. In all cases, the methane level must be below its critical level if the pump is to be operated.
The safety control system shall also maintain sensor readings and pump operation records for history tracking and analysis of anomalies.

24. Modelling the system-as-is
Objective: identify & structure goals and concepts common to any system version (business goals, domain concepts)
Step 1: Build preliminary goal model illustrated by scenarios
identify, define, classify (type, category), refine/abstract stable goals
from available material (e.g. interview transcripts)
until reaching questionable refinement options or assignments
using heuristic rules & techniques from Section 8.8
Step 2: Derive preliminary object model
identify, define, classify (entity, association, agent, event), specialize/generalize stable concepts
from goal definitions & domain descriptions
using heuristic rules & techniques from Section 10.7

25. Search for intentional or prescriptive keywords in available material (system-as-is)
Miners are exposed to multiple hazards while working inside a mine. These include life-threatening levels of percolating water, carbon monoxide, methane, and airflow.
Currently, dedicated supervisors have to alert miners inside the mine for prompt evacuation when any of those levels is estimated to be dangerous.
Sumps are placed at selected places in the mine for water collection. Each sump is equipped with a pump. The water level in each sump must be regularly checked by dedicated operators in order to see if the water level is not too high. When this level is too high, the corresponding pump must be turned on to pump the water out of the mine.
To avoid the risk of explosion, pumps may not be operated when the methane level exceeds some critical threshold.
The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern.

26. Search for intentional or prescriptive keywords in available material (system-as-is)

27. Search for intentional or prescriptive keywords in available material (system-as-is)

28. Use scenarios for understanding, illustration, goal elicitation (system-as-is)
WHY?
=>
Maintain [PumpOn If HighWater]
WHY?
=>
Maintain [PumpOff If HighMethane],
Avoid [Explosion]

29. Refine & abstract stable goals: WHY, HOW questions (system-as-is)
Avoid [MinersInFloodedMine]
3. WHY ?
4. HOW ?
Maintain [SumpPumpedOut
If HighWater]
Sumps
WellDistributed
1. WHY ?
2. HOW ?
WaterPumped
Out If PumpOn
Sufficient
PumpCapacity
PumpOn If HighWater
Common sequence of questions:
WHY? directly followed by HOW? on elicited parent goal
F to elicit missing subgoals, dom props, hypotheses

30. milestone-driven refinement
Refine & abstract stable goals: using refinement patterns (system-as-is)
PumpOn If HighWater
HOW ?
milestone-driven refinement
HighWaterDetected
PumpOn If HighWaterDetected
Operator
Operator
refinement stops when questionable options are reached
(cf. problems reported about system-as-is)
=> alternative refinements/assignments in system-to-be

31. Resulting model fragment (system-as-is)
Avoid [MinersInFloodedMine]
HOW ?
Maintain [SumpPumpedOut
If HighWater]
Sumps
WellDistributed
WaterPumped
Out If PumpOn
Sufficient
PumpCapacity
WHY ?
PumpOn If HighWater
milestone-driven refinement
HighWaterDetected
PumpOn If HighWaterDetected
Operator
Operator

32. Using refinement patterns for model restructuring (system-as-is)

33. Step 1: Build preliminary goal model illustrated by scenarios Step 2: Derive preliminary object model (stable concepts in system-as-is)
Def The pump must be on
when the water level in the
sump is above the high water
level
PumpOn If HighWater
Each sump is
equipped with a pump
Sump
WaterLevel: Depth 1 1
Pump
Motor: {on, off}
Regulation
Def Electrical device regulating
the level in a sump by water
evacuation out of the mine
Def Container located at selected bottom places of the mine for water collection

34. Step 2: derive preliminary object model (stable concepts in system-as-is)
PumpOn If HighWater
Each sump is
equipped with a pump
Sump
WaterLevel: Depth 1 1
Pump
Motor: {on, off}
Regulation
Location
WaterEvacuation
Inside
Miner
...
Mine
MethaneLevel
Def Miners inside the mine must be alerted whenever the level of methane is estimated too high
Achieve [MinersAlerted
If HMDetected]

35. Infer behavior model from scenarios for understanding “interesting” conceptual objects
For Pump entity, Motor attribute with range {on, off, down}
StartUp
NotOperating
EndRepair
pumpProblem
Operating
NotPumping
Pumping
pumpOn
pumpOff
Failure
Stop

36. A goal-oriented method for building multi-view models

37. Modelling the system-to-be
Objective: expand preliminary structure of common goals & concepts, assign new responsibilities, derive operationalizations
from reported problems on system-as-is, opportunities
+ any other elicited material about system-to-be
=> alternative goal refinements & agent assignments
Step 3: replay Step 1 for system-to-be
identify, define, classify, refine/abstract new goals
until reaching goals assignable to individual agents (incl. software)
using heuristic rules & techniques from Section 8.8
Step 4: replay Step 2 for system-to-be
identify, define, classify, specialize/generalize new concepts
from goal definitions & domain descriptions
using heuristic rules & techniques from Section 10.7

38. From problems with system-as-is to soft goals on system-to-be
The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern.
Opportunity:
distributed
multi-sensor technology
Reduce [SafetyRiskExposure]
...
Improve [HumanAwarenessOf
DangerousSituations]
Reduce [UnnecessaryEvacuations]
Improve [AccurateAssessmentOf
DangerousSituations]
Reduce [SafetyControlCost]
...

39. Search for intentional/prescriptive keywords in available material (system-to-be)
To address these problems, a distributed safety control system will be installed. Each sump will be equipped with water level sensors in order to detect when the water is above a high or below a low level, respectively. A software-based controller shall turn a pump on whenever the water in the corresponding sump has reached the high water level, and off whenever the water has reached the low water level.
The mine will also be equipped with sensors at selected places to monitor the carbon monoxide, methane, and airflow levels. An alarm shall be raised, and the operator informed within one second, whenever any of these levels has reached a critical threshold, so that the mine can be evacuated promptly.
Human operators can also control the operation of the pump, like previously, but within limits. An operator can turn the pump on or off if the water is between the low and high water levels. A special operator, the supervisor, can turn the pump on or off without this restriction. In all cases, the methane level must be below its critical level if the pump is to be operated.
The safety control system shall also maintain sensor readings and pump operation records for history tracking and analysis of anomalies.

40. milestone-driven refinement
Step3 - Expand preliminary goal structure: using intentional keywords, HOW ELSE questions, refinement patterns
PumpOn If HighWater
HOW 
ELSE ?
milestone-driven refinement
HighWaterDetected
PumpOn If HighWaterDetected
resolve lack of
controllability
highWater
Sensor
PumpSwitchOn
If HighWaterDetected
PumpOn If SwitchOn
Pump
Actuator
Safety
Controller

41. uncontrollability-driven
Step3 - Expand preliminary goal structure: eliciting further goals through WHY, HOW questions
Avoid [PumpFailure]
...
Avoid [ PumpOn When NoWater]
WHY ?
PumpOff If LowWater
HOW ?
milestone-driven
LowWaterDetected
Pump0ff If LowWaterDetected
uncontrollability-driven
PumpSwitchOff
If LowWaterDetected
PumpOff If SwitchOff
lowWater
Sensor
Pump
Actuator
Safety
Controller

42. Step3 - Expand preliminary goal structure:
use scenarios for illustration, understanding,
further elicitation

43. Step4 - Expand object model: replay Step 2 from new goals
+ multiplicities for further elicitation

44. Step 5: Analyze obstacles for more complete goal model (cf. Chap. 9)
...

45. Step 5: Detect and resolve conflicts (cf. Chap. 3, 16, 18)
boundary condition
for conflict
resolution by
goal weakening

46. Step 5: Using scenarios to illustrate resolutions

47. A goal-oriented method for building multi-view models

48. Step 6: Analyze responsibilities and build the agent model
Define agents, their capabilities
monitored/controlled variables
Check goal realizability by assignable agents
capabilities must match monitored/controlled conditions in goal
Build agent diagram, derive context diagram
reponsibilities for leaf goals, agent interfaces
Annotate capability, responsibility links: instance declarations
Using heuristic rules & techniques from Chap. 11
agent refinement, software counterpart of human assignments, avoiding critical dependencies, ...
check consistency rules among goal, object, agent models
=> Alternative responsibility assignments evaluated in Step 7

49. Step 6: agent diagram

50. Step 6: Deriving a context diagram
PumpOn If HighWater
HighWaterDetected
PumpOn If HighWaterDetected
PumpSwitchOn
If HighWaterDetected
PumpOn If SwitchOn
highWater
Sensor
Pump
Actuator
Safety
Controller
highWaterSensor. highWaterSignal
Safety
Controller
Pump.Switch
highWater
Sensor
Pump
Actuator
...
...

51. Step 7: Make choices among alternative options
Options = alternative goal refinements, agent assignments, obstacle resolutions, conflict resolutions
Evaluation needed to select "best" option
Often in parallel with preceding steps
Pros/cons of option = source for soft goal elicitation (cf. Chap. 8)
By use of evaluation techniques ...
informal heuristics: favor options ...
best contributing to leaf soft goals
introducing fewer / less severe risks
introducing fewer / less severe conflicts
resolving more / more severe risks or conflicts
qualitative or quantitative techniques: cf. Chap. 16

52. Step 7: Selecting among options
HighWaterDetected
highWaterSensor
LowWaterDetected
lowWaterSensor
better contributes to
Reduce [SafetyRiskExposure]
Reduce [SafetyControlCost]
than
HighWaterDetected
WaterLevelSensor
LowWaterDetected
Same for
CentralSafetyCtrler
PumpSwitchOn If HighWater AndNot HighMethane
DistibutedSafetyCtrler

53. A goal-oriented method for building multi-view models

54. Step 8: Operationalize leaf goals in the operation model
Identify & specify the services to be provided by system-to-be
to ensure leaf behavioral goals (satisfaction arguments)
software operations, environments tasks
Write precise specs (at least for sofware operations)
Signature, DomPre/Post
ReqPre, ReqTrig, ReqPost (if any), for every underlying goal
Build operationalization diagram, derive use case diagrams
Annotate agent-operation performance links: instance declars
Use heuristic rules & techniques from Chap. 12
identify operations from scenario events, from goal fluents, ...
check consistency rules among goal, object, agent, operation models

55. Operationalizing leaf goals: operationalization diagram fragment for SafetyController agent

56. Specify operations & operationalizations
ReqTrig:
hWs.highWaterSignal = ‘on’ and
not hMs.highMethaneSignal = ‘on’
ReqPre:
not hMs.highMethaneSignal = ‘on’
Input p: pump, hWs: highWaterSensor,
hMs: highMethaneSensor, ...
Output p: pump / Switch
DomPre pump p's switch is off
DomPost pump p's switch is on

57. Derived use case diagram
Pre The pump switch is off and
the high water signal becomes on
and methane level is below critical
Post The pump switch is on
SwitchPumpOn
highWater
Sensor
Pump
Actuator
SwitchPumpOff
ResetMethaneAlarm
lowWater
Sensor
RaiseMethaneAlarm
methaneAlarm
Actuator
...
highMethane
Sensor
SafetyController
See algorithm in Section 12.6

58. Step 9: Build & analyze the behavior model
Model fragment for SafetyController agent, derived from annotated operationalization diagram (cf. Section )
SafetyControllerState
PumpSwitchState
[ highWaterSignal = ‘on’ and
not highMethaneSignal = ‘on’ ]
PumpSw
Off
PumpSw On
[ lowWaterSignal = ‘on’ or
highMethaneSignal = ‘on’ ]
MethaneAlarmSwitchState
[ highMethaneSignal = ‘on’ ]
MethAlarm
SwOff
MethAlarm
SwOn
methaneAlarmReset
[ not highMethaneSignal = ‘on’ ]
WaterAlarmSwitchState
PumpFailure
[ highWaterSignal = ‘on’ ]
WaterAlarm
SwOff
WaterAlarm
SwOn
waterAlarmReset
[ not highWaterSignal = ‘on’ ]

59. Step 9: Build & analyze the behavior model
Similar model fragment for SafetyController agent, generalized from scenario examples (cf. Section )
SafetyControllerState
PumpSwitchState
highWaterSignalOn
[ not highMethaneSignal = ‘on’]
PumpSw
Off
PumpSw On
lowWaterSignalOn
highMethaneSignalOn
MethaneAlarmSwitchState
highMethaneSignalOn
MethAlarm
SwOff
MethAlarm
SwOn
methaneAlarmReset
[ not highMethaneSignal = ‘on’ ]
WaterAlarmSwitchState
PumpFailure
[ highWaterSignal = ‘on’ ]
WaterAlarm
SwOff
WaterAlarm
SwOn
waterAlarmReset
[ not highWaterSignal = ‘on’ ]

60. Generalizing from examples: some input scenarios

61. Building multi-view system models systematically and incrementally
Heuristic rules & patterns for building goal models (Chap.8-9)
Heuristics, derivation rules for building object models (Chap.10)
Heuristics, derivation rules for building agent models (Chap.11)
Heuristics, derivation rules for building operation models (Chap.12)
Heuristics, derivation rules for building behavior models (Chap.13)
Rules for inter-model consistency (Chap.14)
How about model variants for product lines ?

62. Handling model variants for product lines
To capture model commonalities and variations:
keep multiple options in Step 7
Variation point = OR-refinement, OR -assignment,
OR -resolution of obstacle or conflict
Commonality: parent goal in refinement, assignable goal,
obstacle/conflict to be resolved
Variations: alternative refinements, assignments, resolutions
Product configuration = selection of specific option
at each variation point
Process:
define commonalities & variations;
associate variations with specific PL members;
form configurations by taking commonalities + specific variations

63. Elaborating commonalities & variations in PL goal model
To associate variations with specific PL members:
Attach SysRef attribute to nodes after variation point
F identifies PL members to be developed with this option
(cf. Sect. 8.7)
At successor nodes of any variation point ...
SysRef values must be disjoint
SysRef list of variant references must be included in the SysRef list at alternative node preceding the variation point
If needed, use generalization/specialization mechanism for structural commonality/variations in object model
with SysRef attached to specialization link

64. Commonalities & variations in PL goal model for meeting scheduling

65. Commonalities & variations in PL object model for meeting scheduling

66. Forming model configurations
To get goal model for specific PL member M:
top-down, breadth-first traversal of PL goal model
at each variation point, keep ...
upward commonalities,
successor option whose SysRef list includes M
Customized agent, operation, behavior models for M are derived from this customized goal model

67. From multi-view models to project deliverables
model editor
requirements documents generator
model browser
(HTML generator)

68. Model-driven generation of Requirements Document
From selected diagrams and textual annotations
goal refinement trees => section/subsection trees
Def annotations, ...
According to templates fitting the IEEE-830 standard or company-specific standards
Two-step process:
1. Create an internal composite document
(by drag & drop from Concept Explorer)
2. Export the composite document ® RTF, PDF

69. Model-driven Requirements Document generated according to IEEE Computer Society Std 830
1. Introduction
1.1 Document purpose
1.2 System purpose
1.3 Definitions, acronyms & abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 System perspective
2.2 User requirements
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and Dependencies 2.6 Apportioning of requirements
3. System Requirements
high-level goals
generated from the object model
derived from goal model
traversed from top to
bottom
expectations
& unresolved obstacles
requirements priority
derived from agent,
object & operation models