SlideShare a Scribd company logo
1 of 66
Goal Modeling
KAOS
Goal-Directed Requirements
Acquisition (KAOS)
 (Organizational) goals lead to requirements.
 Goals justify and explain requirements which are
not necessarily comprehensible by stakeholders.
 Goals can be used to assign responsibilities to
agents so that prescribed constraints can be met.
 Goals provide basic information for detecting and
resolving conflicts that arise from multiple
viewpoints
The KAOS Modeling Philosophy
• Modeling a social setting involves a variety of concepts,
including Goals, Agents, Concerned Objects, Actions,
Constraints and Responsibilities.
• Goals lead to assignments of responsibilities and designs of
actions and artifacts
• Use a metamodel to support reuse of generic domain
modeling patterns [Dardenne93]
• For example, the library domain is an instance of the
“resource allocation” meta-domain, which also covers
car/room/dwelling rental and is similar to airline/hotel
reservation, class registration etc.
The KAOS Acquisition Process
• Identify Goals, and their Concerned Objects.
• Identify potential Agents and their Capabilities.
• Operationalize Goals into Constraints.
• Refine Objects and Actions.
• Derive strengthened Objects and Actions to Ensure
• Constraints.
• Identify alternative Responsibilities.
• Assign Actions to responsible Agents.
All this could be just as useful to someone doing
organizational design, rather than software development!
Four KAOS models :
• Goal model
• Responsability model
• Operation model
• Object model
Goals are desired system properties that
have been expressed by some stakeholders.
Stakeholder (wikipedia): third party who temporarily holds
money or property; more recent meaning (widely used in
management): person or organization that has a legitimate
interest in a project or entity; the new use of the term arose
together with and due to the spread of
corporate social responsibility ideas…
 interviews of domain experts and current & future
users
 analysis of existing systems
 reading of available technical documents
Goal modelGoal model
7
• Each goal is either a root or is justified by at least
another goal that explain WHY it is needed.
• Each goal except a leave is refined as a collection of
subgoals describing HOW it can be reached.
• Identifying goals proceeds from either top-down,
bottom-up and non-directional approaches: from
intermediate goals are identified higher-level (business
or strategical) goals and lower-level (system
requirements) ones.
Goal modelGoal model
8
Clear distinction between two low-level types of
goals:
• Requirements, to be achieved by a software agent,
• Expectations, to be achieved by an agent which is
part of the system environment.
Conflicts (and more generally obstacles that prevent
goals to be achieved) must be identified as soon as
possible.
Goal modelGoal model
9
Domain properties:
Properties relevant to the application domain, used in
refinements to prove that a refinement is complete. Ex:
in order to satisfy a service request, an infrastructure to
perform the service must be available.
There are two types of domain properties :
- domain hypotheses: domain object properties expected
to hold ; ex: the elevator system has at least one cage to
carry passengers,
- domain invariants: properties known to hold in every
state of some domain object, e.g. a physical law,
regulation or a constraint enforced by some
environmental agent ; eg : for light buttons, we could
state that « the light is either on or off ».
Goal modelGoal model
Infrastructure available
10
Requirements can be gathered by means of open
interviews. A more efficient way is to conduct less
open interviews be reusing requirements patterns.
One of the long-term benefits of investing in KAOS
technology consists in progressively modelling generic
patterns of requirements.
Completeness of the goal model is ensured be
reviewing the different diagrams during validation
sessions with stakeholders.
Goal modelGoal model
11
• Information system: software system to be and the
part of the environment with which it interacts.
• Agent: humain being or automated component that
are responsible for achieving requirements and
expectations.
– We may stop refining goals into subgoals when they are
placed (as requirements) under the responsibility of a single
agent.
• Assignment is used to link expectations to related
agents (several agents may be assigned to an
expectation).
Responsibility modelResponsibility model
12
Graphical Conventions
Goal & Responsibility modelGoal & Responsibility model
Goal
Requirement
Expectation
Agent
goal refinement
goals conflict
responsibility
assignment
Domain property
(pink)
(red)
(yellow)
(yellow)
(blue)
(blue)
13
Completeness criterion 1: a goal model is said to be
complete with respect to the refinement relationship
‘if and only if’ every leaf goal is either an expectation, a
domain property or a requirement.
Completeness criterion 2: a goal model is complete
with respect to the responsability relationship ‘if and
only if’ every requirement is placed under the
responsability of one and only one agent (either
explicitly or implicitly).
Goal modelGoal model
14
Goal modelGoal model
…with this generic goal pattern
(case driven decomposition)…
Beginning the Elevator case study…
15
Goal modelGoal model...applied to the elevator problem:
16
Goal modelGoal modelAnother generic goal pattern
(milestone driven decomposition)
Also appears
in following
schemes
17
Goal modelGoal modelGeneric goal « Safe system »
18
Goal modelGoal modelGeneric goal « Usable system »
19
Goal modelGoal model
Generic goal « Service request satisfied »…
20
Goal modelGoal modelGeneric pattern for the « Elevator called » goal
(milestone driven decomposition)
21
Goal modelGoal model« Elevator called » goal
22
Goal modelGoal model
How to deal with Alternatives:
23
Goal modelGoal model
Qualitative comparaison:
• links to parent goals to which each requirement contributes
• creating a conflit if it contributes negatively
The design having a bidirectional button panel on each floor
seems to be the best compromise.
24
Goal modelGoal model
Based on the bidirectional button panel design, we can
now refine the goal « Button depressed »:
25
Goal modelGoal model
Let’s now refine the goal « Passengers brought to
requested destination », applying the milestone tactics:
26
Goal modelGoal model
To refine the goal « No casualty », we use a generic
pattern that also use a milestone-driven refinement tactic:
Generic goal « No casualty »
The following figure shows how this pattern has been
used, and how the « No intrusion » goal has been
decomposed.
27
Leaf goals are refined later:
•“Emergency stop available”.
•“System protected against fire”.
•“System protected against power failure”
•“No move in overweight conditions”.
28
Goal modelGoal model
29
Goal modelGoal model
30
Goal modelGoal model
31
Goal modelGoal model
32
First shot of what an efficient elevator system should be:
Goal modelGoal model
33
Responsibility modelResponsibility model
« System protected against fire » with responsibilities:
34
After all requirements are assigned to a
responsible agent, a diagram is generated
for each agent.
35
36
Object modelObject model
The Object model is used to define and document the
concepts of the application domain that are relevant
with respect to the known requirements and to provide
static constraints on the operational system that will
satisfy the requirements.
Part of the Object model are objects pertaining to the
stakeholder’s domain and other objects for expressing
requirements or constraints on the operational model.
There are three types of objects: entities, agents,
relationships.
37
 Entities: independant (needn’t refer to other objects)
