Model-Based Systems Requirements

Jean-Michel Bruel
João Araújo
RE'2013 1

 Introduction
 System Engineering
 Systems Requirements
 Requirements elicitation process
 KAOS overview
 SysML overview
 Requirements in SysML
 Mapping KAOS models into SysML models
 Practical case study
RE'2013 2

 This tutorial aims at presenting an integrated
approach for systems requirements elicitation
and modeling
 The elicitation phase is based on a goal based
approach  the KAOS Approach
 The modeling phase uses SysML, an OMG
modeling language for systems
 getting more and more popularity (used in Airbus,
Thales, Continental)
 start to be a pivot language for many others (e.g.,
Modelica, Simulink)
RE'2013 3

 Introduction
 KAOS overview
 SysML overview
RE'2013 4

 Not Software Engineering…
 …Before Software Engineering!
◦ In the development process
 Involves specifying, designing, implementing,
validating, deploying and maintaining
systems
 Concerned with the system’s services,
constraints and operation
RE'2013 5

 Set of human and material elements composed of
various technologies
◦ Computer, Hydraulic, Electronic,…
 Integrated to provide services to its environment
corresponding to the system finality
 Interacting between themselves and the environment
RE'2013 6
A complex system is very different from a simple
software system

 A system
◦ Should manage interactions between parts
◦ Support expected behavior
◦ Handle unexpected ones
RE'2013 7

RE'2013 8
8
Requirements
Functional and/or
Behavioural Model
Ground Take Off
Landing Flying
Structural Model
Engine Flying
Command
Brakes Flaps
Performance Model
Data
Acquisition
Equations
Reactions
Other Engineering
Analysis Models
Cost
Model
Security
Model
Business
Model
…
?OK

RE'2013 9
Specifications
Requirement Definition
System Design
Analysis
Test Plans
After
Before
Moving from Document centric
To Model centric
Generate lot of
writing work
Not adapted to
discuss within a
multi-domain team

 User requirements
◦ Statements of the services the system must provide
and its operational constraints.
◦ Target: customers.
 System requirements
◦ A structured document with detailed descriptions of
the system’s services and operational constraints.
◦ Part of a contract between client and contractor.
RE'2013 10

 More detailed specifications of system services
(F) and constraints (NF) than user requirements
◦ Functional: descriptions of system’s services, and how
the system should react in particular situations.
◦ Non-functional: may be more critical than functional
requirements. If these are not met, the system is
useless. E.g. availability, timing constraints, reliability,
security, safety
 They are intended to be a basis for designing the
system
 They may be incorporated into the system
contract
 System requirements may be specified using
models
RE'2013 11

 Complex systems must be concerned with
◦ Changing as the system is being specified.
◦ Must anticipate hardware and communications
evolution
◦ Hard to define non-functional requirements and
analyse their interactions
RE'2013 12

Requirements
specification
Requirements
validation
Requirements
elicitation
System requirements
specification and
modeling
System
requirements
elicitation
User requirements
specification
User
requirements
elicitation
Business requirements
specification
Prototyping
Feasibility
study
Reviews
System requirements
document
RE'2013 13

 Also called requirements elicitation or
requirements discovery.
◦ Involves interaction with stakeholders to discover their
requirements.
◦ Domain requirements are also discovered at this stage.
 Developers should work with customers to learn
about the application domain, the services that the
system should provide and the operational
constraints of the system.
 May involve different stakeholders: end-users,
managers, engineers involved in maintenance,
domain experts, trade unions, etc.
RE'2013 14

 In principle, requirements should state what
the system should do and the design should
describe how it does this.
 In practice, requirements and design are
difficult to separate
◦ A system architecture may be designed to structure
the requirements;
◦ The system may inter-operate with other systems
that generate design requirements;
◦ The use of a specific design may be a domain
requirement.
RE'2013 15

 Goals are desired system properties that have been
expressed by some stakeholders
 Goals can be specified in different levels of
abstraction, covering at a higher level strategic
concerns and at a lower level technical issues
 They can be:
