4.REQ - APPLICATIONS Eee403

Req.
Applications, Systems Engineering
Systems Engineering Course Notes
Do not copy or distribute without the author’s permission

REQUIREMENTS
4 ENGINEERING
APPLICATIONS
Orkun Zorba, Ph.D., 2021
Contents
Req. Applications, Systems Engineering
1. UML-Unified Modeling Language

2. SysML-System Modeling Language
3. Use Case Diagrams
4.Activity Diagrams
5. Requirement Diagrams
6. A Tool For Requirements
7. Basic Modeling
8.Systems Modeling
2
UML-Unified
1 Modeling
Language
Standard notation defined by OMG
OMG: Object Management Group

An international not-for-profit software consortium
setting standards in the area of distributed object
computing.
conceptual things
• business processes
• system functions
concrete things
• programming language statements
«A graphical language for visualizing, • database schemas
specifying, constructing, and documenting the • reusable software components
artifacts of a software-intensive system»
4
History of UML
Latest version: 2.5.1

December 2017
5
6 main properties of UML

1. Graphical display format
2. Data, process, system
3. Dictionary of symbols
4. Object oriented
5. De-facto standard
6. Basic diagram types

6
Advantages of UML
Common language between Early detection of errors

technical and non-technical
Better understanding of
systems
7
Documentation
Diagrams
• Project documentation
Use case diagrams

• Functional requirements
Classes or component diagrams

• Software architecture in a design
document
UML diagrams
• Any technical documentation
8
UML standard
The official
specification Normative Document
for UML 2.5.1 • Formal specification
is a complex
work of over Normative Machine Consumable Documents
one thousand • Abstract Syntax Metamodel
pages • Primitive Types
(uml.org, • Standard Profile
omg.org) • Diagram Interchange Metamodel
Informative Document
• Specification changebar
9
UML diagrams
Dynamic
Static
10
Diagram implementation
USE CASE DIAGRAM • Analysis Phase
ACTIVITY DIAGRAM • Analysis & Design Phase
PACKAGE DIAGRAM • Analysis & Design Phase
DEPLOYMENT DIAGRAM • Analysis & Design Phase
SEQUENCE DIAGRAM • Design Phase
COMMUNICATION DIAGRAM • Design Phase
STATE DIAGRAM • Design Phase
COMPONENT DIAGRAM • Design Phase
CLASS DIAGRAM • Design Phase

