Non-functional Requirements Engineering
Lecture 3/Part 1
1Chapter 4 Requirements engineering
Outline
 Non-functional requirements classification
 Discussion of selected 15 non-functional requirements
 Non-functional requirements implementation
 UML Activity diagram
2Chapter 4 Requirements engineering
Functional and non-functional requirements
 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
 E.g. A user shall be able to search the appointments lists for all
clinics.
 Non-functional requirements
 Properties and constraints on the services offered by the
system such as timing, reliability and security constraints,
constraints on the development process, platform, standards, etc.
 E.g. The system shall be available on Mon–Fri, 8 am – 5 pm, with
downtime not exceeding five seconds in any one day.
3Chapter 4 Requirements engineering
Verifiability of non-functional requirements
 Goals vs. verifiable requirements
 Usability requirement example
 Goal: The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized.
 Verifiable non-functional requirement: Medical staff shall be
able to use all the system functions after four hours of training.
After this training, the average number of errors made by
experienced users shall not exceed two per hour of system use.
4Chapter 4 Requirements engineering
Types of non-functional requirements
(excerpt)
5Chapter 4 Requirements engineering
Non-functional requirements classification
 Product requirements
 Requirements which specify that the delivered product must
behave with a certain quality e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
6Chapter 4 Requirements engineering
Examples of non-functional requirements in
a simple health-care system
Product requirement
The system shall be available on Mon–Fri, 8 am – 5 pm, with downtime
not exceeding five seconds in any one day.
Organizational requirement
Users of the system shall authenticate themselves using their health
authority identity card.
External requirement
The system shall implement patient privacy provisions as set out in
HStan-03-2013-priv.
7Chapter 4 Requirements engineering
 Can you add more examples to the listed categories?
Product requirements
 Dependability
 Availability
 Reliability
 Safety
 Security
 Efficiency
 Performance
 Space/resource utilization
 Modifiability
 Testability
 Usability
8
 Resilience
 Robustness
 Portability
 Adaptability
 Complexity
 Modularity
 Reusability
 Understandability
 Learnability
Chapter 24 Quality Management
Principal dependability attributes
9Chapter 11 Security and Dependability
Availability
 The probability that a system, at a point in time, will be
operational and able to deliver the requested services
 Concerned with
 How long the system should be operating without a failure.
 How long a system is allowed to be out of operation.
 Can be expressed quantitatively
 Using mean time to failure (MTTF) and repair (MTTR) as
MTTF / (MTTF + MTTR).
 I.e. availability of 0.999 means that the system is up and running
for 99.9% of the time. Can you explain of what time?
 Can MTTF and MTTR be derived from the defined availability?
10Chapter 11 Security and Dependability
Reliability
 The probability of failure-free system operation over a
specified time in a given environment for a given
purpose
 Concerned with
 How system fault/error/failure is detected.
 How frequently system fault/error/failure may occur.
 What happens when a fault/error/failure occurs.
 Can be expressed quantitatively
 Using the probability of failure on demand (POFOD) within a
single service or usage scenario execution, as 1 - POFOD.
 Could MTTF and MTTR be also used here?
11Chapter 11 Security and Dependability
Reliability terminology
Term Description
Human error or
mistake
Human behavior that results in the introduction of faults into a system.
E.g., in the wilderness weather system, a programmer might decide that the way
to compute the time for the next transmission is to add 1 hour to the current time.
This works except when the transmission time is between 23.00 and midnight .
System fault A characteristic of a software system that can lead to a system error.
E.g., the inclusion of the code to add 1 hour to the time of the last transmission,
without a check if the time is greater than or equal to 23.00.
System error An erroneous system state that can lead to system behavior that is unexpected
by system users.
E.g., the value of transmission time is set incorrectly (to 24.XX rather than 00.XX)
when the faulty code is executed.
System failure An event that occurs at some point in time when the system does not deliver a
service as expected by its users.
E.g., no weather data is transmitted because the time is invalid.
12Chapter 11 Security and Dependability
Availability and reliability
 It is sometimes possible to subsume system availability