◦ functional – related to the services provided
◦ non-functional – related to quality attributes (e.g. Security,
performance, availability)
 Examples of goals (TV system):
 “The system should provide access to search and choose
channels programs”
 “The system must be available 24h/7days a week”
RE'2013 16

 Non-functional requirements may be very difficult
to state precisely and imprecise requirements may
be difficult to verify.
◦ Close to a goal  or a softgoal!
◦ Goals are helpful to developers as they convey the
intentions of the system users.
 Verifiable non-functional requirement
◦ A statement using some measure that can be objectively
tested.
RE'2013 17

 A system goal
◦ The TV system should be easy to use by ordinary users and
should be organised in such a way that user errors are
minimised.
 A verifiable non-functional requirement
◦ Ordinary users shall be able to use all the system functions
after reading the manual for an hour.
RE'2013 18

 GORE is considered an established paradigm in
RE to handle elicitation, specification, analysis,
negotiation and evolution of requirements by
using goals
 GORE approaches were developed to support the
development of large-scale systems where the
goal model is the central one.
◦ KAOS, i*, GRL, NFR Framework, GQM
 Eliciting requirements for large-scale models is
performed in a stepwise manner.
◦ The higher-level goals are decomposed into less
abstract goals.
RE'2013 19

KAOS is one of the most well-known GORE
approaches.
It is a methodology based on the decomposition and
refinement of goals to support the entire
requirements development and acquisition process.
 These models allow:
◦ Goals development
◦ Objects identification
◦ Operations identification
◦ Goals operationalization
◦ Responsibilities assignment
RE'2013 20

 It is a systematic approach to discover and
structure requirements while:
◦ Avoiding ambiguous or irrelevant requirements
◦ Allowing efficient and easy communication
between stakeholders
◦ Clarifying stakeholders responsibilities
 It also provides mechanisms to:
◦ Choose between different alternatives
◦ Manage conflicts
◦ Refine goals to structure complex requirements
◦ Do domain analysis for reuse purposes
RE'2013 22

25
 Goal model
 Responsibility model
 Object model
 Operation model
RE'2013

26
 Discover system goals through interviews, technical
documents, etc.
 Each goal in the model (except the roots) is justified
by at least another goal explaining why the goal
was introduced in the model
 Each goal in the model (except the leaves, bottom
goals) is refined by a collection of subgoals
describing how the refined goal can be reached
 The identification is both top-down and bottom-up
◦ In summary, refining and abstracting goals (WHY & HOW)
RE'2013

28
 Informal (text in natural language)
 Semi-formal (diagrams)
 Formal (use of temporal logic formulas)
◦ Not addressed in this tutorial
RE'2013

29
 AND Refinements
 OR Refinements
 Conflicts
 Obstruction and resolution links
 Responsibilities links
RE'2013

30
 Agents are humans or automated components that
are responsible for achieving requirements
expectations
 Expectations are requirements on agents
interacting with the system
◦ They are introduced to show how the SW system and its
environment have to cooperate to achieve the goals
◦ It is type of goal to be achieved by an agent part of the
environment of the system
 A requirement is a low level type of goal to be
achieved by a software agent
◦ The software agent is responsible for it
RE'2013

31
 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
 Criterion 2:
◦ A goal model is said to be complete with respect
to the responsibility relationship if and only if
every requirement is placed under the
responsibility of one and only one agent or
implicitly if the requirement refines another one
which has been placed under the responsibility of
some agent
RE'2013

32
 Available patterns can be instantiated and
reused
 KAOS consists of modelling generic patterns
of requirements
◦ They are progressively built
RE'2013

33
Expectation
Domain
properties
RE'2013

45
 When it is not possible to satisfy two goals
simultaneously
◦ Performance goals may conflict with safety goals
◦ Information goals may conflict with security and
privacy goals
 Obstacles prevent goals from being
achieved
◦ Defensive approach
 Dealing with conflicts (or more generally,
with obstacles) allows
◦ to build a more complete requirements document
and
◦ To build a more robust system
RE'2013

46
 When conflicts are detected:
◦Negotiation to conflict resolution
 Select alternatives or
 Re-evaluate the priorities or
 Revise requirements