and passive (can’t perform operations) objects; may
have attributes whose values define a set of states the
entity can transition to
 Agents: independant and active objects; they can
perform operations that usually imply state transitions
on entities (ex: elevator company, passenger, elevator
controler)
 Associations: dependant and passive objects that may
have attributes (ex: "At" that links a cage and a floor)
Object modelObject model
38
Ex: entity « Alarm bell » as a component of the « Elevator »:
Object identification is driven by the goal definition process. Most
goals’s short and long definitions refer to domain objects being
modelled and documented.
All modelled objects shall have their own entries in the glossary
section of the requirements document. During review of the object
model, stakeholders will formally agree on a common vocabulary.
Another way to identify new objects consists in looking at the
requirements and discover the system components they are
necessary for satisfying them.
Object modelObject model
39
Objects may be represented in goal diagrams; the concerns relationship
is used to link a requirement to the objects that are needed for it to be
satisfied. Identifying those objects shall further restrict the space of
solutions that can be proposed by the future system provider. Ex:
Object modelObject model
40
Object « Elevator system »:
Object modelObject model
41
Object « Cage »:
Object modelObject model
42
Object « Floor »:
Object modelObject model
The KAOS model is compliant with UML class diagrams in that
KAOS entities correspond to UML classes; and KAOS associations
correspond to UML binary association links or n-ary association
classes. Inheritance is available to all types of objects (including
associations).
Objects can be qualified with attributes.
43
The Operation model describes all the behaviors that agents
need to fulfill their requirements.
Behaviors are expressed in term of operations performed by
agents.
Ex: press button, enter, exit (perform by passengers) ; open
doors, close doors, move up, move down (perform by elevators).
Those operations work on objects: they can create objects,
trigger object state transitions and activate other operations (by
sending an event).
Operations are justified by the goal they operationalize: an
operation without a goal means there’re missing goals, while a
requirement without operations is just wishful thinking.
Operation modelOperation model
44
Operations identification sources:
• stakeholders, that typically describe processes rather
than goals during interviews; the analyst then asks
specific questions in order to identify the reasons
behing the existing processes and hence unveil the
goals that justify these processes;
• existing requirements: operations explain how they
have to be realized.
Operation modelOperation model
45
Requirements can be operationalized by:
• some object(s)
• some agent behavior(s)
• a combinaison of both
They are respectively requirements that describe
static, dynamic, and both properties on the system:
• the requirement « Elevator equiped with floor doors » will be
operationalized by an object « Floor door »
• requirements that describe dynamic system properties are
operationalized by operations
• the expectation « Stop button used » will be operationalized
with an operation « Push button » and the « Button » entity
Operation modelOperation model
46
In a process, operations are represented as ovals,
concerned objects are connected to the operations by
means of input and output links.
Events are represented as: . Events may be
external or produced by operations (through an output
link). They may start (cause) or stop operations.
An operation model (or process) typically composes
operations performed by one or several agents to
achieve a requirement.
Operation modelOperation model
47
Operation modelOperation model
Process
« Elevator control »
48
Completeness criterion 3 : to be complete, a process
diagram must specify
(i) the agents who perform the operations
(ii) the input and output data for each operation.
Completeness criterion 4 : to be complete, a process
diagram must specify when operations are to be
executed.
Completeness criterion 5 : all operations are to be
justified by the existence of some requirements
(through the use of operationalization links).
Operation modelOperation model
49
Operations can be triggered explicitely by an event. If
no event is specified, the operation will be triggered
implicitly when all the data needed in input are
available (data flow).
Requirements left unoperationalized are called « open
requirements »; solution providers have the complete
freedom to address the requirement as they want. The
less open requirements are left in the model, the more
precise the requirements document will be by
eliminating possible implementations.
Operation modelOperation model
50
Partial classification of the events of the process:
Operation modelOperation model
51
Typical instance of a process pattern KAOS analysts have
to reproduce in all projects:
Operation modelOperation model
(is responsible for)(operationalizes)
A requirement is said to be "closed" when this trian-
gular relationship Responsability-Operationalization-
Performance has been established.
52
Operationalization diagram for the Reschedule operation:
Operation modelOperation model
53
Dealing with obstacles.
Obstacles are situations in which a goal, a requirement
or an expectation is violated. The obstacle is said to
"obstruct" the goal, requirement or expectation.
Dealing with obstacles is very important for safety-
critical systems: it allows analysts to identify and address
circumstances at requirements engineering time
(instead of at programming or running time) in order to
produce for instance robust requirements or new
requirements to avoid or reduce impacts of obstacles.
The result will be a more reliable software.
ObstaclesObstacles
54
Obstacle analysis with KAOS is a goal-oriented activity. It
begins with exploring the goal model and with negating
each goal in turn.
As a goal G is refined into goals G1, …, Gn if and only if
G1, …, Gn all together imply G, we know that if goal G is
violated, it is because at least one of its subgoals is
violated.
Each leaf obstacle is then reviewed with domain experts
to study whether it is worth considering it in the
obstacle analysis. It allows the analyst to prune the
obstacle space and to focus on the most relevant
obstacles.
ObstaclesObstacles
55
Application to:
ObstaclesObstacles
casuality occurs during system use
some system component breaks down
somebody succeeds in hacking into the system.
56
Other application:
ObstaclesObstacles
casuality occurs at service start
casuality occurs during service
casuality occurs at service end.
57
Next, conditions for the obstacle to be raised are looked for. Typical
ways used to identify obstacles start by considering component
failures or people behaving in an unexpected way, maliciously or
because of some people’s capability limitation (disable people,
children, …).
Ex: an obstacle to the goal "Elevator direction updated few seconds
before next stop" occurs when blind people want to use the elevator
system as they can’t read the indications.
Obstacles are linked to the goals they obstruct (obstruction link).
Obstacles are refined the same way as goals, but while goals are
generally ‘AND-refined’, obstacles are most often ‘OR-refined’.
ObstaclesObstacles
58
Obstacle to « Passengers informed of elevator direction »:
ObstaclesObstacles
OR refinement
(Obstruct)
59
Having identified the conditions for it to occur, the
analyst can fix the obstacle in several ways. A first way
consists in defining new requirements that prevent the
obstacle from occuring.
In the preceding example, one can add a new
requirement: "Elevator direction announced by voice
upon floor arrival".
New requirements are linked to the obstacle they
resolve by a resolution link.
Other requirements for blind people could be "Floor
level announced by voice upon floor arrival" and "Call
buttons in Braille".
ObstaclesObstacles
60
Obstacle resolution for « Passengers informed of elevator
direction »:
ObstaclesObstacles
(Resolve)
61
An important source of obstacles concerns system (and
components) reliability and robustness. Reliability and
robustness requirements aim at preventing failures to
occur. One can for instance introduce requirements in
terms of Mean Time Before Failure (MTBF), or in terms
of a maintenance program to replace components
systematically at the right time, and so on.
A second way to fix an obstacle is to restore the
obstructed goal once the obstacle occurs. For instance, if
an elevator failure puts the system out of order, a
restoration requirement can prescribe the maximum
delay within which the system must be repaired.
ObstaclesObstacles
62
• A third way to fix an obstacle consists in minimizing its
effects.
– Suppose the building is equiped with two elevator cages,
one serving floors 1 to 10, the other one floors 10 to 20. If
one cage goes out of order, a requirement should
prescribe that the system shall be self-reconfigured so that
the other cage provides service to all floors (from 1 to 20).
• It’s also possible to fix obstacles by modifying the
KAOS model in different ways, for instance by
substituting an agent with a more "capable" one, by
weakening the obstructed goal so that the obstacle is
no longer relevant or by substituting a goal to another
one.
ObstaclesObstacles
63
Possible refinement of the goal « Robust and reliable elevator
system »:
ObstaclesObstacles
Each branch can be
opted for separately to
satisfy the goal, but
KAOS does not force
exclusion
64
The structure of the requirements document generated
from a KAOS model is borrowed from the IEEE 830-1998
standard for software requirements specification :
Table of contents
1. Introduction
1.1 Document purpose
1.2 System purpose
1.3 Definitions, acronyms, and abbreviations → glossary derived from
1.4 References the KAOS model
1.5 Overview
2. Overall description
2.1 System perspective
2.2 User requirements → a subsection for each goal diagram
2.3 User characteristics and a list of the requirements
2.4 Constraints
2.5 Assumptions and dependencies → assumptions & obstacles not
2.6 Apportioning of requirements dealed with
ConclusionConclusion
65
3. System requirements
3.1 System architecture → decomposition of the system by
KAOS agents (responsability model)
3.2 Object model → diagrams of the KAOS object model
3.3 Operation model → diagrams of the KAOS operation model
A major benefit of KAOS is that it provides a bidirectional traceability
between the problem description and the expected solution description.
As systems require frequent changes, it is vital to keep the requirements
document up to date with respect to the current state of development.
Requirements documents with KAOS tend to be more complete.
Completness must be understood by looking at the five completness
criteria: a complete KAOS model leaves no space for wishful thinking (a
goal not refined), requirements with no responsible, unjustified
operations, and operations for which we ignore who will execute what
and when.
ConclusionConclusion
66
Completeness of the goal model also relies on 3 points :
 the quality of the requirements definition phase