under system reliability
 Obviously if a system is unavailable it is not delivering the
specified system services.
 However, it is possible to have systems with low
reliability that must be available.
 So long as system failures can be repaired quickly and does not
damage data, some system failures may not be a problem.
 Availability is therefore best considered as a separate
attribute reflecting whether or not the system can deliver
its services.
13Chapter 11 Security and Dependability
Safety
 Safety is a property of a system that reflects the system’s
ability to operate, normally or abnormally, without danger
of causing human injury or death and without damage
to the system’s environment.
 It is important to consider software safety as most
devices whose failure is critical now incorporate
software-based control systems.
 Safety requirements are often exclusive requirements
i.e. they exclude undesirable situations rather than
specify required system services. These generate
functional safety requirements.
14Chapter 11 Security and Dependability
Safety terminology
Term Definition
Accident (or mishap) An unplanned event or sequence of events which results in human death or injury,
damage to property, or to the environment.
E.g. an overdose of insulin.
Hazard A condition with the potential for causing or contributing to an accident.
E.g. a failure of the sensor that measures blood glucose.
Damage A measure of the loss resulting from a mishap. Damage can range from many people
being killed as a result of an accident to minor injury or property damage.
E.g., damage resulting from an overdose of insulin could be serious injury or
the death of the user of the insulin pump.
Hazard severity An assessment of the worst possible damage that could result from a particular hazard.
E.g. when an individual death is a possibility, a reasonable assessment of hazard
severity is ‘very high’.
Hazard probability The probability of the events occurring which create a hazard. Probability values tend to
be arbitrary but range from ‘probable’ (say 1/100 chance) to ‘implausible’.
E.g. the probability of a sensor failure in the insulin pump that results in an overdose
is probably low.
Risk This is a measure of the probability that the system will cause an accident. The risk is
assessed by considering the hazard probability, the hazard severity, and the probability
that the hazard will lead to an accident.
E.g. the risk of an insulin overdose is probably medium to low.
15Chapter 11 Security and Dependability
Safety and reliability
 Safety and reliability are related but distinct
 In most situations, reliability and availability are necessary and
sufficient conditions for system safety.
 There are situations when reliability and availability are not
necessary conditions for safety, and when they are not
sufficient conditions.
 Can you give an example of an unreliable & safe system?
 Can you give an example of an reliable & unsafe system?
 Reliability is concerned with conformance to a given
specification and delivery of service
 Safety is concerned with ensuring system cannot cause
damage irrespective of whether or not it conforms to its
specification
16Chapter 11 Security and Dependability
Security
 A system property that reflects the system’s ability to
protect itself from accidental or deliberate external
attack.
 Defends the system against:
 Threats to the confidentiality of the system and its data
• Can disclose information to people or programs that do not have
authorization to access that information.
 Threats to the integrity of the system and its data
• Can damage or corrupt the software or its data.
 Threats to the availability of the system and its data
• Can restrict access to the system and data for authorized users.
Security is an essential pre-requisite for availability, reliability and safety.
17Chapter 11 Security and Dependability
Security terminology
Term Definition
Asset Something of value which has to be protected (e.g. patients records in a healthcare
system). The asset may be the system itself or data used by that system.
Exposure Possible loss or harm to a computing system (e.g. financial loss from patients’
legal action or loss of reputation). This can be loss or damage to data, or can be
a loss of time and effort if recovery is necessary after a security breach.
Vulnerability A weakness in a computer-based system that may be exploited to cause loss or
harm (e.g. weak password).
Attack An exploitation of a system’s vulnerability. Generally, this is from outside the
system and is a deliberate attempt to cause some damage.
Threats Circumstances that have potential to cause loss or harm. You can think of these
as a system vulnerability that is subjected to an attack (e.g. guessing the weak
password).
Control A protective measure that reduces a system’s vulnerability. E.g. encryption is an
example of a control that reduces a vulnerability of a weak access control
system, or a password checking system in our example.
18Chapter 11 Security and Dependability
Dependability attribute dependencies
 Safe system operation depends on the system being