RE'2013

49
 Lamsweerde, Axel van; “Goal-Oriented
Requirements Engineering: A Guided Tour”;
Université Catholique de Louvain; Louvain-la-
Neuve; Belgium; 2001
 “A KAOS Tutorial”; Objectiver; 2003
 Lamsweerde, Axel van; “Goal-Oriented
Requirements Engineering: From System Objectives
to UML Models to Precise Software Specification”;
Université Catholique de Louvain; Louvain-la-
Neuve; Belgium; May 2003
 Lamsweerde, Axel van; “Requirements Engineering
- - from system goals to UML models to software
specifications”; Wiley, 2009
RE'2013

 Introduction
 KAOS overview
 SysML overview
RE'2013 50

 Date of birth: 2001!
 Current version: 1.3 (June 2012)
 Father: OMG/UML + INCOSE
 Leading authors
◦ Conrad Bock
◦ CrisKobryn
◦ Sanford Friedenthal
RE'2013 52

 Relationship between the two
RE'2013 53

RE'2013 54
 Industry
◦ American Systems, BAE Systems, Boeing, Deere & Company, EADS
Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin,
Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
 Tool vendors
◦ Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics,
PivotPoint Technology, Sparx Systems, vitech, …
 Other organisations
◦ AP-233, INCOSE, Georgia Institute of Technology, AFIS, …

RE'2013 56
Master Technologies de l'Internet - 2ième année 56
Block Definition
Diagram
Internal Block
Diagram
Parametric
Diagram
Requirement
Diagram

RE'2013 57
57Master Technologies de l'Internet - 2ième année 57
Same as UML
Modified from UML
New

 Diagram notation
 Structure diagrams
 Behavioral diagrams
 Cross-cutting constructs
RE'2013 58

 Each SysML diag. represents a model element
 Each SysML diag. must have a Diagram Frame
 Diagram context is indicated in the header:
◦ Diagram kind (req, act, bdd, ibd, sd, etc.)
◦ Model element type (package, block, activity, etc.)
◦ Model element name
◦ User defined diagram name or view name
 A separate diagram description block is used to
indicate if the diagram is complete, or has elements
elided
RE'2013 59

RE'2013 60
header
content
diag. type diag. name

 Package
 Block Definition
 Internal Block
 Parametric
RE'2013 61

 Same as UML
◦ to organize the model
◦ name space
 Model can be organized in multiple ways:
◦ System hierarchy
 e.g., enterprise, system, component
◦ Diagram kind
 e.g., requirements, use cases, behavior
◦ Use viewpoints to augment model organization
RE'2013 62

 Classes are dead… welcome to blocks!
◦ Can be anything (System, Hardware, Software, Data,
Procedure, Facility, Person)
◦ Satisfy Systems Engineers
RE'2013 65

 Compartments
◦ Properties
◦ Operations
◦ Constraints
◦ Allocations
◦ Requirements
◦ User defined!
RE'2013 66

RE'2013 67
Diagramme de Définition de
blocs (BDD)
Décrit les relations entre les
blocks (composition,
généralisations…)
Diagramme Interne de bloc
(IBD)
Décrit la structure interne
d’un bloc sous forme de
parts, ports et connecteurs.

RE'2013 71
◦ Standard
◦ Flow

RE'2013 72
 to preserve encapsulation of
block
 interactions at outer ports
are delegated to ports of
child parts
 ports must match
◦ same kind, type, direction, etc.
 connectors can cross
boundary without requiring
ports at each level of
nested hierarchy

RE'2013 73Master Technologies de l'Internet - 2ième année 73
Flot hydraulique
Flot électrique
Interface logicielle
signal

 To express constraints between value properties
◦ equations
◦ support for engineering analysis (e.g., performance)
◦ identification of critical performance properties
 Constraint block captures equations
◦ Expression language can be formal (e.g., MathML, OCL)
◦ Computational engine is not provided by SysML
 Parametric diagram
◦ usage of the constraints in an analysis context
RE'2013 74

 Activity
 Sequence
 State Machine
 Use Case
