This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam. http://www.ivanomalavolta.com

1. Software and Services research group (S2)
Department of Computer Science, Faculty of Sciences
Vrije Universiteit Amsterdam
VRIJE
UNIVERSITEIT
AMSTERDAM
Requirements engineering with
UML
Software design (400170) – 2017/2018
Ivano Malavolta
i.malavolta@vu.nl

2. VRIJE
UNIVERSITEIT
AMSTERDAM
Announcement
The template for Deliverable 1 is already available on Canvas!
2

3. VRIJE
UNIVERSITEIT
AMSTERDAM
Roadmap
• Introduction to UML
• What is UML?
• Main characteristics of UML
• UML diagrams
• Requirements engineering
• Use case diagrams
3

4. VRIJE
UNIVERSITEIT
AMSTERDAM
What is UML?
• In the 80s there were multiple OO approaches
• each approach had its own notation
• then Rational Inc. (now IBM)
4
Booch notation Jacobson‘s OOSE Rumbaugh's Technique

5. VRIJE
UNIVERSITEIT
AMSTERDAM
What is UML?
• UML = Unified Modeling Language
• De facto standard software design language
• Developed by OMG
• A “Swiss Army Knife” of notations
5

6. VRIJE
UNIVERSITEIT
AMSTERDAM
Why UML in this course?
The most used language for modeling software
6
38 job postings requiring UML in Amsterdam
(as of today)

7. VRIJE
UNIVERSITEIT
AMSTERDAM
Who uses UML?
7

8. VRIJE
UNIVERSITEIT
AMSTERDAM
Main characteristics of UML
• It is not tied to any development process
• à waterfall, agile, whatever…
• Can be used across the whole life cycle
• promotes iterative refinement of models
• General purpose
• it can be used for modeling a mobile app, but also a satellite
• It has different representations:
• graphical
• textual
• others…
8

9. VRIJE
UNIVERSITEIT
AMSTERDAM
Main characteristics of UML
• It is comprehensive
• all parts of a system can be described using UML
• It is scalable
• you can zoom in with additional details when needed
• Originally intended for descriptive models
• Now it also supports prescriptive models
• models execution
• code generation
• but more importantly…
9

10. VRIJE
UNIVERSITEIT
AMSTERDAM
Main characteristics of UML
UML is a formal modeling language
à all its concepts have a well-defined meaning
10
Modeling with code Informal model
UML model

11. VRIJE
UNIVERSITEIT
AMSTERDAM
Where are the “meanings” of UML concepts?
The UML superstructure
640 pages like this à
Don’t read it! Use it only as
a manual in case of doubts
http://www.omg.org/spec
/UML/2.5/
11

12. VRIJE
UNIVERSITEIT
AMSTERDAM
UML diagrams
A UML model is represented graphically by diagrams
12

13. VRIJE
UNIVERSITEIT
AMSTERDAM
UML structure diagrams
• Emphasize the static
description of the elements
of the system being modeled
• ex: student submission
system à
• Structural elements may
have an associated behavior
13

14. VRIJE
UNIVERSITEIT
AMSTERDAM
UML behavioural diagrams
• Behavior = the direct
consequences of an action of at
least one object
• It affects how the states of
objects change over time
• Behavior can be either
• specified through the actions
of a single object
• result from interactions
between multiple objects à
14
Submission

15. VRIJE
UNIVERSITEIT
AMSTERDAM
Which diagrams you will see in this course
• Use case diagram
• to specify the basic functionality of a software system
• aka requirements
• Class diagram
• to define data structures within the system
• State machine diagram
• to define intra-object behavior
• Sequence diagram
• specifies inter-object behavior and communication
15
In your project you can use additional UML diagrams
à BONUS in the final grade

16. VRIJE
UNIVERSITEIT
AMSTERDAM
Models != diagrams
• A UML model contains everything related to your system
• it is complete
• Diagrams are just “windows” on your model
• technically they can be considered as projections of the
same model
• a particular diagram will show some parts of your model but
not necessarily everything (recall abstraction?)
16
represented
by
System Model
Class diagram
Sequence
diagram
State machine
diagram

17. VRIJE
UNIVERSITEIT
AMSTERDAM
Models and diagrams in Papyrus
17
Diagram creation