available and operating reliably.
 A system may be unreliable because its data has been
corrupted by an external attack.
 Service attacks on a system are intended to make it
unavailable.
 If a system is infected with a virus, you cannot be
confident in its reliability or safety.
Chapter 11 Security and Dependability 19
Performance
 Performance is about timing – response time to events
(interrupts, messages, requests from users, or the
passage of time).
 For a web-based financial system, the response might be the
number of transactions that can be processed in a minute,
 or the expected duration of a single transaction (given as a
random variable).
 Highly sensitive to concurrency effects (number of
users, shared resources), hardware, operating system
implementation (e.g. scheduler strategy), etc.
 Often accompanied by characterization of throughput
and resource utilization.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
20
Modifiability
 Modifiability is about the cost of change.
 What can change (the artifact)?
 The functions that the system computes, the platform the
system exists on (the hardware, operating system, middleware,
etc.), the environment within which the system operates, etc.
 When is the change made and who makes it (the
environment)?
 During implementation (by modifying the source code), compile
(using compile-time switches), build (by choice of libraries),
configuration setup (by a range of techniques, including
parameter setting) or execution (by parameter setting).
 By a developer, an end user, or a system administrator.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
21
Testability
 Software testability refers to the ease with which
software can be made to demonstrate its faults through
(typically execution-based) testing.
 About 40-60% of the cost of developing well-engineered systems
is taken up by testing. If the software architect can reduce this
cost, the payoff is large.
 The response measures for testability deal with how
effective the tests are in discovering faults and how
long it takes to perform the tests to some desired level
of coverage.
 For a system to be properly testable, it must be possible to
control each component's internal state and inputs and then to
observe its outputs.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
22
Usability
 Usability is concerned with how easy it is for the user to
accomplish a desired task and the kind of user support
the system provides.
 It can be broken down into the following areas:
 Learning system features.
 Using a system efficiently.
 Minimizing the impact of errors.
 Adapting the system to user needs.
 Increasing confidence and satisfaction.
 Always follow Human-Interface Guidelines (HIG) if
available (Windows HIG, Mac OS HIG, and others)
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
23
Organisational requirements
24Chapter 4 Requirements engineering
Organisational requirements
 Development requirements
 Programming language, development environment, process
standards, time to market, rollout schedule, costs, etc.
 Operational requirements
 Execution platform and other restrictions, system usage,
projected lifetime, etc.
 Environmental requirements
 Integration with legacy systems, targeted market, etc.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
25
Process standards [development]
 Encapsulation of best practice
 Avoids repetition of past mistakes.
 Provide continuity
 New staff can understand the organisation by understanding the
standards that are used.
 ISO 9001
 International set of standards that can be used as a basis for
developing quality management systems.
 Applies to organizations that design, develop and maintain
products, including software.
 Sets out general quality principles, describes quality processes
and lays out the organizational procedures that should be defined.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
26
Time to market [development]
 If there is competitive pressure or a short window of
opportunity for a system or product, development time
becomes important.
 This in turn leads to pressure to buy or otherwise re-use
existing elements.
 Time to market is often reduced by using prebuilt
elements such as commercial off-the-shelf (COTS)
products or elements re-used from previous projects.
 The ability to insert or deploy a subset of the system
depends on the decomposition of the system into
elements.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
27
Rollout schedule [development]
 If a product is to be introduced as base functionality
with many features released later, the flexibility and
customizability of the architecture are important.
 Particularly, the system must be constructed with ease of
expansion and contraction in mind.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
28
Cost and benefit [development]
 The development effort will naturally have a budget that
must not be exceeded.
 Different designs will yield different development costs.
 For instance, an implementation that relies on technology (or
expertise with a technology) not resident in the developing
organization will be more expensive to realize than one that
takes advantage of assets already inhouse.
 An implementation that is highly flexible will typically be more