RE'2013 77

 to specify
◦ controlled sequence of actions
◦ the flow of inputs/outputs
◦ control, including sequence and conditions for
coordinate activities
 Swimlanes
◦ to show responsibility of the activity
RE'2013 78

 Improvements from UML:
◦ continuous or discrete flow
◦ control operators
 to start/stop other actions
◦ Overwrite and NoBufferports
 for continuous flows
◦ probabilities on transitions or parameters
RE'2013 79

 Allocation
 Requirement Diagrams
RE'2013 84

 General relationship between two elements of
the model
 Different kinds of allocation:
◦ Functionality - component
◦ Logical component – physical component
◦ Software – hardware
◦ …
 Usable in a lot of different diagrams
 Usable under graphical or tabular representation
RE'2013 85

 Use of swimlanes
RE'2013 86

 We will focuss on them soon…
RE'2013 87

RE'2013 90
Black Box Use Case Scenarios
Requirements Diagram
Black Box Use Case Model,
System Level Operational Contracts
White Box Use Case Model
Logical Subsystem Operational Contracts
Deployment Model,
HW/SW allocated Operational Contracts
RequirementsRepository
TestDatabase
White Box Use Case Scenarios
System Use Cases
Links providing
traceability
to original requirements
Physical Subsystem
Use Case Scenarios
ICD
HW/SW Design
System Architectural Design
UseCaseAnalysis
Abstracted
Use Case Models
System Functional Analysis
Requirements Analysis
Definition of System Use Cases
Updated Logical Subsystem OpCons
Requirements Capture
Definition of Phys.SS Use Cases
HW/SW Trade Off
Physical Subsystem Use Cases
System Use Cases
Logical Subsystem OpCons
Use Case Consistency
Analysis
White Box Analysis
System Level
OpCons
Black Box Analysis
Use Case 1
HW/SW Specs
HARMONY- SE (i-Logix)

 Introduction
 KAOS overview
 SysML overview
RE'2013 91

 Requirement diagram
 Other diagrams
◦ To link use cases in a Use Case diagram
◦ To allocate them to block in a Block Def. Diag.
◦ Etc.
 In tables
RE'2013 92

 <<requirement>> allows to represent a text
based requirement
◦ Includes one identifier id and some textual properties
◦ Can add user defined properties
◦ Can add user defined requirement categories
 Requirements can be
◦ decomposed
◦ specialized
 Requirement relationships
◦ « deriveRqt », « refine »
◦ « satisfy », « verify »
◦ « trace », « copy »
RE'2013 93

RE'2013 94
- Stereotype
- Id
- text

 Between requirements
◦ Containment
◦ Refine
◦ Derive
◦ Specialize
◦ Copy
◦ Trace
 Between requirements and others
◦ Satisfy
◦ Verify
◦ Refine
◦ Trace
RE'2013 96

RE'2013 98
satisfiedBy
<<block>> Camera

RE'2013 100
http://ojs.academypublisher.com/index.php/jsw/article/viewFile/03065768/988

 Requirements organized into package structure
RE'2013 101

 Requirements organized using containment
RE'2013 102

 Implies an analysis
RE'2013 103

RE'2013 105
 When you don’t want to be more precise

 Not too much if used only for requirements
 Added value when related to other elements
 Easy import/export
RE'2013 108

 Introduction
 KAOS overview
 SysML overview
RE'2013 109

 Mapping Modeling concepts
◦ Goal  <<requirement>>
◦ Requirement  <<requirement>> (system)
◦ Expectation  <<requirement>> (user)
◦ Resolutions  <<requirement>> (system or user)
◦ Entity  Block
◦ Operation  activity or Block operation
◦ Environment Agents  Actors
◦ System Agents  Blocks/components
RE'2013 110

 Relationships
◦ Decomposition
 Or  multiple <<refine>>
 And  composition
◦ Concerns  <<satisfy>>
 No direct mapping
◦ Obstacles
◦ Conflicts
RE'2013 111

