1. Requirements Modeling
with SysML
Pascal Roques
IEEE SysCon 2013 Tutorial
April 15th, 2013

2. • Senior Consultant & Trainer,
25 years of experience in modeling
 SADT, OMT, UML, SysML
• OMG Certified on UML2 and SysML
• Co-founder of association
• Author of UML best-sellers in France
• … and of the first French
SysML book
pascal.roques@prfc.fr
The Speaker: Pascal Roques
2

3. What is SysML?
3
• SysML™ is a general-purpose graphical
modeling language for specifying,
analyzing, designing, and verifying
complex systems that may include
hardware, software, information,
personnel, procedures, and facilities
• It is a specialized UML profile targeted to
system engineering

4. Why Model?
4
• In all domains, those building complex
systems have been modelling for ages!
• To harness complexity
• To reduce risks
• To communicate!
• Abstraction
• Hide details
• …

5. Reference: INCOSE
5
• www.incose.org

6. (Brief) History of SysML
6

7. SysML Stakeholders
7
• American Systems, BAE SYSTEMS, Boeing, Deere &
Company, EADS Astrium, Eurostep, Israel Aircraft
Industries, Lockheed Martin, Motorola, NIST, Northrop
Grumman, oose.de, Raytheon, THALES
Industry
• ARTiSAN, EmbeddedPlus, Gentleware, IBM, I-Logix,
Mentor Graphics, PivotPoint Technology, SparxSystems,
Telelogic, Vitech
Tool Vendors
• AP-233, INCOSE, Georgia Institute of Technology, etc.
• In France: l’AFIS
Others

8. SysML = UML2 Profile
8
www.omgsysml.org/

9. SysML Diagram Types
9
www.omgsysml.org/

10. The Four « Pillars » of SysML
10 www.omgsysml.org/

11. SysML and Requirements
11
• SysML defines elements for modeling
requirements and their relationships
• including relationships to other artifacts such
as test cases or blocks

12. Requirements in SysML
(1/3)
• A requirement specifies a capability or
condition that must (or should) be
satisfied
• A requirement may specify a function that
a system must perform or a performance
condition a system must achieve
• Use cases are typically effective for
capturing the functional requirements, but
not as well for non-functional
• The incorporation of text-based requirements
into SysML effectively accommodates a broad
range of requirements
12

13. Requirements in SysML
(2/3)
• SysML provides modeling constructs to
represent text-based requirements and
relate them to other modeling elements
• The requirements diagram can depict the
requirements in graphical, tabular, or tree
structure format
• A requirement can also appear on other
diagrams to show its relationship to other
modeling elements
• The requirements modeling constructs are
intended to provide a bridge between
traditional requirements management tools
and the SysML models
13

14. Requirements in SysML
(3/3)
• A standard requirement includes
properties to specify its unique identifier
and text requirement
• Additional properties such as verification status,
can be specified by the user
• Several requirements relationships are
specified that enable the modeler to relate
requirements to other requirements as well
as to other model elements
• These include relationships for defining a
requirements hierarchy, deriving requirements,
satisfying requirements, verifying requirements,
and refining requirements
14

15. Composite Requirement
• A Composite Requirement can contain sub
requirements in terms of a requirements
hierarchy, specified using the namespace
containment mechanism
• A composite requirement may state that the
system shall do A and B and C, which can be
decomposed into the child requirements that
the system shall do A, the system shall do B,
and the system shall do C
15

16. Requirement Reuse
• There is a real need for Requirement
reuse across product families and projects
• Typical scenarios are regulatory, statutory, or
contractual requirements that are applicable
across products and/or projects and
requirements that are reused across product
families
• SysML introduces the concept of a slave
requirement
16

17. Derive Relationship
• The derived requirements generally
correspond to requirements at the next
level of the system hierarchy
17

18. Satisfy Relationship
• The satisfy relationship describes how a
design or implementation model satisfies
one or more requirements
18

19. Verify Relationship
• The verify relationship defines how a test
case or other model element verifies a
requirement
19

20. Refine Relationship
• The refine requirement relationship can be
used to describe how a model element or
set of elements can be used to further
refine a requirement
20

21. Trace Relationship
• A generic trace requirement relationship
provides a general-purpose relationship
between a requirement and any other
model element
• The semantics of trace include no real
constraints and therefore are quite weak
21

22. Warning: Arrow direction!
• Most requirement relationships in SysML
are based on the UML dependency
• The arrow points from the dependent model
element (client) to the independent model
element (supplier)
• In SysML, the arrowhead direction is
opposite of what has typically been used
for requirements flow-down where the
higher-level requirement points to the
lower-level requirement
22

23. Requirement Subclasses
• Modelers can customize requirements
taxonomies by defining additional
subclasses of the Requirement stereotype
• For example, a modeler may want to define
requirements categories to represent
operational, functional, interface, performance,
physical, storage, activation/deactivation,
design constraints, and other specialized
requirements such as reliability and
maintainability, or to represent a high level
stakeholder need
• Some potential Requirement subclasses
are defined in Non-normative Extensions
23

24. HSUV Sample Problem
Requirement Diagrams (1/3)
24

25. HSUV Sample Problem
Requirement Diagrams (2/3)
25

26. HSUV Sample Problem
Requirement Diagrams (3/3)
26

27. Requirements Table (1/2)
• The requirement diagram has a distinct
disadvantage when viewing large numbers
of requirements
• The traditional method of viewing requirements
in textual documents is a more compact
representation than viewing them in a diagram
• SysML embraces the concept of displaying
results of model queries in tables as well
as using tables as a data input
mechanism, but the specifics of generating
tables is left to the tool implementer
27