costly to build than one that is rigid (although it will be less
costly to maintain and modify).
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
29
Projected lifetime of the system
[operational]
 If the system is intended to have a long lifetime,
modifiability, scalability, and portability become
important.
 But building in the additional infrastructure (such as a
layer to support portability) will usually compromise time
to market.
 On the other hand, a modifiable, extensible product is
more likely to survive longer in the marketplace,
extending its lifetime.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
30
Integration with legacy systems
[environmental]
 If the new system has to integrate with existing
systems, care must be taken to define appropriate
integration mechanisms.
 This property is clearly of marketing importance but has
substantial design implications.
 For example, the ability to integrate a legacy system with an
HTTP server to make it accessible from the Web has been a
marketing goal in many corporations over the past decade.
 The architectural constraints implied by this integration must
be analyzed.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
31
Targeted market [environmental]
 For general-purpose (mass-market) software, the
platforms on which a system runs as well as its feature
set will determine the size of the potential market.
 Thus, portability and functionality are key to market
share.
 To attack a large market with a collection of related
products, a product line approach should be
considered in which a core of the system is common
(frequently including provisions for portability) and
around which layers of software of increasing specificity
are constructed.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
32
External requirements
 Regulatory requirements
 Ethic requirements
 Legislative requirements
 Accounting legislative
 Safety/Security legislative
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
33
Non-functional requirements
implementation
 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 the system to minimize
communications between components.
 A single non-functional requirement, such as a security
requirement, may generate a number of related
functional requirements that define system services
that are required.
 It may also generate requirements that restrict existing
requirements.
34Chapter 4 Requirements engineering
Design for non-functional requirements
 Most commonly related to product requirements (nonfunctional
product qualities)
 Specific to each non-functional product attribute
 Tactics discussed later in the course.
 Design-time reliability/performance/… prediction
 Support of early design decisions based on the prediction of
non-functional product qualities early in system design.
 Commonly based on annotated UML Activity diagrams.
35Chapter 4 Requirements engineering
Key points
 We have discussed examples of product, operational
and external non-functional requirements.
 Specific attention has been paid to:
 Availability
 Reliability
 Safety
 Security
 Performance
 Modifiability
 Testability
 Usability
36Chapter 4 Requirements engineering
UML Activity Diagram
Lecture 3/Part 2
37© Clear View Training 2010 v2.6
© Clear View Training 2010 v2.6 38
What are activity diagrams?
 Activity diagrams are "OO flowcharts"
 They allow us to model a process
as a collection of nodes and edges
between those nodes
 Use activity diagrams to model
the behavior of:
 use cases
 classes
 interfaces, components
 collaborations
 operations and methods
 business processes
Authorization
Event
Authorization
RequestEvent
Enter PIN
Not authorizedAuthorized
[isAuthorized] [!isAuthorized]
Validate card
send
signal
accept
event
action
node
control flow
initial node
final node
activity
© Clear View Training 2010 v2.6 39
Activities
 Activities are networks of nodes connected by edges
 There are three categories of node:
 Action nodes – represent atomic units of work within the activity
 Control nodes - control the flow through the activity
 Object nodes - represent the flow of objects around the activity
 Edges represent flow through the activity
 There are two categories of edge:
 Control flows - represent the flow of control through the activity
 Object flows - represent the flow of objects through the activity
 What is the difference between an action and activity?
How can I recognize one from another in the diagram?
© Clear View Training 2010 v2.6 40
Activity diagram syntax
 Activities usually start in an
initial node and terminate in
a final node
 Activities can have
preconditions and
postconditions
 When an action node
finishes, it emits a token that
may traverse an edge to
trigger the next action
 This is sometimes known as
a transition
Address letter
Post letter
Write letter
action node
Send letter
control flow
activity
initial node
final node
precondition: know topic for letter
postcondition: letter sent to address
edge
«localPrecondition»
address is known
«localPostcondition»
letter is addressed
© Clear View Training 2010 v2.6 41
Activity diagram semantics
 The token game
 Token – an object, some data or a
