KAOS/Objectiver

rese

rved

.

Case Study

t-IT.

All

right

sr Case Study

10 b

y R

espe

ct

JDEV 2013

© 2

0

Case Study: Multi storey car parkCase Study: Multi‐storey car park

You are acting as a requirements engineering consultant to aengineering consultant to a client who wants to automate his existing multi‐storey car park 

rese

rved

. with time‐stamped ticket‐issuing machines, payment machines, l d i it t l i i

t-IT.

All

right

sr closed‐circuit television cameras 

to deter both theft and non‐payment, and automatic

10 b

y R

espe

ct payment, and automatic barriers operated by validated (paid‐up) tickets. 

© 2

0

Case study statement (details)Case study statement (details)

In concrete terms• The automation consists in 

i i t d t tmanaging inputs and outputs; information useful for car park users shall be continuously

rese

rved

.

users shall be continuously displayed

• The automation consists also to guarantee a high level of

t-IT.

All

right

sr The automation consists also to guarantee a high level of 

security. We will focus on two specific points: any stayshall be guaranteed to be fully paid and theft of cars shall

10 b

y R

espe

ct

be prevented as far as possible.

© 2

0

Case study statement (details)Case study statement (details)Regulation prescribes the fulfilment of security constraintsRegulation prescribes the fulfilment of security constraintsofficially identified in several documents. For instance, accordingto a fire security regulation, • the total authorized weight of vehicules admitted in covered

car parks shall not exceed 3,5 tons 

rese

rved

. • In case of fire, all barriers shall beopen (no opening mode is

ib d)

t-IT.

All

right

sr prescribed).

In the following we suppose that the car park to be automated

10 b

y R

espe

ct In the following, we suppose that the car park to be automatedcomplies with the facility structure regulation and that the application to be developed shall be responsible for a part of 

© 2

0

the regulatory security.

First Goal IdentificationFirst Goal IdentificationY i i i i l liYou are acting as requirements engineering consultant to a client who wants to automate his existing multi‐storey car park with time‐stamped ticket‐issuing machines payment machinestime stamped ticket issuing machines, payment machines, closed‐circuit television cameras to deter both theft and non‐payment, and automatic barriers operated by validated (paid‐

rese

rved

. up) tickets. 

• Candidate goals : the problem to solve

t-IT.

All

right

sr g p

• Technical elements: contraints on the solution• Typical: lots of elts related to a solution

10 b

y R

espe

ct • Typical: lots of elts related to a solution• RE objective: get a deeper insight into the PROBLEM

© 2

0

First questionsFirst questions• Deter thefts… of what?

– vehicules?– in vehicules ?in vehicules ?– at payment machines?

i ?

rese

rved

.

– mugging?

• Automated barrier: strange position in the 

t-IT.

All

right

sr

statement • Automate car park: does not tell the why;

10 b

y R

espe

ct • Automate car park: does not tell the why; project enveloppe  discarded for a while

© 2

0

First Goal IdentificationFirst Goal IdentificationIn concrete terms• The automation consists in managing/controlling inputs and outputs; 

information useful for car park users shall also be continuously displayedh i i l hi h l l f i W ill• The automation consists also to guarantee a high level of security. We willfocus on two specific points: any stay shall be guaranteed to be fully paidand theft of cars shall be prevented as far as possible.

rese

rved

. • Candidate goals : – Managing/controlling inputs & outputs: a means to deter thefts & 

t-IT.

All

right

sr non‐payment

– Information displayed for users: which kind of information isrelevant?  user goals?

10 b

y R

espe

ct

g– Stay fully paid. Provides a definition for « validated tickets » (paid‐up 

tickets)Th f f M k h i i i l i

© 2

0 – Theft of cars. Makes the initial statement more precise. 

First Goal identificationFirst Goal identificationl b h f lf l f ff llRegulation prescribes the fulfilment of security constraints officially