RE'2013 113
Conforms toConforms to
Through Through
Transformed into
Conforms toConforms toConforms to
Conforms toConforms toConforms to
Meta -
metamodel
SysML
Metamodel
ATL
Metamodel
KAOS
Metamodel
ATL Rules
SysML Model KAOS Model
SysML Log
Model
KAOS Log Model

 Introduction
 KAOS overview
 SysML overview
RE'2013 114

 Hybrid Utility Vehicle (HUV)
◦ From http://www.uml-sysml.org/sysml
 Cable TV
RE'2013 115

◦ Requirement  <<requirement>> (system)
◦ Expectation  <<requirement>> (user)
◦ Object  Block
◦ Operation  activity or Block operation
◦ Decomposition
 Or  multiple <<refine>>
 And  composition
◦ Satisfy  <<satisfy>>
RE'2013 133

 KAOS
◦ Goal-oriented modeling language
◦ Special role at Requirements elicitation
 SysML is:
◦ a specific language for complex systems
◦ strongly UML-Based
◦ focusing on analysis
 SysML is not:
◦ a method
◦ just a UML profile
◦ sufficient in itself
 Synergy between KAOS and SysML!
RE'2013 134

 Develop an MDD framework to automatically derive SysML
requirement and block models from KAOS models and
vice-versa.
 How to address the KAOS model elements that do not
have direct correspondence to SysML
◦ E.g. Obstacles and resolutions, conflicts
RE'2013 135

 Any question?
 Anycomments?
RE'2013 136
??

 A. v. Lamsweerde. "GoalOriented Requirements Engineering: A
Guided Tour”, presented at the 5th IEEE International Symposium
on Requirements Engineering, Toronto, Canada, 2001.
 A. v. Lamsweerde. Requirements Engineering: From System Goals
to UML Models to Software Specifications. Hoboken, USA: John
Wiley & Sons, Inc., 2009.
 Jean Michel Bruel and Pascal Roques. "Présentation des concepts
de SysML. Chap. 4 of the book: "Modélisation et analyse de
systèmes embarqués", Hermès Book, To be published in June
2013.
 Manzoor Ahmad, JeanMichel , Christophe
Gnaho. Using RELAX, SysML and KAOS for Ambient Systems
Requirements Modeling. Procedia Computer Science 10 (2012)
474–481.
 Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H. C. Cheng and
JeanMichel Bruel. RELAX: A Language to Address Uncertainty in
SelfAdaptive Systems Requirements.
 I. Sommerville, Software Engineering, Addison-Wesley, 9th
Edition, 2010
RE'2013 138

RE'2013 139
 Books
◦ « A Practical Guide to SysML », A. Moore, R. Steiner, S. Friedenthal, The
MK/OMG Press, MK/OMG Press, 2011 (2ndedition).
◦ « Embedded Systems Analysis and Modelingwith SysML, UML and AADL », F.
Kordon, J. Hugues, A. Canals, A. Dohet, Wiley, 2013.
 Internet
◦ OMG, Object Management Group (http://www.omgsysml.org/)
◦ AFIS, Association Françaised’IngénierieSystème, (http://www.afis.fr/)
◦ INCOSE, International Council on Systems, (http://www.incose.org/)
◦ The SysML spec: http://www.omg.org/spec/SysML/1.3/PDF

RE'2013 140
 Tools
◦ Papyrus (http://www.papyrusuml.org)
◦ TopCased (http://topcased.gforge.enseeiht.fr/)
◦ Artisan Software / Real-time Studio (http://www.artisansw.com/)
◦ Embedded Plus / SysML Toolkit for RSDP (http://www.embeddedplus.com/)
◦ I-Logix / Rhapsody (http://www.ilogix.com/sublevel.aspx?id=53)
◦ SparxSystems / Enterprise Architect (http://www.sparxsystems.com/sysml)
◦ Telelogic / Tau G2 (http://www.telelogic.com/products/tau/index.cfm)
◦ MagicDraw (http://www.nomagic.com/)

Model-Based Systems Requirements

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Model-Based Systems Requirements (20)

Recently uploaded (20)

Model-Based Systems Requirements

Editor's Notes