focus of control
 Imagine tokens flowing around the
activity diagram
 Tokens traverse from a source
node to a target node via an
edge
 The source node, edge and target
node may all have constraints
controlling the movement of tokens
 All constraints must be satisfied
before the token can make the
traversal
Address letter
Post letter
Write letter
Send letter
imaginary flow of control token
«localPrecondition»
address is known
«localPostcondition»
letter is addressed
© Clear View Training 2010 v2.6 42
Action nodes
 Action nodes offer a token
on all of their output edges
when:
 There is a token
simultaneously on each
input edge
 The input tokens satisfy all
preconditions specified by
the node
 Action nodes:
 Perform an implicit fork on
their output edges when they
have finished executing
Action node
Action node
Action node
input token
output token
action node does
not execute
action node does
not execute
action node
executes
© Clear View Training 2010 v2.6 43
Decision and merge nodes
 A decision node is a control node
that has one input edge and two or
more alternate output edges
 Each edge out of the decision is
protected by a guard condition
 guard conditions must be mutually
exclusive
 The edge can be taken if and only if
the guard condition evaluates to true
 The keyword else specifies the path
that is taken if none of the guard
conditions are true
 A merge node allows through any of
several alternate flows
 It has two or more input edges and
exactly one output edge
Bin mailOpen mail
Get mail
[is junk]else
Process mail
keyword
guard
condition
decision
node
merge node
© Clear View Training 2010 v2.6 44
Fork and join nodes – concurrency
 Forks nodes model concurrent
flows of work
 Tokens on the single input edge are
replicated at the multiple output
edges
 Join nodes synchronize two or
more concurrent flows
 Joins have two or more incoming
edges and exactly one outgoing
edge
 A token is offered on the outgoing
edge when there are tokens on all
the incoming edges i.e. when the
concurrent flows of work have all
finished
Design new
product
Market
product
Manufacture
product
Sell
product
Product process
fork node
join node
© Clear View Training 2010 v2.6 45
Control nodes
Activity final node – terminates an activity
Flow final node – terminates a specific flow within an activity. The other
flows are unaffected
Initial node – indicates where the flow starts when an activity is invoked
Merge node – allows through any of its input edges
Fork node – splits the flow into multiple concurrent flows
Join node – synchronizes multiple concurrent flows
May optionally have a join specification to modify its semantics
Finalnodes
«decisionInput»
decision condition
Decision node– guard conditions on the output edges select one of them for
traversal
May optionally have inputs defined by a «decisionInput»
{join spec}
control node syntax control node semantics
Seeexamplesonnexttwoslides
Types of action node
end of month occurred
time
expression
event type
OrderEvent
wait 30 mins
Accept event action - waits for events detected by its owning object and
offers the event on its output edge.
Is enabled when it gets a token on its input edge.
If there is no input edge it starts when its containing activity starts and is
always enabled.
Accept time event action - waits for a set amount of time.
Generates time events according to it's time expression.
action node syntax action node semantics
Close Order
Call action - invokes an activity, a behavior or an operation.
The most common type of action node.
See next slide for details.
signal type
OrderEvent
Send signal action - sends a signal asynchronously.
The sender does not wait for confirmation of signal receipt.
It may accept input parameters to create the signal
© Clear View Training 2010 v2.6 46
© Clear View Training 2010 v2.6 47
Call action node syntax
Raise Order
call an activity
(note the rake icon)
Close Order call a behavior
call an
operation
getBalance():double
(Account::)
operation name
class name
(optional)
Get Balance
(Account::getBalance():double)
node name
operation name
(optional)
if self.balance <= 0:
self.status = INCREDIT
else
self.status = OVERDRAWN
programming
language
(e.g. Python)
 The most common type of
node
 Call action nodes may
invoke:
 an activity
 a behavior
 an operation
 They may contain code
fragments in a specific
programming language
 The keyword 'self' refers
to the context of the
activity that owns the
action
© Clear View Training 2010 v2.6 48
Sending signals and accepting events
 Signals represent information passed