identified in several documents. For instance, according to a fire securityregulation, • the total authorized weight of any vehicule admitted in covered car parks

shall not exceed 3,5 tons • In case of fire all barriers shall be open (no opening mode is prescribed)

rese

rved

.

• In case of fire, all barriers shall be open (no opening mode is prescribed).In the following, we suppose that the car park to be automated complies withthe facility structure regulation and that the application to be developed

t-IT.

All

right

sr

shall be responsible for a part of the regulatory security.

• Security constraints = a specific category of mandatory goals; introduces

10 b

y R

espe

ct • Security constraints = a specific category of mandatory goals; introducesconstraints on ways behavioural goals shall be achieved

take them into consideration when the possibly impacted goals are 

© 2

0 studied

First diagramFirst diagram• First Non payment deterred then Thefts• First Non payment deterred, then Thefts deterred

• Non payment deterred : HOW?• New goal: Car exit only after payment of a fee

rese

rved

.

New goal: Car exit only after payment of a fee

t-IT.

All

right

sr

Tactic:Milestone decomposition

10 b

y R

espe

ct Milestone decomposition

© 2

0

Tactic: milestone decompositionTactic: milestone decompositionre

serv

ed.

t-IT.

All

right

sr

N t t dd i l ti t h i

10 b

y R

espe

ct Not yet addressing solution techniquesJust analysing the pb based on what’s known about 

© 2

0 the needs

An alternative…An alternative…

Identifying goals helps the analyst ask questions…q

rese

rved

. Do we need bothor only one of them?

t-IT.

All

right

sr

Subscription, …

10 b

y R

espe

ct©

20

AND vs. OR‐refinement

Both subgoals are neededto satisfy the parent goal

AND-refinement

rese

rved

. t-I

T. A

ll rig

hts

r

OR-refinement

Only one of the subgoals is needed to satisfy the parent goal

NFR often used to motivate a choice

10 b

y R

espe

ct OR-refinementparent goal

© 2

0

Decomposing goals: going on…Decomposing goals: going on……until to identify who does what…

rese

rved

. t-I

T. A

ll rig

hts

r

hypothesis

10 b

y R

espe

ct Unability of the control systemto realise that: other agents are needed…

© 2

0

Tactic : making up for unabilitiesTactic : making up for unabilities

• HOW to compute the stay duration?– System with ticketsy– System with cameras reading plate numbers

G l l i ll t

rese

rved

.

• Goal analysis: allows one to…– envision several solutions and position them 

t-IT.

All

right

sr

correctly– confirm that the expressed needs are real

10 b

y R

espe

ct

p– think about the system

© 2

0

Leaf levelLeaf level• Information on tickets: ID? entry time? blank?• Information on tickets: ID?, entry time? blank?• WHO manages time?  CPC

CPC: Car ParkCPC: Car Park Controller

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

TIM: Ticket Issuing MachineThe right questions

© 2

0 MachineThe right questions at the right time!

Behavioural specificationBehavioural specificationUML sequence or activity diagramsUML sequence or activity diagrams

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

Easy translation Makes behavioursmore/fully deterministic wrt goals

© 2

0 from leaf goal diagrams (no order on AND‐refinement)

Leaf levelre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

Definition of the systemscope!

H th i !

© 2

0

pHypothesis!

Behavioural specificationBehavioural specificationre

serv

ed.

t-IT.

All

right

sr

No ticket taken

10 b

y R

espe

ct barrier maintained closed!

© 2

0

Thefts deterredThefts deterredFirst idea: case decompositionFirst idea: case decomposition

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

Diamond-like structure:N d f th i t di t l ???

© 2

0 Need for the intermediate layer???

Thefts deterred (cont’d)Thefts deterred (cont d)

• Directed goal graph, not a tree

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

© 2

0

Take all viewpoints into accountTake all viewpoints into account

• Viewpoints:– Managerg– OwnerUser

rese

rved

.

– User– Authorities

t-IT.

All

right

sr

• Source for conflicts