(interviewing stakeholders, if operated properly, leads to
a good goal covering rate)
 the validation meetings during which stakeholders
review consolidated goal diagrams (conflicts are
addressed, forgotten goals have a new chance to come
up)
 refinement techniques that guarantee completness
and consistency (generic refinement patterns that
require formal notations for safety-critical applications).
ConclusionConclusion

More Related Content

What's hot

integration testing.pptx
integration testing.pptxintegration testing.pptx
integration testing.pptxMirzaHammad12
 
software requirement specification
software requirement specificationsoftware requirement specification
software requirement specificationmaliksiddique1
 
MS-Access Tables Forms Queries Reports.ppt
MS-Access Tables Forms Queries Reports.pptMS-Access Tables Forms Queries Reports.ppt
MS-Access Tables Forms Queries Reports.ppt1520lakshyagupta
 
Object Oriented Analysis Design using UML
Object Oriented Analysis Design using UMLObject Oriented Analysis Design using UML
Object Oriented Analysis Design using UMLAjit Nayak
 
Software architectural patterns - A Quick Understanding Guide
Software architectural patterns - A Quick Understanding GuideSoftware architectural patterns - A Quick Understanding Guide
Software architectural patterns - A Quick Understanding GuideMohammed Fazuluddin
 
Database Design
Database DesignDatabase Design
Database Designlearnt
 
2 database system concepts and architecture
2 database system concepts and architecture2 database system concepts and architecture
2 database system concepts and architectureKumar
 
All data models in dbms
All data models in dbmsAll data models in dbms
All data models in dbmsNaresh Kumar
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsSeema Kamble
 
Mapping ER and EER Model
Mapping ER and EER ModelMapping ER and EER Model
Mapping ER and EER ModelMary Brinda
 
Data modeling using the entity relationship model
Data modeling using the entity relationship modelData modeling using the entity relationship model
Data modeling using the entity relationship modelJafar Nesargi
 
Structured Vs, Object Oriented Analysis and Design
Structured Vs, Object Oriented Analysis and DesignStructured Vs, Object Oriented Analysis and Design
Structured Vs, Object Oriented Analysis and DesignMotaz Saad
 
SRS(software requirement specification)
SRS(software requirement specification)SRS(software requirement specification)
SRS(software requirement specification)Akash Kumar Dhameja
 