asynchronously between objects
 This information is modelled as attributes
of a signal
 A signal is a classifier stereotyped
«signal»
 The accept event action asynchronously
accepts event triggers which may be
signals or other objects
Authorization
Event
Authorization
RequestEvent
Enter PIN
Not authorizedAuthorized
CardDetails
[isAuthorized] [!isAuthorized]
Validate card
send
signal
accept
event
PIN
CardDetails
«signal»
AuthorizationRequestEvent
pin : PIN
cardDetails : CardDetails
«signal»
AuthorizationEvent
isAuthorized : Boolean
«signal»
SecurityEvent
© Clear View Training 2010 v2.6 49
Object nodes
 Object nodes indicate that instances of a
particular classifier may be available
 If no classifier is specified, then the object
node can hold any type of instance
 Multiple tokens can reside in an object node
at the same time
 The upper bound defines the maximum
number of tokens (infinity is the default)
 Tokens are presented to the single output
edge according to an ordering:
 FIFO – first in, first out (the default)
 LIFO – last in, first out
 Modeler defined – a selection criterion is
specified for the object node
OrderEvent
Orderobject
node
object
flow
object
node for
signal
classifier name
or node name
© Clear View Training 2010 v2.6 50
Object node syntax
 Object nodes have a
flexible syntax. You
may show:
 upper bounds
 ordering
 sets of objects
 selection criteria
 object in state
Order
Set of Order
Order
[open]
Order«selection»
monthRaised = "Dec"
order objects may be available
sets of Order objects may be available
select Order objects in the open state
Order objects raised in December may be
available
Order
{upperBound = 12}
zero to 12 Order objects may be available
Order
{ordering = LIFO}
last Order object in is the first out
(FIFO is the default)
© Clear View Training 2010 v2.6 51
Activity parameters and partitioning
 Object nodes can provide input and output parameters to activities
 Input parameters have one or more output object flows into the activity
 Output parameters have one or more input object flows out of the activity
 Draw the object node overlapping the activity boundary
Design bespoke
product
Manufacture
product
Accept
payment
Deliver
product
Marketing Manufacturing Delivery
Order
[paid]
CustomerRequest
Set of
BusinessConstraint
Order
[delivered]
Bespoke product process
Order
input parameter
output
parameter
object flow
object in state
ProductSpecification
© Clear View Training 2010 v2.6 52
Activity partitions
Location
Marketing Development
Create course
business case
Develop course
Scheduling
Book trainers
Book roomsMarket course
Course production
dimension name
activity partition
Schedule
course
Zurich London
 Each activity partition represents
a high-level grouping of a set of
related actions
 Partitions can be hierarchical
 Partitions can be vertical,
horizontal or both
 Partitions can refer to many
different things e.g. business
organisations, classes,
components and so on
 If partitions can’t be shown
clearly using parallel lines, put
their name in brackets directly
above the name of the activities
(London::Marketing)
Market product
(p1, p2)
SomeAction
multiple partitionsnested partitions
© Clear View Training 2010 v2.6 53
«create»
addCourse( “UML” )
[add] [remove]
Interaction overview diagrams
 Model the high
level flow of
control between
interactions
 Show interactions
and interaction
occurrences
 Have activity
diagram syntax
sd ref
GetCourseOption
sd ref
RemoveCourse
sd ref
FindCourse
:Registrar
:RegistrationManager
uml:Course
sd AddCourse
sd ref
Logon
[find]
sd ManageCourses lifelines :Registrar, :RegistrationUI, :Course
[exit]
else
inline interaction
interaction use
© Clear View Training 2010 v2.6 54
Key points
 Activity diagrams can model flows of activities using:
 Activities and connectors
 Activity partitions
 Action nodes
• Call action node
• Send signal/accept event action node
• Accept time event action node
 Control nodes
• Decision and merge
• Fork and join
 Object nodes
• Input and output parameters
• Pins
 Interaction overview diagrams as their advanced feature