10 b

y R

espe

ct©

20

Example of user goalsExample of user goalsre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

Other goals: cheap price, security, user‐friendliness,

© 2

0 Other goals: cheap price, security, user friendliness, information goals, …

ConflictsConflictsre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

• between goals of a same agent• between goals of several agents

© 2

0 • between goals of several agents

Conflict resolutionre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

Obstacle resolution: new requirements!

© 2

0 Obstacle resolution: new requirements!

Nor top‐down, nor bottom‐up…NFR taxonomy:

high potential for reuse

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

Piecing a jigsaw puzzle together instead

© 2

0 Piecing a jigsaw puzzle together instead…

RegulationgHypothesisypCfr statement

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

© 2

0

ObstaclesObstacles

• De‐idealise the model: analyse all what could go wrongg g

• Process:1 N t th i t th t ti

rese

rved

.

1. Negate the requirement or the expectation2. Find the obstacle origin and motivation

t-IT.

All

right

sr

3. Evaluate the obstacle4. Solve the obstacle

10 b

y R

espe

ct 4. Solve the obstacle5. Integrate in the goal graph

© 2

0

Example

Goal-driven risk analysis

rese

rved

. Obstacle pertinence needs validation from domain experts

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

Example (step 5)

resolutions

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

Refinements complemented with obstacle resolution

© 2

0 Refinements complemented with obstacle resolution

The best defense, …• Playing the bad guy• Define the anti goals and refine them into anti• Define the anti‐goals and refine them into anti‐requirementsId tif th l biliti• Identify the vulnerabilities

• Solve the anti‐requirements and the vulnerabilities

rese

rved

.

X : anti-goal

t-IT.

All

right

sr g

10 b

y R

espe

ct©

20

Think negatively…Vulnerability

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

Systematic analysis of delinquent behaviours

© 2

0 Systematic analysis of delinquent behaviours

Adopt counter‐measuresre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

Behavioural SpecificationBehavioural SpecificationSequence diagrams: flat unmotivatedflat, unmotivated

Goals capture the rationales behind the prescribed behaviourprescribed behaviour

rese

rved

. Avoid [cheatingon the entry time]

Important to inform

t-IT.

All

right

sr Important to inform

developers about rationales initially & for releases

10 b

y R

espe

ct©

20

Object ModellingObject Modelling

You are acting as requirements engineering consultant to a client who wants to automate his existing multi‐storey car park with time stamped ticket issuing machines payment machinestime‐stamped ticket‐issuing machines, payment machines, closed‐circuit television cameras to deter both theft and non‐payment, and automatic barriers operated by validated (paid‐

rese

rved

.

p y , p y (pup) tickets. 

• Candidate objects: domain specific concepts

t-IT.

All

right

sr Candidate objects: domain specific concepts

• Object attributes: object qualification

10 b

y R

espe

ct©

20

First object inventoryFirst object inventoryStatement Model

Ticket‐issuing machine Ticket Issuing Machine (TIM)

Ticket Ticket

Payment machine Payment machine

Closed‐circuit televisioncamera

Surveillance system

rese

rved

.

camera

Automatic barrier operated by validated tickets

Exit station, Automatic barrier

t-IT.

All

right

sr

Car park Car Park System

10 b

y R

espe

ct Ticket Attribute

Stamped entry time

Validated (payed up) payed

© 2

0 Validated (payed up) payed

Object definitionre

serv

ed.

t-IT.

All

right

sr

• Agent Stereotype: if direct operational behaviour (not by f i l i hi )

10 b

y R

espe

ct means of an aggregation relationship)• Attribute type: not needed at this stage 

© 2

0 • Fill the model in  operationalise the requirements

Object model (« final »)architecture

rese

rved

. t-I

T. A

ll rig

hts

r10

by

Res

pect

© 2

0

Minimalist approach: Introduce concepts to cover the requirements

Operationalisation Ire

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

• Concerned agents: CPC and TIM