18. VRIJE
UNIVERSITEIT
AMSTERDAM
Models and diagrams in Papyrus
18The model
The diagrams

19. VRIJE
UNIVERSITEIT
AMSTERDAM
Requirements engineering
19

20. VRIJE
UNIVERSITEIT
AMSTERDAM
Requirements engineering
• The process of establishing
• the services that a customer requires from a system
• the constraints under which it operates and is developed
• A requirement may range between
• a high-level abstract statement of a service
• Example: all the robots must avoid obstacles autonomously
• a detailed mathematical functional specification
• Example: each robot must communicate its position to the
central station every 1 second
20

21. VRIJE
UNIVERSITEIT
AMSTERDAM
Functional and non-functional requirements
Functional requirements
a. Services the system should provide
b. How the system should react to particular inputs
c. How the system should behave in particular situations
d. May state what the system should not do
Non-functional requirements
a. Constraints on the services or functions offered by the system
I. example: timing constraints, constraints on the development
process, standards, etc.
b. Often apply to the system as a whole rather than individual
features or services
21

22. VRIJE
UNIVERSITEIT
AMSTERDAM
Functional requirements
• Precise
• Ambiguous requirements may be interpreted in different
ways by developers and users à problems
• Complete
• They should include descriptions of ALL facilities required
• Consistent
• There should be no conflicts or contradictions in the
descriptions of the system facilities
• In UML they are represented using Use case diagrams
22

23. VRIJE
UNIVERSITEIT
AMSTERDAM
Non-functional requirements
• System properties and constraints
• e.g. reliability, response time and storage requirements
• Constraints are I/O device capability, system
representations, etc.
• Non-functional requirements may be more critical than
functional requirements
• e.g., safety requirements
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components
• For example, to ensure that performance requirements are
met, you may have to organize your system to minimize
communications between robots
23

24. VRIJE
UNIVERSITEIT
AMSTERDAM
Types of non-functional requirements
24
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Dependability
requirements
Security
requirements
Regulatory
requirements
Ethical
requirements
Legislative
requirements
Operational
requirements
Development
requirements
Environmental
requirements
Safety/security
requirements
Accounting
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements

25. VRIJE
UNIVERSITEIT
AMSTERDAM
Robotic systems MUST be dependable
25

26. VRIJE
UNIVERSITEIT
AMSTERDAM
Ways of writing requirements specifications
26
Notation Description
Natural language The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.
Structured natural
language
The requirements are written in natural language on a standard form or
template. Each field provides information about an aspect of the requirement.
Design description
languages
This approach uses a language like a programming language, but with more
abstract features to specify the requirements by defining an operational model
of the system. This approach is now rarely used although it can be useful for
interface specifications.
Graphical
notations
Graphical models, supplemented by text annotations, are used to define
the functional requirements for the system; UML use case and sequence
diagrams are commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state
machines or sets. Although these unambiguous specifications can reduce the
ambiguity in a requirements document, most customers don’t understand a
formal specification. They cannot check that it represents what they want and
are reluctant to accept it as a system contract

27. VRIJE
UNIVERSITEIT
AMSTERDAM
Natural language specification
• Requirements are written as natural language sentences
• Used for writing requirements because it is expressive,
intuitive and universal.
• These requirements can be understood by users and
customers
• Guidelines:
• Invent a standard format and use it for all requirements
• Use language in a consistent way
• Use “shall” for mandatory requirements, “should” for desirable
requirements
• Use text highlighting to identify key parts of the requirement
• Avoid the use of computer jargon
• Include an explanation (rationale) of why a requirement is
necessary
27

28. VRIJE
UNIVERSITEIT
AMSTERDAM
Example
28
R1. The system shall measure the blood sugar and deliver insulin, if required,
every 10 minutes. (Changes in blood sugar are relatively slow so more
frequent measurement is unnecessary; less frequent measurement could lead
to unnecessarily high sugar levels.)
R2. The system shall run a self-test routine every minute with the conditions to
be tested and the associated actions defined in Table 1. (A self-test routine can
discover hardware and software problems and alert the user to the fact the
normal operation may be impossible.)