SE_Lec 05_System Modelling and Context Model
SE_Lec 05_System Modelling and Context ModelSE_Lec 05_System Modelling and Context Model
SE_Lec 05_System Modelling and Context ModelAmr E. Mohamed
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specificationshiprashakya2
 
System analysis and design chapter 2
System analysis and design chapter 2System analysis and design chapter 2
System analysis and design chapter 2Einrez Pugao
 

What's hot (20)

integration testing.pptx
integration testing.pptxintegration testing.pptx
integration testing.pptx
 
software requirement specification
software requirement specificationsoftware requirement specification
software requirement specification
 
MS-Access Tables Forms Queries Reports.ppt
MS-Access Tables Forms Queries Reports.pptMS-Access Tables Forms Queries Reports.ppt
MS-Access Tables Forms Queries Reports.ppt
 
Object Oriented Analysis Design using UML
Object Oriented Analysis Design using UMLObject Oriented Analysis Design using UML
Object Oriented Analysis Design using UML
 
Software architectural patterns - A Quick Understanding Guide
Software architectural patterns - A Quick Understanding GuideSoftware architectural patterns - A Quick Understanding Guide
Software architectural patterns - A Quick Understanding Guide
 
Database Design
Database DesignDatabase Design
Database Design
 
2 database system concepts and architecture
2 database system concepts and architecture2 database system concepts and architecture
2 database system concepts and architecture
 
All data models in dbms
All data models in dbmsAll data models in dbms
All data models in dbms
 
OOP Basics
OOP BasicsOOP Basics
OOP Basics
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metrics
 
System Modelling
System ModellingSystem Modelling
System Modelling
 
Mapping ER and EER Model
Mapping ER and EER ModelMapping ER and EER Model
Mapping ER and EER Model
 
Data modeling using the entity relationship model
Data modeling using the entity relationship modelData modeling using the entity relationship model
Data modeling using the entity relationship model
 
Create table
Create tableCreate table
Create table
 
Structured Vs, Object Oriented Analysis and Design
Structured Vs, Object Oriented Analysis and DesignStructured Vs, Object Oriented Analysis and Design
Structured Vs, Object Oriented Analysis and Design
 
SRS(software requirement specification)
SRS(software requirement specification)SRS(software requirement specification)
SRS(software requirement specification)
 
Dbms
DbmsDbms
Dbms
 
SE_Lec 05_System Modelling and Context Model
SE_Lec 05_System Modelling and Context ModelSE_Lec 05_System Modelling and Context Model
SE_Lec 05_System Modelling and Context Model
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specification
 
System analysis and design chapter 2
System analysis and design chapter 2System analysis and design chapter 2
System analysis and design chapter 2
 

Similar to KAOS

05 fse requirementsengineering
05 fse requirementsengineering05 fse requirementsengineering
05 fse requirementsengineeringMohesh Chandran
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)Manoj Reddy
 
Scenario based methods
Scenario based methodsScenario based methods
Scenario based methodsJoshuaU1
 
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdf
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdfunit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdf
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdfRojaPogul1
 
OOSAD Chapter 6 Object Oriented Design.pptx
OOSAD Chapter 6 Object Oriented Design.pptxOOSAD Chapter 6 Object Oriented Design.pptx
OOSAD Chapter 6 Object Oriented Design.pptxBereketMuniye
 
RE of Scalable Systems
RE of Scalable SystemsRE of Scalable Systems
RE of Scalable SystemsAsjad K.
 
Requirements modeling
Requirements modelingRequirements modeling
Requirements modelingAnanthiP8
 
Model-Based Systems Requirements
Model-Based Systems RequirementsModel-Based Systems Requirements
Model-Based Systems RequirementsJean-Michel Bruel
 
OOAD unit1 introduction to object orientation
 OOAD unit1 introduction to object orientation OOAD unit1 introduction to object orientation
OOAD unit1 introduction to object orientationDr Chetan Shelke
 
Mc0084 software project management & quality
Mc0084 software project management & qualityMc0084 software project management & quality
Mc0084 software project management & qualitysmumbahelp
 
Pattern oriented architecture for web based architecture
Pattern oriented architecture for web based architecturePattern oriented architecture for web based architecture
Pattern oriented architecture for web based architectureshuchi tripathi
 
Applying UML and Patterns (CH1, 6, 9, 10)
Applying UML and Patterns (CH1, 6, 9, 10)Applying UML and Patterns (CH1, 6, 9, 10)
Applying UML and Patterns (CH1, 6, 9, 10)Jamie (Taka) Wang
 
12266422.ppt
12266422.ppt12266422.ppt
12266422.pptCSEC5
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxKarthigaiSelviS3
 
System Modelling.ppt
System Modelling.pptSystem Modelling.ppt
System Modelling.pptAnishNarayan4
 
Ch7-Software Engineering 9
Ch7-Software Engineering 9Ch7-Software Engineering 9
Ch7-Software Engineering 9Ian Sommerville
 

Similar to KAOS (20)

05 fse requirementsengineering
05 fse requirementsengineering05 fse requirementsengineering
05 fse requirementsengineering
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)
 
Scenario based methods
Scenario based methodsScenario based methods
Scenario based methods
 
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdf
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdfunit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdf
unit-1modellingconceptsclassmodeling-140929182538-phpapp01.pdf
 
OOSAD Chapter 6 Object Oriented Design.pptx
OOSAD Chapter 6 Object Oriented Design.pptxOOSAD Chapter 6 Object Oriented Design.pptx
OOSAD Chapter 6 Object Oriented Design.pptx
 
RE of Scalable Systems
RE of Scalable SystemsRE of Scalable Systems
RE of Scalable Systems
 
Requirements modeling
Requirements modelingRequirements modeling
Requirements modeling
 
Ch09
Ch09Ch09
Ch09
 
Ch09
Ch09Ch09
Ch09
 
Model-Based Systems Requirements
Model-Based Systems RequirementsModel-Based Systems Requirements
Model-Based Systems Requirements
 
OOAD unit1 introduction to object orientation
 OOAD unit1 introduction to object orientation OOAD unit1 introduction to object orientation