28. Requirements Table (2/2)
• The tabular format can be used to
represent the requirements, their
properties and relationships
28

29. Distiller Sample Problem
29

30. Requirement Packages
• Requirements can be organized into a
package structure
• A typical structure may include a top-level
package for all requirements
• Each nested package within this package may
contain requirements from different
specifications (system, subsystem, component,
etc.)
• Each specification package contains the text-
based requirements for that specification
• This package structure corresponds to a typical
specification tree that is a useful artifact for
describing the scope of requirements for a
project
30

31. Other Ways to Represent
“Requirements”
• Nearly all SysML diagram types can
represent Requirements!
• Use Case Diagram
• Sequence Diagram
• State Diagram
• Activity Diagram
• Block Definition Diagram
• Internal Block Diagram
• Parametric Diagram
31

32. Use Case Diagram
• The Use Case diagram describes the
usage of a system (subject) by its actors
(environment) to achieve a goal, that is
realized by the subject providing a set of
services to selected actors
32

33. Sequence Diagram
• The Sequence diagram describes the flow
of control between actors and systems
(blocks) or between parts of a system
• This diagram represents the sending and
receiving of messages between the
interacting entities called lifelines, where
time is represented along the vertical axis
33

34. Sequence Diagram
34

35. State Machine Diagram
• The StateMachine package defines a set
of concepts that can be used for modeling
discrete behavior through finite state
transition systems
• The state machine represents behavior
as the state history of an object in terms
of its transitions and states
35

36. State Machine Diagram
36

37. Activity Diagram
• Activity modeling emphasizes the inputs,
outputs, sequences, and conditions for
coordinating other behaviors. It provides
a flexible link to blocks owning those
behaviors
37

38. Activity Diagram
38

39. Block Definition Diagram
• The Block Definition Diagram defines
features of blocks and relationships
between blocks such as associations,
generalizations, and dependencies
• It captures the definition of blocks in
terms of properties and operations, and
relationships such as a system hierarchy
or a system classification tree
39

40. Block Definition Diagram
(Domain)
40

41. Internal Block Diagram (Domain)
• The Internal Block Diagram captures the
internal structure of a block in terms of
properties and connectors between
properties
• A block can include properties to specify
its values, parts, and references to other
blocks
• Ports are a special class of property used
to specify allowable types of interactions
between blocks
41

42. Internal Block Diagram (Domain)
42

43. Parametric Diagram
• Parametric diagrams include usages of
constraint blocks to constrain the
properties of another block
• The usage of a constraint binds the
parameters of the constraint, such as F,
m, and a, to specific properties of a block,
such as a mass, that provide values for
the parameters
43

44. Parametric Diagram
44

45. The Four Pillars
of SysML (1/2)
45

46. The Four Pillars
of SysML (2/2)
46

47. Industrial Feedback (1)
47
• In 2009, MagicDraw R&D decided to
migrate from Document-driven to Model-
driven Requirement Engineering using
SysML
• Advantages:
• Much better teamwork and version
management capabilities
• More formal/structured descriptions of the
requirements
• Maintain the information about already
implemented functionality
• Traceability to the architecture and test cases

48. Industrial Feedback (2)
48
• SE^2 and APE Case Study
• Large telescope SysML Model
• Guidelines for modeling Requirements:
• Distinguish Objectives, Stakeholder
Requirements, System Requirements and
Analysis elements (e.g. Use Cases)
• Modeling can be used for requirements
specification
• Above a certain number of requirements, they
become difficult to visualize graphically. It is
better to use the tabular format
• SysML requirements are not a replacement of
RM tools but a visualization aid for
architectural important requirements

49. APE Project Examples
(1/5)
49

50. APE Project Examples
(2/5)
50

51. APE Project Examples
(3/5)
51

52. APE Project Examples
(4/5)
52

53. APE Project Examples
(5/5)
53

54. Tools (1/3)
54
http://www.sparxsy
stems.com.au/reso
urces/demos/Trace
ability/Traceability_
Impact.htm

55. Tools (2/3)
55
http://www.nomagic.com/products/
cameo-systems-modeler.html

56. Tools (3/3)
56

57. Conclusion (1/3)
57
• A Requirements Model can provide
information that helps determine if the
requirements meet their desired attributes
• SysML requirements modeling provides a
‘link’ between the text requirements and
the rest of the model elements
• … But for the moment, SysML
requirements are not a complete
replacement of RM tools

58. Conclusion (2/3)
58
• SysML Requirement modeling concept
should not remain just a buzz!
• It can be a real breakthrough for people
who do not master yet a tooled
Requirements Management process
• It can be also valuable for people used to
Requirements Management tools
• Models can help a lot to formalize requirements
(state machines, block diagrams, etc.)
• Diagrams are a very powerful communication
tool between all stakeholders

59. Conclusion (3/3)
59
Validation Tests
System Validation
User
Requirements
Need Operational Use
derivation
Components
Requirements
Components
Tests
Components Verification
Subsystems
Requirements
Subsystems
Tests
Subsystems Verification
derivation
System
Requirements Verification Tests
System Verification
derivation

60. Additional Resources…
• Websites:
• www.omgsysml.org/
• www.incose.org/
• http://mbse.gfse.de/index.html
• Books:
• P. Roques, SysML par l’exemple,
2009, Eyrolles
• S. Friedenthal, A. Moore, and R. Steiner, A
Practical Guide to SysML, 2011, OMG Press
• T. Weilkiens, Systems Engineering with
SysML/UML: Modeling, Analysis, Design, 2008,
OMG Press
60