© 2

0 Concerned agents: CPC and TIM

Operationalisation : TIMOperationalisation : TIMre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

Operationalisation: TIMpre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

Operation specification (I)Operation specification (I)

Operation Open entry barrierInput ab: AutomaticBarrierOuput ab: AutomaticBarrierPre ab.state = closed

rese

rved

.

Post ab.state = openPerformedBy TIM

t-IT.

All

right

sr

ReqPre for [No ticket taken => barrier maintained closed]Ticket taken

10 b

y R

espe

ct©

20

Operationalisation: CPCOperationalisation: CPCre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct

N lti i t!

© 2

0 No multi-session yet!

Operation specification (II)Operation specification (II)

Operation Compute feeInput fin: Fee, clk: Clock, t: TicketOuput fout: FeePre t ∈ Ticket_DB ∧ t.ticket_id = fin.ticket_id

rese

rved

.

Postfout.ticket_id = fin.ticket_id 

t-IT.

All

right

sr

fout.dueFee = tarif (t.entryTime, clk.currentTime)PerformedBy CPC

10 b

y R

espe

ct

Operationalizes [Diff (entrance, current) time computed] 

© 2

0

Operationalisation IIOperationalisation IIre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

Multi‐session payment p yre

serv

ed.

t-IT.

All

right

sr

10 b

y R

espe

ct©

20

payed payedFee

Operation specification (III)Operation specification (III)Operation Compute feeOperation Compute fee

Input fin: Fee, clk: Clock, t: TicketOuput fout: FeeOuput fout: FeePre t ∈ Ticket_DB ∧ t.ticket_id = fin.ticket_idPost

rese

rved

.

Postfout.ticket_id = fin.ticket_id fout dueFee =

t-IT.

All

right

sr fout.dueFee = 

tarif (t.entryTime, clk.currentTime) – t.payedFeePerformedBy CPC

10 b

y R

espe

ct PerformedBy CPCOperationalizes [Diff (entrance, current) time computed]O ti li [M lti i t d]

© 2

0 Operationalizes [Multi‐session supported] 

Operation specification (IV)Operation specification (IV)Operation RegisterTicketOperation RegisterTicket

Input tid: Ticket_Id, clk: ClockOuput t: TicketOuput t: TicketPre ¬ (∃ tx ∈ Ticket_DB ∧ tx.ticket_id = tid)Post t ticket id = tid

rese

rved

.

Post t.ticket_id = tid PerformedBy CPCReqPost for [Multi session supported]

t-IT.

All

right

sr ReqPost for [Multi‐session supported] 

t.payedFee = 0

10 b

y R

espe

ct©

20

Operation specification (V)Operation specification (V)Operation RecordPaymentOperation RecordPayment

Input tid: Ticket_Id, t: Ticket, p: PaymentOuput t: TicketOuput t: TicketPre t.ticket_id = tid ∧ t ∈ Ticket_DBPost t payedFee’ = t payedFee + p amount

rese

rved

.

Post t.payedFee  = t.payedFee + p.amount PerformedBy CPCoperationalizes [Multi session supported]

t-IT.

All

right

sr operationalizes [Multi‐session supported] 

10 b

y R

espe

ct©

20

State‐transition of a ticketre

serv

ed.

t-IT.

All

right

sr

NB: incomplete

10 b

y R

espe

ct

No exit allowed if max duration exceeded

p

Deduced from the operation model

© 2

0 educed o t e ope at o ode

Conclusion• Goal model: 

– Identification of essential properties to fulfill– Prescriptive and declarativePrescriptive and declarative

• Operation model:

rese

rved

. – Can be easily translated in UML– Requirements progressively and systematically

t-IT.

All

right

sr

taken into account methodKAOS/Objectiver: a method

10 b

y R

espe

ct KAOS/Objectiver: a methodto build good UML modelsto drive developers (incl outsourcing)

© 2

0 to drive developers (incl. outsourcing)