29. VRIJE
UNIVERSITEIT
AMSTERDAM
Requirement validation checklist
29
• Validity
• Does the system provide the functions which best support
the customer’s needs?
• Consistency
• Are there any requirements conflicts?
• Completeness
• Are all functions required by the customer included?
• Realism
• Can the requirements be implemented given available
budget and technology
• Verifiability
• Can the requirements be checked?
I will use it when grading your project

30. VRIJE
UNIVERSITEIT
AMSTERDAM
Use case diagrams
30

31. VRIJE
UNIVERSITEIT
AMSTERDAM
Contents
• Introduction
• Use cases
• Actors
• Relationships between use cases and actors
• Relationships between use cases
• Relationships between actors
• Description of use cases
• Best practices
• Typical errors
• Notation elements
31

32. VRIJE
UNIVERSITEIT
AMSTERDAM
Introduction
Use case diagrams express the expectations of the
customers/stakeholders
§ essential for a detailed design
We can use a use case diagram to answer the following
questions:
§ What is being described? (The system)
§ Who interacts with the system? (The actors)
§ What can the actors do? (The use cases)
32

33. VRIJE
UNIVERSITEIT
AMSTERDAM
Example: Student Administration System
System
(what is being described?)
§ Student administration system
Actors
(who interacts with the system?)
§ Professor
Use cases
(what can the actors do?)
§ Query student data
§ Issue certificate
§ Announce exam

34. VRIJE
UNIVERSITEIT
AMSTERDAM
Use Case
• Describes functionality expected from the system under
development
• The set of all use cases describes the functionality that a
system shall provide
• Alternative notations:

35. VRIJE
UNIVERSITEIT
AMSTERDAM
Actor (1/2)
Actors interact with the system
§ by using use cases,
i.e., the actors initiate the execution of use cases
§ by being used by use cases,
i.e., the actors provide functionality for the execution of use
cases.
Actors represent roles that users adopt
§ Specific users can have multiple roles simultaneously
Actors are not part of the system, i.e., they are outside of the
system boundaries
Alternative notations:

36. VRIJE
UNIVERSITEIT
AMSTERDAM
Actor (2/2)
Human
§ E.g., Student, Professor
Non-human
§ E.g., E-Mail Server
Primary: has the main benefit of the execution of the use case
Secondary: receives no direct benefit
Active: initiates the execution of the use case
Passive: provides functionality for the execution of the use case
Examples:
8
Non-human
Secondary
Passive
Human
Primary
Active
Human
Primary
Active
Human
Secondary
Active

37. VRIJE
UNIVERSITEIT
AMSTERDAM
Relationships between Use Cases and Actors
• Actors are connected with use cases via solid lines
(associations)
• Every actor must communicate with at least one use case
• An association is always binary
• Multiplicities may be specified

38. VRIJE
UNIVERSITEIT
AMSTERDAM
The behavior of one use case (included use case) is ALWAYS
integrated in the behavior of another use case (base use case)
Example:
Relationships between Use Cases
«include» - Relationship
Base use case
requires the behavior of the included use
case to be able to offer its functionality
Included use case
may be executed on its own

39. VRIJE
UNIVERSITEIT
AMSTERDAM
Relationships between Use Cases
«extend» - Relationship
• The behavior of one use case (extending use case) may be
integrated in the behavior of another use case (base use case)
but does not have to
• Both use cases may also be executed independently of each
other
• A decides if B is executed
• Extension points define at which point the behavior is
integrated
• Conditions define under which circumstances the behavior is
integrated
Base use case
Extending use case

40. VRIJE
UNIVERSITEIT
AMSTERDAM
Relationships between Use Cases
«extend» - Relationship: Extension Points
• Extension points are written directly within the use case
• Specification of multiple extension points is possible
• Example:

41. VRIJE
UNIVERSITEIT
AMSTERDAM
Relationships between Use Cases
Generalization of Use Cases
Use case A generalizes use case B.
B inherits the behavior of A and may
either extend or overwrite it.
B also inherits all relationships from A.
B adopts the basic functionality of A but
decides itself what part of A is executed or changed.
A may be labeled {abstract}
§ Cannot be executed directly
§ Only B is executable
Example:
Base use case
Sub use case