OOAD unit1 introduction to object orientation
 
Mc0084 software project management & quality
Mc0084 software project management & qualityMc0084 software project management & quality
Mc0084 software project management & quality
 
Pattern oriented architecture for web based architecture
Pattern oriented architecture for web based architecturePattern oriented architecture for web based architecture
Pattern oriented architecture for web based architecture
 
Ch7
Ch7Ch7
Ch7
 
Software Design principales
Software Design principalesSoftware Design principales
Software Design principales
 
Applying UML and Patterns (CH1, 6, 9, 10)
Applying UML and Patterns (CH1, 6, 9, 10)Applying UML and Patterns (CH1, 6, 9, 10)
Applying UML and Patterns (CH1, 6, 9, 10)
 
12266422.ppt
12266422.ppt12266422.ppt
12266422.ppt
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptx
 
System Modelling.ppt
System Modelling.pptSystem Modelling.ppt
System Modelling.ppt
 
Ch7-Software Engineering 9
Ch7-Software Engineering 9Ch7-Software Engineering 9
Ch7-Software Engineering 9
 

More from Syed Zaid Irshad

More from Syed Zaid Irshad (20)

Operating System.pdf
Operating System.pdfOperating System.pdf
Operating System.pdf
 
DBMS_Lab_Manual_&_Solution
DBMS_Lab_Manual_&_SolutionDBMS_Lab_Manual_&_Solution
DBMS_Lab_Manual_&_Solution
 
Data Structure and Algorithms.pptx
Data Structure and Algorithms.pptxData Structure and Algorithms.pptx
Data Structure and Algorithms.pptx
 
Design and Analysis of Algorithms.pptx
Design and Analysis of Algorithms.pptxDesign and Analysis of Algorithms.pptx
Design and Analysis of Algorithms.pptx
 
Professional Issues in Computing
Professional Issues in ComputingProfessional Issues in Computing
Professional Issues in Computing
 
Reduce course notes class xi
Reduce course notes class xiReduce course notes class xi
Reduce course notes class xi
 
Reduce course notes class xii
Reduce course notes class xiiReduce course notes class xii
Reduce course notes class xii
 
Introduction to Database
Introduction to DatabaseIntroduction to Database
Introduction to Database
 
C Language
C LanguageC Language
C Language
 
Flowchart
FlowchartFlowchart
Flowchart
 
Algorithm Pseudo
Algorithm PseudoAlgorithm Pseudo
Algorithm Pseudo
 
Computer Programming
Computer ProgrammingComputer Programming
Computer Programming
 
ICS 2nd Year Book Introduction
ICS 2nd Year Book IntroductionICS 2nd Year Book Introduction
ICS 2nd Year Book Introduction
 
Security, Copyright and the Law
Security, Copyright and the LawSecurity, Copyright and the Law
Security, Copyright and the Law
 
Computer Architecture
Computer ArchitectureComputer Architecture
Computer Architecture
 
Data Communication
Data CommunicationData Communication
Data Communication
 
Information Networks
Information NetworksInformation Networks
Information Networks
 
Basic Concept of Information Technology
Basic Concept of Information TechnologyBasic Concept of Information Technology
Basic Concept of Information Technology
 
Introduction to ICS 1st Year Book
Introduction to ICS 1st Year BookIntroduction to ICS 1st Year Book
Introduction to ICS 1st Year Book
 
Using the set operators
Using the set operatorsUsing the set operators
Using the set operators
 

Recently uploaded

Past, Present and Future of Generative AI
Past, Present and Future of Generative AIPast, Present and Future of Generative AI
Past, Present and Future of Generative AIabhishek36461
 
Risk Assessment For Installation of Drainage Pipes.pdf
Risk Assessment For Installation of Drainage Pipes.pdfRisk Assessment For Installation of Drainage Pipes.pdf
Risk Assessment For Installation of Drainage Pipes.pdfROCENODodongVILLACER
 
Solving The Right Triangles PowerPoint 2.ppt
Solving The Right Triangles PowerPoint 2.pptSolving The Right Triangles PowerPoint 2.ppt
Solving The Right Triangles PowerPoint 2.pptJasonTagapanGulla
 
Arduino_CSE ece ppt for working and principal of arduino.ppt
Arduino_CSE ece ppt for working and principal of arduino.pptArduino_CSE ece ppt for working and principal of arduino.ppt
Arduino_CSE ece ppt for working and principal of arduino.pptSAURABHKUMAR892774
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleAlluxio, Inc.
 
home automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadhome automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadaditya806802
 
National Level Hackathon Participation Certificate.pdf
National Level Hackathon Participation Certificate.pdfNational Level Hackathon Participation Certificate.pdf
National Level Hackathon Participation Certificate.pdfRajuKanojiya4
 
Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating SystemRashmi Bhat
 
Call Girls Narol 7397865700 Independent Call Girls
Call Girls Narol 7397865700 Independent Call GirlsCall Girls Narol 7397865700 Independent Call Girls
Call Girls Narol 7397865700 Independent Call Girlsssuser7cb4ff
 
IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024Mark Billinghurst
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvLewisJB
 
Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxRomil Mishra
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm Systemirfanmechengr
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating SystemRashmi Bhat
 
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsync
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsyncWhy does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsync
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsyncssuser2ae721
 
Sachpazis Costas: Geotechnical Engineering: A student's Perspective Introduction
Sachpazis Costas: Geotechnical Engineering: A student's Perspective IntroductionSachpazis Costas: Geotechnical Engineering: A student's Perspective Introduction
Sachpazis Costas: Geotechnical Engineering: A student's Perspective IntroductionDr.Costas Sachpazis
 
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...Amil Baba Dawood bangali
 
Indian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptIndian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptMadan Karki
 

Recently uploaded (20)

Past, Present and Future of Generative AI
Past, Present and Future of Generative AIPast, Present and Future of Generative AI
Past, Present and Future of Generative AI
 
Risk Assessment For Installation of Drainage Pipes.pdf
Risk Assessment For Installation of Drainage Pipes.pdfRisk Assessment For Installation of Drainage Pipes.pdf
Risk Assessment For Installation of Drainage Pipes.pdf
 