11
SysML- System
2 Modeling
Language
Systems Engineering Version of UML
What is SysML?
The OMG Systems Modeling
Language™ (OMG 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. Latest version: 1.5
May 2017 13
Complex systems
Complex Systems
hardware software information personnel procedures facilities
14
UML vs. SysML
• OMG XML
Metadata
Interchange
(XMI)
• ISO 10303-
233 systems
engineering
data
interchange
standard
15
Fundamental design principles
Requirements-
UML reuse UML extensions
driven
Partitioning Layering Interoperability

16
SysML diagrams
17
Example from formal document
Graphical nodes
used in
requirements
diagram
18
3 Use-Case
Diagrams
Use cases, actors, different connectors
Scope
Business view
Business
use case Actor: Outside the organization
Business operations
System view
System
use case Actor: Entity using the system
System requirements
Software view
Software
use case Actor: Entity using the software (may be o part of the system)
Software requirements
20
Use case diagram
Captures requirements
of a system
Means of
communicating with
users and other
stakeholders
21
Actors
A named stick
Human users,
Actors: External figure, or a class
external hardware
entities rectangle with
or other systems
«actor» keyword
22
Use cases
A connecting line
Use case: A high-level view The ellipse
with an optional
meaningful work of behavior notation
arrowhead
23
Actors & use cases

• Actor «Customer» uses the
«Withdraw» use case.
• «Uses» connector can optionally

have multiplicity values at each
end.
• «A customer may only have one
withdrawal session at a time»
• «A bank may have any number of
customers making withdrawals
concurrently». 24
Use case definition

Use cases typically include the
followings.
▪ Name and description
▪ Requirements
▪ Constraints
▪ Scenarios
▪ Scenario diagrams
▪ Additional information
25
Use case diagram example
ATM system
26
Ticket reservation
system; customer
use case diagram
27
Ticket reservation
system;
administrator use
case diagram
28
➢ Be careful that use cases are the functionalities provided by the

systems to the user.
➢ They are not the things what the user does.
➢ They are the functionalities of the systems that user «uses».
➢ Customer uses withdraw functionality provided by the system. If the
system doesn’t exist customer won’t withdraw. If the customer
doesn’t exist system will still have this functionality to be used.
29
«Actors» & «use cases»
User of the system; a human user, a Describes how a user of the proposed
machine, or even another system. system interacts with the system to perform
a discrete unit of work.
Anything that interacts with the system from Describes and signifies a single interaction
the outside or system boundary. over time that has meaning for the end user.
Typically associated with Use Cases. Has requirements and constraints that
describe the essential features and rules
under which it operates.
Can use the system through a graphical Has scenarios that describe the workflow
user interface, through a batch interface or over time.
through some other media.
30
«System boundary» & «use» connector
Non-UML element used to define conceptual Indicates that one element requires another
boundaries. to perform some interaction.
Helps group logically related elements Does not specify how the target supplier is
(from a visual perspective, not as part of the used, other than that the source client uses
UML model). it in definition or implementation.
Encloses the Use Case and associated with Used it in Use Case diagrams to model how
a classifier such as a Class, Component or Actors use system functionality.
Subsystem.
31
«Association» & «generalization»
Used to indicate inheritance.
Implies that two model elements have a

Drawn from the specific classifier to a
relationship, usually implemented as an
general classifier, implication is that the
instance variable in one or both Classes.
source inherits the target's characteristics.
Can include named roles at each end,
Used in Class, Component, Object, Package,
multiplicity, direction and constraints.
Use Case and Requirements diagrams.
Indicate the reading direction by adding a

Name Direction Indicator arrow to the
name-label on the connector.
32
«Include» & «extend» connectors
Indicates that the source element includes Used to indicate that an element extends the
the functionality of the target element. behavior of another, mainly in Use Case
models where one Use Case (optionally)
extends the behavior of another Use Case.
Used in Use Case models to reflect that one Expresses alternative flows that are
Use Case includes the behavior of another. integrated with the behavior of the extended
Use Case.
Used to avoid having the same subset of There may more than one extension point,
behavior in many Use Cases; this is similar and can be extended by more than one other
to delegation used in Class models. Use Case.
33
4 Activity
Diagrams
Activities, actions
Activity diagram
Displays sequence of activities
Shows the workflow from a start point to the finish point
Many decision paths exist in the progression of events
35
Activity diagram example
activity
action
36
«Activity» and «action»
Organizes and specifies the participation of Describes a basic process or transformation

subordinate behaviors, such as sub- that occurs within a system, and is the basic
Activities or Actions, to reflect the control functional unit within an Activity diagram.
and data flow of a process.
Used in Activity diagrams for various Can be thought of as children of Activities;
modeling purposes, from procedural-type both represent processes, but Activities can
application development, to business contain multiple steps, each can be
process modeling. embodied in an Action.
Contains Action elements and includes input Cannot be further broken down or
parameters and output parameters. decomposed.
37
«Partition» & «decision» & «merge»
Partitions the Actions of the Indicates a point of Brings together a number of

Activity without affecting the conditional progression: if a alternative flow paths in
token flow, helping to structure condition is True, then Activity.
the view or parts of the Activity. processing continues one
way; if not, then another.
38
«Initial» & «final» and «flow final»
Depicts an exit from the

system that has no effect on
other executing flows in the
Activity.
Defines the start of a flow
when an Activity is invoked.
Indicates the completion of an

Activity; upon reaching the
Final, all execution in the
Activity diagram is aborted.
39
«Fork/join» & «control flow»
Fork or split the flow into a number of Connects two nodes in an Activity diagram,
concurrent flows modeling an active transition.
Join the flow of a number of concurrent Bridge the flow between Activity nodes, by
flows directing the flow to the target node once
the source node's activity is completed.
Both join and fork a number of incoming

flows to a number of outgoing flows
40
«Object flow» & «interrupt flow»
Connects two elements, with specific data Used to define the two UML concepts of
passing through it, modeling an active connectors for Exception Handler and
transition. Interruptible Activity Region.
41
«Exception handlers»
Exception handlers can be modeled on activity diagrams, as in the

example below.
42
«Interruptible activity region»

An interruptible
• “Process Order” action will execute until completion
activity region
• When it will pass control to the “Close Order” action
surrounds a group of • Unless a “Cancel Request” interrupt is received
actions that can be • Which will pass control to the “Cancel Order” action.
interrupted.
43
«Partition»
Activity partition: horizontal or vertical
swimlane.
Used when there are more than one

actors/entities sharing the same objects but
having different use cases in the system.
Partitions are used to separate actions within

an activity into
• those performed by the accounting

department
• those performed by the customer.
44
5 Requirements
Diagrams
Functional, non-functional
Requirements diagram
Visual representation of how requirements are related to each other and to other
elements in the model.
Business Business
Constraints
Drivers Rules
User Design
Use Cases
Stories Components
46
The diagram is one of the
extended diagram types and for
analysts who are accustomed to
working with requirements in a
text based tool it will provide a
welcomed and compelling
graphical representation of the
requirements.
47
Usage
One usage is to show how requirements are connected together in a hierarchy,
but a more compelling usage is to show how requirements are connected to
other elements.
The experienced modeler will define and manage the requirements in the
Specification Manager and then use the Requirements Diagram to show how one
or more requirements are related to up-process elements such as Business
Drivers and down-process elements such as Use Cases, User Stories, User
Experience designs and solution Components.
48
Options
The appearance of a diagram can be
changed to suit the audience, and details
can be included, suppressed or altered to
ensure the diagram meets its main
objective of communication. There is a wide
range of options, ranging from creating a
Hand Drawn style of diagram to page set
up.
49
Details of a requirement
• The system shall include a complete inventory management
REQ019-Manage
facility to store and track stock of books for the on-line
Inventory
bookstore.
• A facility shall exist to list current stock levels and to
REQ021-List Stock
manually update stock quantities if physical checking reveals
Levels
inconsistencies.
• A book order facility shall be required to allow on-line
REQ022-Order Books
ordering from major stocklist’s.
• A facility to receive and add books to the inventory shall be
REQ020-Receive
required. Books shall be received in batch shipments from the
Books
usual suppliers and manually recorded in the system.
REQ023-Store and
• A book storage and management facility shall be required.
Manage Books
• A facility shall be required to receive and add books to the
REQ027-Add Books
stock lists. 50
Requirements element
Example: Online Book Ordering System

51
Details of a requirement
52
Tracing requirements
This diagram shows the expressive power of putting disparate elements onto a
diagram.
It shows the traceability between different layers of a system. The traceability
can be from the Requirements to the Use Cases that Realize them, to the logical
Components that will deliver the required functionality.
53
Specification manager
The Specification Manager is a
document-based interface to
the Package selected in the
model. It provides a means of
creating and reviewing
elements in the package as text
representations of those
elements.
It is particularly useful when
entering Requirements into your
model.
54
Elicitation workshops
This diagram shows the flexibility of
Mind Mapping as a technique for
recording needs elicited from
stakeholders. It allows the modeler to
keep a record of the workshops right
inside the model.
Once the analysis is complete,
stakeholder requirements can then be
linked back to topics in this diagram.
55
User stories
User Stories are useful as an
alternate way of describing user
requirements.
They are typically used as part of an

Agile development process, to
provide a simple but clear
description of what the user does or
needs to do as part of the role they
perform.
56
Non-functional requirements
The Non Functional

Requirements have been
defined using a number of
separate packages.
The packages can then be

displayed on a diagram,
showing the Requirements
they contain.
57
6 A Tool For
Requirements
Enterprise Architect
Setting Up
Download EA trial from Enterprise Architect
sparxsystems.com
Install it into your PC/laptop.
Use preferably «ultimate» or

«systems engineering»
configuration to start the tool.
Investigate EAExample file.
59
What can be done with EA?

▪ Business Process Modeling and
Simulation
▪ Data Modeling and Database Engineering
▪ Requirements Management
▪ Spatial Information Modeling with GML
and ArcGIS
▪ Strategic Modeling
▪ User Interface, Tools and Productivity
▪ Systems Engineering Boosters
▪ Test Management ▪ Document Generation and Reporting
▪ UI Design and Wireframes for Mobile ▪ Traceability and Accountability
Apps and Web Pages
▪ Charts and Dashboards 60
Getting Started
▪ 1. Basic Modeling
▪ 2. Systems Modeling
▪ 3. Business Modeling
▪ 4. Software Modeling
▪ 5. Requirements Model
▪ 6. Project Management
61
7
Basic Modeling
EA Example
Getting Started/EA Example

A. Basic modeling B. System modeling
A.1. Requirements model B.1. SysML Example Audio Player
A.1.a. Requirements diagram
B.1.a. Requirements model
A.1.a.i. Requirement detail
A.1.a.ii. Tracing requirements B.1.a.i. Specifications
A.1.b. Specification manager
A.1.c. Tracing requirements
A.1.c.i. Traceability diagram
A B B.1.a.ii. Use cases
B.1.a.ii.1. Top level
B.1.a.ii.2. Maintain
A.1.c.ii. Realtionships window playlist
A.1.c.iii. Traceability window B.1.a.ii.3. Operate audio
A.1.c.iv. Relationship matrix player
A.2. Use case diagrams B.1.a.ii.4. Maintain audio
A.2.a. Manage users player
A.2.b. Manage inventory
B.1.b. Domain model
A.2.c. Take orders
A.2.d. Fulfil orders
A.3. Activity diagrams
A.3.a. Activity diagram
A.3.b. Partitioned activity diagram
A.3.c. Sub-activity diagram
A.3.d. Interruptible activity regions
63
Basic Modeling
A. Basic modelling
A.1. Requirements model
A.1.a.ii. Tracing requirements
A.1.c. Tracing requirements 2 1
A.1.c.ii. Realtionships window
A.1.c.iii. Traceability window
A.1.c.iv. Relationship matrix
A.2. Use case diagrams
A.2.a. Manage users 3
A.2.c. Take orders
64
Requirements model
A. Basic modeling
a b c
A.2.a. Manage users
A.2.c. Take orders
65
A. Basic modeling
i
A.2.a. Manage users
A.2.c. Take orders
ii
66
Requirements detail
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
67
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
68
Specification manager
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
69
A. Basic modeling
i ii
A.2.a. Manage users
A.2.c. Take orders
iii iv
70
Tracing diagram
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
71
Relationship window
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
72
Traceability window
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
73
Relationship matrix
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
74
Use case diagrams

A. Basic modeling
a b
A.2.a. Manage users
A.2.c. Take orders
c d
75
Manage users
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
76
Manage inventory
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
77
Take orders
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
78
Fulfil orders
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
79
Activity diagrams
A. Basic modeling
a b
A.2.a. Manage users
A.2.c. Take orders
c d
80
Activity diagrams
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
81
Partitioned activity diagram

A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
82
Sub-activity diagram
A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
83
Interruptible activity regions

A. Basic modeling
A.2.a. Manage users
A.2.c. Take orders
84
8 System
Modeling
EA Example
Getting Started/EA Example

A. Basic modeling B. System modeling
A.1. Requirements model B.1. SysML Example Audio Player
A.1.a.ii. Tracing requirements B.1.a.i. Specifications
A B B.1.a.ii. Use cases
A.1.c.ii. Realtionships window playlist
A.1.c.iii. Traceability window B.1.a.ii.3. Operate audio
A.1.c.iv. Relationship matrix player
A.2. Use case diagrams B.1.a.ii.4. Maintain audio
A.2.a. Manage users player
B.1.b. Domain model
A.2.c. Take orders
86
System modeling
B. System modelling
B.1. SysML Example Audio Player
B.1.a.i. Specifications
B.1.a.ii. Use cases
playlist
1 B.1.a.ii.3. Operate audio

player
B.1.a.ii.4. Maintain audio
player
B.1.b. Domain model
87
SysML example audio

B. System modeling
B.1.a.ii. Use cases
a
b playlist
B.1.a.ii.3. Operate audio
player
player
B.1.b. Domain model
88
Requirements model
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
89
Specifications
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
90
Use cases
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
91
Top level
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
92
Maintain playlist
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
93
Operate audio player

B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
94
Maintain audio player

B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
95
Domain model
B. System modeling
B.1.a.ii. Use cases
playlist
player
player
B.1.b. Domain model
96
Summary
✓ UML and SysML are given with their history, advantages,
diagram types etc.
✓ Use case diagrams are given in detail.
✓ Activity diagrams are given in detail.
✓ Requirement diagrams are given in detail.
✓ EA tool is given with examples in Basic Modeling and System

Modeling.
Systems Engineering Course, Lecture-4: Requirements Applications, Orkun Zorba, Ph.D., 2021 97

4.REQ - APPLICATIONS Eee403

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4.REQ - APPLICATIONS Eee403

Uploaded by

Copyright:

Available Formats

Req.

Applications, Systems Engineering

Systems Engineering Course Notes

Do not copy or distribute without the author’s permission

1. UML-Unified Modeling Language

OMG: Object Management Group

Latest version: 2.5.1

6 main properties of UML

2. Data, process, system

6. Basic diagram types

Common language between Early detection of errors

Use case diagrams

Classes or component diagrams

ACTIVITY DIAGRAM • Analysis & Design Phase

PACKAGE DIAGRAM • Analysis & Design Phase

DEPLOYMENT DIAGRAM • Analysis & Design Phase

SEQUENCE DIAGRAM • Design Phase

COMMUNICATION DIAGRAM • Design Phase

STATE DIAGRAM • Design Phase

COMPONENT DIAGRAM • Design Phase

CLASS DIAGRAM • Design Phase

hardware software information personnel procedures facilities

UML vs. SysML

Fundamental design principles

Partitioning Layering Interoperability

Example from formal document

Use case diagram

Actors & use cases

• «Uses» connector can optionally

Use case definition

Use case diagram example

Use case diagram example

Use case diagram example

➢ Be careful that use cases are the functionalities provided by the

«Actors» & «use cases»

«System boundary» & «use» connector

«Association» & «generalization»

Used to indicate inheritance.

Implies that two model elements have a

Indicate the reading direction by adding a

«Include» & «extend» connectors

Shows the workflow from a start point to the finish point

Many decision paths exist in the progression of events

Activity diagram example

«Activity» and «action»

Organizes and specifies the participation of Describes a basic process or transformation

«Partition» & «decision» & «merge»

Partitions the Actions of the Indicates a point of Brings together a number of

«Initial» & «final» and «flow final»

Depicts an exit from the

Indicates the completion of an

«Fork/join» & «control flow»

Both join and fork a number of incoming

«Object flow» & «interrupt flow»

Exception handlers can be modeled on activity diagrams, as in the

«Interruptible activity region»

Used when there are more than one

Partitions are used to separate actions within

• those performed by the accounting

Example: Online Book Ordering System

They are typically used as part of an

The Non Functional

The packages can then be