42. VRIJE
UNIVERSITEIT
AMSTERDAM
Relationships between Actors
Generalization of Actors
Actor A inherits from actor B
A can communicate with X and Y
B can only communicate with Y
Abstract actors are possible
Example:
Super-actor
Sub-actor
Professor AND Assistant needed
for executing Query student data
Professor OR Assistant needed
for executing Query student data

43. VRIJE
UNIVERSITEIT
AMSTERDAM
Description of Use Cases
Structured approach
§ Name
§ Short description
§ Precondition: prerequisite for successful execution
§ Postcondition: system state after successful execution
§ Error situations: errors relevant to the problem domain
§ System state on the occurrence of an error
§ Actors that communicate with the use case
§ Trigger: events which initiate/start the use case
§ Standard process: individual steps to be taken
§ Alternative processes: deviations from the standard process
[A. Cockburn: Writing Effective Use Cases, Addison Wesley,
2000]

44. VRIJE
UNIVERSITEIT
AMSTERDAM
Description of Use Cases - Example
Name: Reserve lecture hall
Short description: An employee reserves a lecture hall at the university for an event.
Precondition: The employee is authorized to reserve lecture halls.
Postcondition: A lecture hall is reserved.
Error situations: There is no free lecture hall.
System state in the event of an error: The employee has not reserved a lecture hall.
Actors: Employee
Trigger: Employee requires a lecture hall.
Standard process: (1) Employee logs in to the system.
(2) Employee selects the lecture hall.
(3) Employee selects the date.
(4) System confirms that the lecture hall is free.
(5) Employee confirms the reservation.
Alternative processes: (4’) Lecture hall is not free.
(5’) System proposes an alternative lecture hall.
(6’) Employee selects alternative lecture hall and confirms the
reservation.

45. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Identifying Actors
• Who uses the main use cases?
• Who needs support for their daily work?
• Who is responsible for system administration?
• What are the external devices/(software) systems with which
the system must communicate?
• Who is interested in the results of the system?

46. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Identifying Use Cases
• What are the main tasks that an actor must perform?
• Does an actor want to query or even modify information
contained in the system?
• Does an actor want to inform the system about changes in
other systems?
• Should an actor be informed about unexpected events within
the system?

47. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Typical Errors To Avoid (1/5)
Use case diagrams do not model processes/workflows!

48. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Typical Errors To Avoid (2/5)
Actors are not part of the system, hence, they are positioned
outside the system boundaries!

49. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Typical Errors To Avoid (3/5)
§ Beware of incorrect associations!
§ Use case Issue information needs EITHER one Assistant OR
one Professor
ü

50. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Typical Errors To Avoid (4/5)
Too many use cases, one for each possible situation
à Many small use cases that have the same objective may be
grouped to form one use case
ü

51. VRIJE
UNIVERSITEIT
AMSTERDAM
Best Practices
Typical Errors To Avoid (5/5)
Detailed functional decomposition
à The various steps of a functionality are part of the same use
case, not separate use cases themselves!
ü

52. VRIJE
UNIVERSITEIT
AMSTERDAM
Name Notation Description
System
Boundaries between the system
and the users of the system
Use case Unit of functionality of the system
Actor Role of the users of the system
Notation Elements (1/2)

53. VRIJE
UNIVERSITEIT
AMSTERDAM
Name Notation Description
Association
Relationship between use cases
and actors
Generalization
Inheritance relationship between
actors or use cases
Extend
relationship
B extends A: optional use of use
case B by use case A
Include
relationship
A includes B: required use of use
case B by use case A
Notation Elements (2/2)

54. VRIJE
UNIVERSITEIT
AMSTERDAM
What this lecture means to you?
• UML = general purpose modeling language
• tailored to object-oriented software systems
• 1 UML model, many diagrams
• Requirements
• functional vs non-functional
• Functional = the WHAT
• text + use case diagrams + use case descriptions
• Non-functional = the HOW
• text + rationale
• UML use case diagrams rules and best practices
55

55. VRIJE
UNIVERSITEIT
AMSTERDAM
Readings
• UML@Classroom: An Introduction to Object-Oriented
Modeling” – chapters 2 and 3
• Learning UML 2.0 – chapters 1 and 2
56