Solving The Right Triangles PowerPoint 2.ppt
Solving The Right Triangles PowerPoint 2.pptSolving The Right Triangles PowerPoint 2.ppt
Solving The Right Triangles PowerPoint 2.ppt
 
POWER SYSTEMS-1 Complete notes examples
POWER SYSTEMS-1 Complete notes  examplesPOWER SYSTEMS-1 Complete notes  examples
POWER SYSTEMS-1 Complete notes examples
 
Arduino_CSE ece ppt for working and principal of arduino.ppt
Arduino_CSE ece ppt for working and principal of arduino.pptArduino_CSE ece ppt for working and principal of arduino.ppt
Arduino_CSE ece ppt for working and principal of arduino.ppt
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at Scale
 
home automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadhome automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasad
 
National Level Hackathon Participation Certificate.pdf
National Level Hackathon Participation Certificate.pdfNational Level Hackathon Participation Certificate.pdf
National Level Hackathon Participation Certificate.pdf
 
Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating System
 
Call Girls Narol 7397865700 Independent Call Girls
Call Girls Narol 7397865700 Independent Call GirlsCall Girls Narol 7397865700 Independent Call Girls
Call Girls Narol 7397865700 Independent Call Girls
 
IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvv
 
Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptx
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm System
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating System
 
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsync
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsyncWhy does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsync
Why does (not) Kafka need fsync: Eliminating tail latency spikes caused by fsync
 
Sachpazis Costas: Geotechnical Engineering: A student's Perspective Introduction
Sachpazis Costas: Geotechnical Engineering: A student's Perspective IntroductionSachpazis Costas: Geotechnical Engineering: A student's Perspective Introduction
Sachpazis Costas: Geotechnical Engineering: A student's Perspective Introduction
 
young call girls in Green Park🔝 9953056974 🔝 escort Service
young call girls in Green Park🔝 9953056974 🔝 escort Serviceyoung call girls in Green Park🔝 9953056974 🔝 escort Service
young call girls in Green Park🔝 9953056974 🔝 escort Service
 
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...
NO1 Certified Black Magic Specialist Expert Amil baba in Uae Dubai Abu Dhabi ...
 
Indian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptIndian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.ppt
 

KAOS

  • 2. Goal-Directed Requirements Acquisition (KAOS)  (Organizational) goals lead to requirements.  Goals justify and explain requirements which are not necessarily comprehensible by stakeholders.  Goals can be used to assign responsibilities to agents so that prescribed constraints can be met.  Goals provide basic information for detecting and resolving conflicts that arise from multiple viewpoints
  • 3. The KAOS Modeling Philosophy • Modeling a social setting involves a variety of concepts, including Goals, Agents, Concerned Objects, Actions, Constraints and Responsibilities. • Goals lead to assignments of responsibilities and designs of actions and artifacts • Use a metamodel to support reuse of generic domain modeling patterns [Dardenne93] • For example, the library domain is an instance of the “resource allocation” meta-domain, which also covers car/room/dwelling rental and is similar to airline/hotel reservation, class registration etc.
  • 4. The KAOS Acquisition Process • Identify Goals, and their Concerned Objects. • Identify potential Agents and their Capabilities. • Operationalize Goals into Constraints. • Refine Objects and Actions. • Derive strengthened Objects and Actions to Ensure • Constraints. • Identify alternative Responsibilities. • Assign Actions to responsible Agents. All this could be just as useful to someone doing organizational design, rather than software development!
  • 5. Four KAOS models : • Goal model • Responsability model • Operation model • Object model
  • 6. Goals are desired system properties that have been expressed by some stakeholders. Stakeholder (wikipedia): third party who temporarily holds money or property; more recent meaning (widely used in management): person or organization that has a legitimate interest in a project or entity; the new use of the term arose together with and due to the spread of corporate social responsibility ideas…  interviews of domain experts and current & future users  analysis of existing systems  reading of available technical documents Goal modelGoal model
  • 7. 7 • Each goal is either a root or is justified by at least another goal that explain WHY it is needed. • Each goal except a leave is refined as a collection of subgoals describing HOW it can be reached. • Identifying goals proceeds from either top-down, bottom-up and non-directional approaches: from intermediate goals are identified higher-level (business or strategical) goals and lower-level (system requirements) ones. Goal modelGoal model
  • 8. 8 Clear distinction between two low-level types of goals: • Requirements, to be achieved by a software agent, • Expectations, to be achieved by an agent which is part of the system environment. Conflicts (and more generally obstacles that prevent goals to be achieved) must be identified as soon as possible. Goal modelGoal model
  • 9. 9 Domain properties: Properties relevant to the application domain, used in refinements to prove that a refinement is complete. Ex: in order to satisfy a service request, an infrastructure to perform the service must be available. There are two types of domain properties : - domain hypotheses: domain object properties expected to hold ; ex: the elevator system has at least one cage to carry passengers, - domain invariants: properties known to hold in every state of some domain object, e.g. a physical law, regulation or a constraint enforced by some environmental agent ; eg : for light buttons, we could state that « the light is either on or off ». Goal modelGoal model Infrastructure available
  • 10. 10 Requirements can be gathered by means of open interviews. A more efficient way is to conduct less open interviews be reusing requirements patterns. One of the long-term benefits of investing in KAOS technology consists in progressively modelling generic patterns of requirements. Completeness of the goal model is ensured be reviewing the different diagrams during validation sessions with stakeholders. Goal modelGoal model
  • 11. 11 • Information system: software system to be and the part of the environment with which it interacts. • Agent: humain being or automated component that are responsible for achieving requirements and expectations. – We may stop refining goals into subgoals when they are placed (as requirements) under the responsibility of a single agent. • Assignment is used to link expectations to related agents (several agents may be assigned to an expectation). Responsibility modelResponsibility model
  • 12. 12 Graphical Conventions Goal & Responsibility modelGoal & Responsibility model Goal Requirement Expectation Agent goal refinement goals conflict responsibility assignment Domain property (pink) (red) (yellow) (yellow) (blue) (blue)
  • 13. 13 Completeness criterion 1: a goal model is said to be complete with respect to the refinement relationship ‘if and only if’ every leaf goal is either an expectation, a domain property or a requirement. Completeness criterion 2: a goal model is complete with respect to the responsability relationship ‘if and only if’ every requirement is placed under the responsability of one and only one agent (either explicitly or implicitly). Goal modelGoal model
  • 14. 14 Goal modelGoal model …with this generic goal pattern (case driven decomposition)… Beginning the Elevator case study…
  • 15. 15 Goal modelGoal model...applied to the elevator problem:
  • 16. 16 Goal modelGoal modelAnother generic goal pattern (milestone driven decomposition) Also appears in following schemes
  • 17. 17 Goal modelGoal modelGeneric goal « Safe system »
  • 18. 18 Goal modelGoal modelGeneric goal « Usable system »
  • 19. 19 Goal modelGoal model Generic goal « Service request satisfied »…
  • 20. 20 Goal modelGoal modelGeneric pattern for the « Elevator called » goal (milestone driven decomposition)
  • 21. 21 Goal modelGoal model« Elevator called » goal
  • 22. 22 Goal modelGoal model How to deal with Alternatives:
  • 23. 23 Goal modelGoal model Qualitative comparaison: • links to parent goals to which each requirement contributes • creating a conflit if it contributes negatively The design having a bidirectional button panel on each floor seems to be the best compromise.
  • 24. 24 Goal modelGoal model Based on the bidirectional button panel design, we can now refine the goal « Button depressed »:
  • 25. 25 Goal modelGoal model Let’s now refine the goal « Passengers brought to requested destination », applying the milestone tactics:
  • 26. 26 Goal modelGoal model To refine the goal « No casualty », we use a generic pattern that also use a milestone-driven refinement tactic: Generic goal « No casualty » The following figure shows how this pattern has been used, and how the « No intrusion » goal has been decomposed.
  • 27. 27 Leaf goals are refined later: •“Emergency stop available”. •“System protected against fire”. •“System protected against power failure” •“No move in overweight conditions”.
  • 32. 32 First shot of what an efficient elevator system should be: Goal modelGoal model
  • 33. 33 Responsibility modelResponsibility model « System protected against fire » with responsibilities:
  • 34. 34 After all requirements are assigned to a responsible agent, a diagram is generated for each agent.
  • 35. 35
  • 36. 36 Object modelObject model The Object model is used to define and document the concepts of the application domain that are relevant with respect to the known requirements and to provide static constraints on the operational system that will satisfy the requirements. Part of the Object model are objects pertaining to the stakeholder’s domain and other objects for expressing requirements or constraints on the operational model. There are three types of objects: entities, agents, relationships.
  • 37. 37  Entities: independant (needn’t refer to other objects) and passive (can’t perform operations) objects; may have attributes whose values define a set of states the entity can transition to  Agents: independant and active objects; they can perform operations that usually imply state transitions on entities (ex: elevator company, passenger, elevator controler)  Associations: dependant and passive objects that may have attributes (ex: "At" that links a cage and a floor) Object modelObject model
  • 38. 38 Ex: entity « Alarm bell » as a component of the « Elevator »: Object identification is driven by the goal definition process. Most goals’s short and long definitions refer to domain objects being modelled and documented. All modelled objects shall have their own entries in the glossary section of the requirements document. During review of the object model, stakeholders will formally agree on a common vocabulary. Another way to identify new objects consists in looking at the requirements and discover the system components they are necessary for satisfying them. Object modelObject model
  • 39. 39 Objects may be represented in goal diagrams; the concerns relationship is used to link a requirement to the objects that are needed for it to be satisfied. Identifying those objects shall further restrict the space of solutions that can be proposed by the future system provider. Ex: Object modelObject model
  • 40. 40 Object « Elevator system »: Object modelObject model
  • 41. 41 Object « Cage »: Object modelObject model
  • 42. 42 Object « Floor »: Object modelObject model The KAOS model is compliant with UML class diagrams in that KAOS entities correspond to UML classes; and KAOS associations correspond to UML binary association links or n-ary association classes. Inheritance is available to all types of objects (including associations). Objects can be qualified with attributes.
  • 43. 43 The Operation model describes all the behaviors that agents need to fulfill their requirements. Behaviors are expressed in term of operations performed by agents. Ex: press button, enter, exit (perform by passengers) ; open doors, close doors, move up, move down (perform by elevators). Those operations work on objects: they can create objects, trigger object state transitions and activate other operations (by sending an event). Operations are justified by the goal they operationalize: an operation without a goal means there’re missing goals, while a requirement without operations is just wishful thinking. Operation modelOperation model
  • 44. 44 Operations identification sources: • stakeholders, that typically describe processes rather than goals during interviews; the analyst then asks specific questions in order to identify the reasons behing the existing processes and hence unveil the goals that justify these processes; • existing requirements: operations explain how they have to be realized. Operation modelOperation model
  • 45. 45 Requirements can be operationalized by: • some object(s) • some agent behavior(s) • a combinaison of both They are respectively requirements that describe static, dynamic, and both properties on the system: • the requirement « Elevator equiped with floor doors » will be operationalized by an object « Floor door » • requirements that describe dynamic system properties are operationalized by operations • the expectation « Stop button used » will be operationalized with an operation « Push button » and the « Button » entity Operation modelOperation model
  • 46. 46 In a process, operations are represented as ovals, concerned objects are connected to the operations by means of input and output links. Events are represented as: . Events may be external or produced by operations (through an output link). They may start (cause) or stop operations. An operation model (or process) typically composes operations performed by one or several agents to achieve a requirement. Operation modelOperation model
  • 48. 48 Completeness criterion 3 : to be complete, a process diagram must specify (i) the agents who perform the operations (ii) the input and output data for each operation. Completeness criterion 4 : to be complete, a process diagram must specify when operations are to be executed. Completeness criterion 5 : all operations are to be justified by the existence of some requirements (through the use of operationalization links). Operation modelOperation model
  • 49. 49 Operations can be triggered explicitely by an event. If no event is specified, the operation will be triggered implicitly when all the data needed in input are available (data flow). Requirements left unoperationalized are called « open requirements »; solution providers have the complete freedom to address the requirement as they want. The less open requirements are left in the model, the more precise the requirements document will be by eliminating possible implementations. Operation modelOperation model
  • 50. 50 Partial classification of the events of the process: Operation modelOperation model
  • 51. 51 Typical instance of a process pattern KAOS analysts have to reproduce in all projects: Operation modelOperation model (is responsible for)(operationalizes) A requirement is said to be "closed" when this trian- gular relationship Responsability-Operationalization- Performance has been established.
  • 52. 52 Operationalization diagram for the Reschedule operation: Operation modelOperation model
  • 53. 53 Dealing with obstacles. Obstacles are situations in which a goal, a requirement or an expectation is violated. The obstacle is said to "obstruct" the goal, requirement or expectation. Dealing with obstacles is very important for safety- critical systems: it allows analysts to identify and address circumstances at requirements engineering time (instead of at programming or running time) in order to produce for instance robust requirements or new requirements to avoid or reduce impacts of obstacles. The result will be a more reliable software. ObstaclesObstacles
  • 54. 54 Obstacle analysis with KAOS is a goal-oriented activity. It begins with exploring the goal model and with negating each goal in turn. As a goal G is refined into goals G1, …, Gn if and only if G1, …, Gn all together imply G, we know that if goal G is violated, it is because at least one of its subgoals is violated. Each leaf obstacle is then reviewed with domain experts to study whether it is worth considering it in the obstacle analysis. It allows the analyst to prune the obstacle space and to focus on the most relevant obstacles. ObstaclesObstacles
  • 55. 55 Application to: ObstaclesObstacles casuality occurs during system use some system component breaks down somebody succeeds in hacking into the system.
  • 56. 56 Other application: ObstaclesObstacles casuality occurs at service start casuality occurs during service casuality occurs at service end.
  • 57. 57 Next, conditions for the obstacle to be raised are looked for. Typical ways used to identify obstacles start by considering component failures or people behaving in an unexpected way, maliciously or because of some people’s capability limitation (disable people, children, …). Ex: an obstacle to the goal "Elevator direction updated few seconds before next stop" occurs when blind people want to use the elevator system as they can’t read the indications. Obstacles are linked to the goals they obstruct (obstruction link). Obstacles are refined the same way as goals, but while goals are generally ‘AND-refined’, obstacles are most often ‘OR-refined’. ObstaclesObstacles
  • 58. 58 Obstacle to « Passengers informed of elevator direction »: ObstaclesObstacles OR refinement (Obstruct)
  • 59. 59 Having identified the conditions for it to occur, the analyst can fix the obstacle in several ways. A first way consists in defining new requirements that prevent the obstacle from occuring. In the preceding example, one can add a new requirement: "Elevator direction announced by voice upon floor arrival". New requirements are linked to the obstacle they resolve by a resolution link. Other requirements for blind people could be "Floor level announced by voice upon floor arrival" and "Call buttons in Braille". ObstaclesObstacles
  • 60. 60 Obstacle resolution for « Passengers informed of elevator direction »: ObstaclesObstacles (Resolve)
  • 61. 61 An important source of obstacles concerns system (and components) reliability and robustness. Reliability and robustness requirements aim at preventing failures to occur. One can for instance introduce requirements in terms of Mean Time Before Failure (MTBF), or in terms of a maintenance program to replace components systematically at the right time, and so on. A second way to fix an obstacle is to restore the obstructed goal once the obstacle occurs. For instance, if an elevator failure puts the system out of order, a restoration requirement can prescribe the maximum delay within which the system must be repaired. ObstaclesObstacles
  • 62. 62 • A third way to fix an obstacle consists in minimizing its effects. – Suppose the building is equiped with two elevator cages, one serving floors 1 to 10, the other one floors 10 to 20. If one cage goes out of order, a requirement should prescribe that the system shall be self-reconfigured so that the other cage provides service to all floors (from 1 to 20). • It’s also possible to fix obstacles by modifying the KAOS model in different ways, for instance by substituting an agent with a more "capable" one, by weakening the obstructed goal so that the obstacle is no longer relevant or by substituting a goal to another one. ObstaclesObstacles
  • 63. 63 Possible refinement of the goal « Robust and reliable elevator system »: ObstaclesObstacles Each branch can be opted for separately to satisfy the goal, but KAOS does not force exclusion
  • 64. 64 The structure of the requirements document generated from a KAOS model is borrowed from the IEEE 830-1998 standard for software requirements specification : Table of contents 1. Introduction 1.1 Document purpose 1.2 System purpose 1.3 Definitions, acronyms, and abbreviations → glossary derived from 1.4 References the KAOS model 1.5 Overview 2. Overall description 2.1 System perspective 2.2 User requirements → a subsection for each goal diagram 2.3 User characteristics and a list of the requirements 2.4 Constraints 2.5 Assumptions and dependencies → assumptions & obstacles not 2.6 Apportioning of requirements dealed with ConclusionConclusion
  • 65. 65 3. System requirements 3.1 System architecture → decomposition of the system by KAOS agents (responsability model) 3.2 Object model → diagrams of the KAOS object model 3.3 Operation model → diagrams of the KAOS operation model A major benefit of KAOS is that it provides a bidirectional traceability between the problem description and the expected solution description. As systems require frequent changes, it is vital to keep the requirements document up to date with respect to the current state of development. Requirements documents with KAOS tend to be more complete. Completness must be understood by looking at the five completness criteria: a complete KAOS model leaves no space for wishful thinking (a goal not refined), requirements with no responsible, unjustified operations, and operations for which we ignore who will execute what and when. ConclusionConclusion
  • 66. 66 Completeness of the goal model also relies on 3 points :  the quality of the requirements definition phase (interviewing stakeholders, if operated properly, leads to a good goal covering rate)  the validation meetings during which stakeholders review consolidated goal diagrams (conflicts are addressed, forgotten goals have a new chance to come up)  refinement techniques that guarantee completness and consistency (generic refinement patterns that require formal notations for safety-critical applications). ConclusionConclusion