Here are some key difficulties in specifying non-functional requirements: 1. Imprecision - Non-functional requirements are often imprecisely specified since they can be difficult to quantify. Terms like "easy to use" or "high performance" don't have clear definitions. 2. Prioritization - It can be challenging to determine which non-functional requirements are most important since they may conflict with each other (e.g. performance vs reliability). 3. Verification - Unlike functional requirements, non-functional requirements are sometimes hard to test and verify objectively since they deal with overall system attributes rather than specific behaviors. 4. Understanding - Stakeholders don't always fully understand non-functional concerns like maintainability

1. – Software Requirements –
Descriptions and specifications of a system
Objectives:
q To introduce the concepts of user and system
requirements
q To describe functional / non-functional requirements
q To explain two techniques for describing system
requirements
q To explain how software requirements may be
organised in a requirements document

2. Key Points
Functional and non-functional requirements
User requirements
System requirements
The software requirements document

3. What is Requirement
Engineering

4. Requirements engineering
Requirements engineering is the process of establishing
q the services that the customer requires from a system
q the constraints under which it operates and is developed
Requirements The descriptions of the system
services and constraints
that are generated during the
requirements engineering process

5. Definition of RE

6. What are Requirements?

7. What is a requirement?
• It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification
• This is inevitable as requirements may serve a
dual function
– May be the basis for a bid for a contract - therefore must be
open to interpretation
– May be the basis for the contract itself - therefore must be
defined in detail
– Both these statements may be called requirements

8. What are requirements?
Application Domain Machine Domain
C - computers
D - domain properties
R - requirements P - programs
• Domain Properties:
– things in the application domain that are true whether or not we ever
build the proposed system
• Requirements:
– things in the application domain that we wish to be made true by
delivering the proposed system
•Many of which will involve phenomena the machine has no access to
• A Specification:
– is a description of the behaviours that the program must have in order to
meet the requirements

9. What are Requirements?
• Two basic principles of requirements engineering:
– Separate the problem from the solution
– Problems and solutions intertwine with one another
• Describing problems:
– Application Domains vs. Machine Domains
– Verification vs. Validation
• Systems Engineering
– Systems vs. software
• Patterns and Types of Problem
– Requirements patterns
– Problem Frames

10. Separate the problem from the
solution
• A separate problem Problem
description is useful: Situation
– Most obvious problem
might not the right one to
solve
Validation
– Problem statement can be Problem
Correspondence
Verification
discussed with Statement
Correctness
stakeholders
– Problem statement can be
used to evaluate design
choices
– Problem statement is a Implementation
source of good test cases Statement
• Still need to check:
– Solution correctly solves
the stated problem
– Problem statement System
corresponds to the needs
of the stakeholders

11. Fitness for purpose?
• Two correctness (verification) criteria:
– The Program running on a particular Computer
satisfies the Specification
– The Specification, in the context of the given domain
properties, satisfies the requirements
• Two completeness (validation) criteria:
– We discovered all the important requirements
– We discovered all the relevant domain properties

12. Example
• Requirement R
– “The database shall only be accessible by authorized
personnel”
• Domain Properties D:
– Authorized personnel have passwords
– Passwords are never shared with non-authorized
personnel
• Specification S:
– Access to the database shall only be granted after the
user types an authorized password.
• S + D entail R

13. But we can also move the
boundaries…
• E.g. Elevator control system:
people waiting
Elevator call buttons Scheduling algorithm
people in the elevator Floor request buttons
people wanting to go to button lights
a particular floor Current floor indicators Control program
Motor on/off
Elevator motors
Door open/close
Safety rules
We can shift things around:
E.g. Add some sensors to detect when people are waiting
This changes the nature of the problem to be solved

14. What do Requirements
Engineers do?

15. What do Requirements Engineers
do?
• Some notion that there is a “problem” that
needs solving
– dissatisfaction with the current state of affairs
– a new business opportunity
– a potential saving of cost, time, resource usage,
etc.
• Requirements Engineer is an agent of change

16. The requirements engineer
must:

17. The requirements engineer must:
• Identify the “problem”/”opportunity”
• Which problem needs to be solved? (identify problem
Boundaries)
• Where is the problem? (understand the Context/Problem
Domain)
• Whose problem is it? (identify Stakeholders)
• Why does it need solving? (identify the stakeholders’
Goals)
• How might a software system help? (collect some
Scenarios)
• When does it need solving? (identify Development
Constraints)
• What might prevent us solving it? (identify Feasibility
and Risk)
• And become an expert in the problem domain

18. Types of requirement

19. Types of requirement
• User requirements
• System requirements
• Domain requirements
• Functional requirements
• Non-functional requirements

20. Types of requirement
• User requirements
– Statements in natural language plus diagrams of the
services the system provides and its operational constraints.
Written for customers
• System requirements
– A structured document setting out detailed descriptions of
the system services. Written as a contract between client
and contractor
• Software specification
– A detailed software description which can serve as a basis
for a design or implementation. Written for developers

21. Functional and non-functional
requirements
• Domain requirements
– Requirements that come from the application domain of
the system and that reflect characteristics of that
domain
• 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.
• Non-functional requirements
– constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.

22. What are User requirements

23. User requirements
• Should describe functional and non-
functional requirements so that they are
understandable by system users who don’t
have detailed technical knowledge
• User requirements are defined using natural
language, tables and diagrams

24. What are System requirements

25. System requirements
– More detailed specifications of user requirements
• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed using
system models

26. What are Domain requirements

27. Domain requirements
• Derived from the application domain and
describe system characteristics and features
that reflect the domain
• May be new functional requirements, constraints
on existing requirements or define specific
computations
• If domain requirements are not satisfied, the
system may be unworkable

28. What are Domain requirements
problems

29. Domain requirements problems
• Understandability
– Requirements are expressed in the language of the
application domain
– This is often not understood by software engineers
developing the system
• Implicitness
– Domain specialists understand the area so well that they
do not think of making the domain requirements explicit

30. What is Functional Requirement

31. Functional Requirements
Describe functionality or system services
• Depend on the type of software, expected users
and the type of system where the software is used
• Functional user requirements may be high-
level statements of what the system should do
BUT functional system requirements should
describe the system services in detail

32. The LIBSYS system
• A library system that provides a single interface to
a number of databases of articles in different
libraries.
• Users can search for, download and print these
articles for personal study.

33. Examples of functional
requirements

34. Examples of functional
requirements
• The user shall be able to search either all of the
initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for
the user to read documents in the document store.
• Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.

35. Requirements imprecision
• Problems arise when requirements are not
precisely stated
• Ambiguous requirements may be interpreted
in different ways by developers and users
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer for each
different document type
– Developer interpretation - Provide a text viewer that
shows the contents of the document

36. Requirements completeness and
consistency
• In principle requirements should be both
complete and consistent
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 practice, it is very difficult or impossible to
produce a complete and consistent requirements
document

37. Types of Non-functional requirement

38. Non-functional requirement types
Non-functional
requirements
Product Organizational External
requirements requirements requirements
Efficiency Reliability Portability Interoperability Ethical
requirements requirements requirements requirements requirements
Usability Delivery Implementation Standards Legislative
requirements requirements requirements requirements requirements
Performance Space Privacy Safety
requirements requirements requirements requirements

39. Non-functional requirements
• Define 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. If these
are not met, the system is useless

40. Non-functional classifications
• Product requirements
– Requirements which specify that the delivered product
must behave in a particular way 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.

41. Non-functional requirements
examples
• Product requirement
– 4.C.8 It shall be possible for all necessary communication
between the APSE and the user to be expressed in the
standard Ada character set
• Organisational requirement
– 9.3.2 The system development process and deliverable
documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95
• External requirement
– 7.6.5 The system shall not disclose any personal
information about customers apart from their name and
reference number to the operators of the system

42. Goals and requirements
• Non-functional requirements may be very
difficult to state precisely and imprecise
requirements may be difficult to verify.
• Goal
– A general intention of the user such as ease of use
• Verifiable non-functional requirement
– A statement using some measure that can be
objectively tested
• Goals are helpful to developers as they convey
the intentions of the system users

43. Examples
• A system goal
– The system should be easy to use by experienced
controllers and should be organised in such a way that user
errors are minimised.
• A verifiable non-functional requirement
– Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this
training, the average number of errors made by
experienced users shall not exceed two per day.

44. Features of Non-Functional Requirements
1. Non-Functional requirements mostly define
the overall attributes of the “resulting”
system
– Most of the time these turn out to be
“constraints” on how the (functional)
requirements are to be met.
• (e.g.) Response time must be .xyz second per screen
– Sometimes the functional requirements may have
to be “sacrificed or increased” in order to meet
the non-functional requirements
• (e.g.) in order to satisfy security requirements, we can
not let everyone access the system --- sacrificing some
flexibility
• (e.g.) in order to satisfy the reliability requirements, we
may add a duplicative functionality to provide another
path to achieve the desired result

45. Features of Non-Functional
Requirements
1. Some non-functional requirements
may not address the attributes of the
resulting system (product), but
something else
– (e.g.) the system must be developed with
a very risk averse process such as Spiral
or the system must be developed with
Visual Basic language

46. IEEE Standard 830 – 1993
• List of 13 non-functional requirements:
1. Performance
2. Interface
3. Operational
4. Resource Examples?
5. Verification
6. Acceptance
7. Documentation
8. Security
9. Portability
10. Quality
11. Reliability
12. Maintainability
13. Safety
Some of these also overlap - - - - - -

47. IEEE Standard 830 – 1993
• List of 13 non-functional requirements Examples:
– Performance: 100 transactions per minute
– Interface: capable of importing data with EDI format
– Operational: must not require more than 1 megabyte of main memory
– Resource: will use wireless encryption algorithm that is “better” than WEP
– Verification: all data updates must be traceable
– Acceptance: must pass a user defined system test bucket
– Documentation: user manual is needed for novice users only
– Security: user request to access any data must be authorized first
– Portability: the system must operate with “any” relational db systems
– Quality: the system must install with zero defect
– Reliability: the system must be accessible 99.9 % of the time
– Maintainability: the system must be modifiable (e.g. designed with exits)
– Safety: the system must not perform “chemical material discard” functions without
“explicit” user authorization.
There may be others that are important such as meeting legal standards that
Is not mentioned in this list

48. Sommerville’s Classification of
Non-Functional Requirements
Process Product External
Oriented Related Directed
Delivery/Updates Usability Legal rules
Implementation Reliability Economics
Process standards Safety Interoperability
Efficiency
Performance
Capacity

49. These are constraints placed on various activities
related to the development and delivery of the
software product.
For example:
Process 1.The development organization must be CMM
Oriented level 3 or above.
2. The system must use some specific tool.
3. There must be a disaster recovery plan for the
system
Delivery/Updates 4. There must be an agreed to product delivery plan
Implementation
Process standards
Why do we have these requirements?
Large organizations such as fortune 500
companies or government agencies are
experienced with quality, maintenance, and
delivery problems from past. These requirements
are meant to minimize those problems.

50. These are constraints which specify the desired “attributes”
that the system must possess.
Note:
- Some can be specified quantitatively and precisely;
others are difficult to quantify and are informally
specified.
Product - Sometimes these requirements may be mutually conflicting
Related (e.g. reliability versus efficiency)
Examples:
Usability 1.The system must process 100 transactions per minute
2. The system must not require 1 meg of main memory
3. The mean time between failure must be 3 months
Reliability 4. The average user learning time must be less than 1 day
5. The system must be available 99.99% of time
Safety
Efficiency
Why do we have these requirements?
Performance Many organizations have critical needs; Aviation or
Health Systems may have safety, reliability, and
Capacity performance needs beyond the normal processing
environment

51. These are constraints which may be placed on
both the product and/or process.
For example:
Externally
Directed 1.The system must abide to HIPAA (Health Insurance
Portability and Accountability Act) privacy rules
2. The system must meet European Sales Tax laws
3. The system must use Automotive EDI for B2B
Legal rules e-commerce
Economics
Interoperability
Why do we have these requirements?
Many countries have specific financial laws, privacy
protection laws, etc. that the system must abide to.
Some industries have their own business rules
to conduct commerce.

52. Difficulties in Specifying
Non-functional Requirements

53. Difficulties in Specifying
Non-functional Requirements
• The difficulties in gathering Non-Functional Requirements may be
attributed to many reasons - - - - - mostly because people tend to focus on
the functions and services that they need:
– Certain non-functional requirements are sometimes hard to quantify and
therefore hard to express without some “trial and error prototyping”.
• e.g. : usability
– Certain non-functional requirements are hard to differentiate between
functional and non-functional
• e.g. security
– Certain non-functional requirements are difficult to specify because they can
not be well understood or validated until much later
• e.g. reliability or quality
– Certain non-functional requirements may be conflicting
similar
• e.g. performance .vs. security .vs. reliability
– Certain non-functional requirements may be difficult to express and validate;
may require more refinements
• e.g. when to stop prototyping usability if the users do not clearly signal satisfaction

54. What are“Critical” Systems

55. “Critical” Systems
• Critical systems are systems whose failure causes
significant economic, human or organizational
damage:
– Business Critical System
• e-commerce systems such as stock trading, reservations, etc.
– Mission Critical System
• Aircraft control, manufacturing process control, etc.
– Safety (life) Critical system
• Medical Device control, hazardous materials management, etc.

56. Requirements for System Criticality

57. Requirements for System Criticality
• Most of the requirements for these “business,” “mission,”
and “safety” criticality deals with non-functional
requirements of the a) “complete” system, not just software
and b) may be expressed in general ways that need to be
decomposed further:
– Performance
– Reliability
– Security
– Usability
– Safety
Again, these may be “conflicting” - - - - so what do you do?
Must prioritize the requirements, especially when there are conflicts

58. Performance Related Requirements

59. Performance Related Requirements
• These requirements mostly addresses the
constraints of speed and sometimes capacity:
– System Response time to end-user such as 1 second
response to user requests
– System throughput such as # of transactions per minute
(time interval)
– System timing such as collection of data and responding
to it within sub-second for real-time system.
– System capacity such as number of simultaneous users
that may access an application (instantaneous time)
These should be specified quantitatively.

60. Reliability Related Requirements

61. Reliability Related Requirements
• These requirements addresses constraints on run-time
behavior of the system:
– System Availability such as the system is up certain percentage of
the time.
– System Failure rate such as average mean time between system
failures to deliver the user service.
These should also be specified quantitatively.

62. Security Related Requirements

63. Security Related Requirements
• These requirements addresses the issues related to
unauthorized access: to the system, to specific function, to
data:
– System Access protection such as firewall requirement
– Application Functional Access & Usage protection such as
authorization and authentication requirement
– Data Access and Usage protection such as authorization and
encryption requirement
Security is also an important factor for other requirement such
as safety. A little hard to specify these quantitatively.

64. Usability Related Requirements

65. Usability Related Requirements
• These requirements addresses the user interface looks and user inter-
actions with the system
– Entry and beginners-level knowledge assumption to use the system
– Learning time and experience needed such as hours or number of lessons to
learn the system
– Handling and usage such as time to complete certain tasks or number of
errors made before completing certain tasks
– Likeness and delight experienced from using the system such as availability of
context sensitive help text or “re-do” capability
Some of these requirements can be and should be specified
Quantitatively; delight and likeness are a bit hard to define.

66. Safety Critical System Requirements

67. Requirements measures

68. Safety Critical System Requirements
• These requirements addresses everything with the
safety of the system and of the usage of the system.
• These requirements deal mostly with the “shall not”
requirements such as:
– The system shall not allow - - - -
– The system will not operate without - - -
Note that safety may be dependent on many of the other requirements:
- insecure system may be open to malicious danger
- unreliable system may fail unpredictably and hurt someone
- non-responsive system may miss critical data and damage something
- difficult to use system may create a critical human error

69. Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use T raining time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness T ime to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

70. Relationship Between Requirement
and Design

71. Requirements and design
• 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
inseparable
– 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

72. Non-functional Requirements

73. Objectives
• To introduce non-functional requirements
• To explain the schemes used to classify non-
functional requirements
• To illustrate various derivation techniques for
non-functional requirements
• To demonstrate the importance of non-
functional requirements in critical systems

74. Non-functional requirements (NFR)
• Non-functional requirements define the overall
qualities or attributes of the resulting system
• Non-functional requirements place restrictions
on the product being developed, the
development process, and specify external
constraints that the product must meet.
• Examples of NFR include safety, security,
usability, reliability and performance
requirements.

75. Functional and Non-functional
requirements
• There is no a clear distinction between
functional and non-functional requirements.
• Whether or not a requirement is expressed as a
functional or a non-functional requirement
may depend:
– on the level of detail to be included in the
requirements document
– the degree of trust which exists between a system
customer and a system developer.

76. Example
• The system shall ensure that data is protected
from unauthorised access.
– Conventionally, this would be considered as a non-
functional requirement because it does not specify
specific system functionality which must be
provided. However, it could have been specified in
slightly more detail as follows:
• The system shall include a user authorisation
procedure where users must identify themselves
using a login name and password. Only users who
are authorised in this way may access the system

77. Types of Non-functional
requirements
• The ‘IEEE-Std 830 - 1993’ lists 13 non-
functional requirements to be included in a
Software Requirements Document.
– Performance requirements
– Interface requirements
– Operational requirements
– Resource requirements
– Verification requirements
– Acceptance requirements

78. Types of NFRs (contd.)
– Documentation requirements
– Security requirements
– Portability requirements
– Quality requirements
– Reliability requirements
– Maintainability requirements
– Safety requirements

79. Classification of NFRs
• NFRs may be classified n terms of qualities
that a software must exhibit (Boehm)
• A more general classification distinguishes
between product, process and external
requirements

80. Classification of NFRs (contd.)
Nt a
oc l
ni
- o
f n
un
ri e
em
q n
u t
r s
e
P
rs
oc
es Ptq e
r cu n
or i t
d r s
u e
em El
x
ta
er
n
ri e
em
q n
u t
r s
e ri e
em
q n
u t
r s
e
U ri e
si e m
a q n
b u t
i
lt
yr s
e
Dey
lr
i
ve Le
g
al
ri e
em
q n
u t
r s
e Rte m
el ri e
li q n
ii u t
abyr s
e ca
oi
nt
s s
tn
r
i leo
ma
pn
et n
m ti Sr i e
a em
f q n
eu t
t
yr s
e Ei
c c
o
nom
ri e
em
q n
u t
r s
e ca
oi
nt
s s
tn
r
sa
t r
ad
n
ds Ec u n
fer i e
f nq t
i yr s
c em
i e
Ir rl
nei
tp t
ea
oiby
ri e
em
q n
u t
r s
e ri e
em
q n
u t
r s
e
P ae m
e nq e
r cu n
f ei t
o rr s
r
m e
C ri e
ay r n
p em
a q t
c u s
i
t e

81. Product requirements
• Specify the desired characteristics that a
system or subsystem must possess.
• Most NFRs are concerned with specifying
constraints on the behaviour of the executing
system.

82. Specifying product requirements
• Some product requirements can be formulated
precisely, and thus easily quantified
– Performance
– Capacity
• Others are more difficult to quantify and,
consequently, are often stated informally
– Usability

83. Examples of product requirements
• The System service X shall have an
availability of 999/1000 or 99%. This is a
reliability requirement which means that out of
every 1000 requests for this service, 999 must
be satisfied.
• System Y shall process a minimum of 8
transactions per second. This is a performance
requirement.
• The executable code of System Z shall be
limited to 512Kbytes. This is a space

84. Source code requirements
• There are product requirements which relate to
the source code of the system
• Examples
– The system shall be developed for PC and
Macintosh platforms. This is a portability
requirement which affects the way in which the
system may be designed
– The system must encrypt all external
communications using the RSA algorithm. This is
a security requirement which specifies that a
specific algorithm must be used in the product

85. Conflicts in product requirements
• Product requirements are often conflict. For
example:
– A requirement for a certain level of performance
may be contradicted by reliability and security
requirements which use processor capacity to carry
out dynamic system checking
– A requirement on the space utilisation of the system
may be contradicted by another requirement which
specifies that a standard compiler which does not
generate compact code must be used
• The process of arriving at a trade-off in these

86. Process requirements
• Process requirements are constraints placed
upon the development process of the system
• Process requirements include:
– Requirements on development standards and
methods which must be followed
– CASE tools which should be used
– The management reports which must be provided

87. Examples of process requirements
• The development process to be used must be explicitly
defined and must be conformant with ISO 9000 standards
• The system must be developed using the XYZ suite of
CASE tools
• Management reports setting out the effort expended on
each identified system component must be produced every
two weeks
• A disaster recovery plan for the system development must
be specified

88. External requirements
• May be placed on both the product and the
process
• Derived from the environment in which the
system is developed
• External requirements are based on:
– application domain information
– organisational considerations
– the need for the system to work with other systems
– health and safety or data protection regulations
– or even basic natural laws such as the laws of

89. Examples of external requirements
• Medical data system The organisation’s data protection
officer must certify that all data is maintained according to
data protection legislation before the system is put into
operation.
• Train protection system The time required to bring the
train to a complete halt is computed using the following
function:
The deceleration of the train shall be taken as:
γtrain = γcontrol + γgradient
where:

90. External requirement example
(contd.)
γgradient = 9.81 ms-2 * compensated gradient / alpha
and where the values of 9.81 ms-2/ alpha are
known for the different types of train.
γcontrol is initialised at 0.8 ms-2 - this value being
parameterised in order to remain adjustable. The
illustrates an example of the train’s
deceleration by using the parabolas derived
from the above formula where there is a change
in gradient before the (predicted) stopping point
of the train.

91. External requirement example
(contd.)
S p eed of rain at change of gradient
S p eed of train on ap p lication of b rakes
V
γ = γ control+ γ gradient1
γ = γ control+ γ gradient2
Distance
Front of train C hange of gradient

92. External requirement example
(contd.)
• The first of the the requirements described comes from
the need for the system to conform to data protection
legislation
• The second comes from the application domain and is a
specification of the physical braking characteristics of a
train.
• External requirements rarely have the form “the system
shall...” or ‘the system shall not...”. Rather, they are
descriptions of the system’s environment which must be
taken into account.

93. Deriving NFRs
• NFRs are difficult to express
• A number of important issues contribute to the problem of
expressing non-functional requirements:
– Certain constraints are related to the design solution
that is unknown at the requirements stage
– Certain constraints, are highly subjective and can
only be determined through complex empirical
evaluations
– Non-functional requirements tend to be related to
one or more functional requirements
– Non-functional requirements tend to conflict and

94. Stakeholder concerns
• Stakeholders normally have a number of
‘concerns’
• Concerns are typically non-functional
• Examples include:
– Critical business objectives
– Essential system characteristics (e.g. security)
– Safety, performance, functionality and
maintainability
• Vaguely defined user concerns may be related
to NFRs

95. Relationships between user needs,
concerns and NFRs
User’s need User’s concern Non-functional
requirement
Function 1. Ease of use 1. Usability
2. Unauthorised access 2. Security
3. Likelihood of failure 3. Reliability
Performance 1. Resource utilisation 1. Efficiency
2. Performance verification 2. Verifiability
3. Ease of interfacing 3. Interoperability
Change 1. Ease of repair 1. Maintainability
2. Ease of change 2. Flexibility
3. Ease of transport ? 3. Portability
4. Ease of expanding or upgrading capacity 4. Expandability
or performance ?

96. Concerns
• A way of expressing critical ‘holistic’
requirements
• Concerns may be broken down into sub-
concerns and finally into specific questions
• Questions act as a check list to ensure that
specific requirements do not conflict with
global priorities

97. Concern decomposition
S
a
f
et
y Ci
ob
m
py
a
tt
il
i
Pl
e
rs
on
a Se
o
f
tw
a
r P
h
y
si
c
al
C
o
ln
l
i
si
o Dt
ee
r n
a
il
m H
ae
rr
d
wa
an
ct
ci
d
e
En T
x
e
cu
t
io i g If
m n
i
n tc
e
r
ae
Ee
xp
c e
e d
ss
s
Tm
rd
a a
c g
k e
a E e
n n
v t
im
r
o
n
f ans
o ci
r kt
t on
r d
c i
o
Wt a
h ri b
a mu
to n
i a o
n ot
f Wm
i ri ee
l e nt
lq t c
ar a
u f
e f
Sme
y ub
s s l
t
e ta
m bt
eo
tkgqb
rd i uy
am i
c ar r
a s e
eed t e af
ho ee
e r ch
p n
rfm ot
d n ds
e de
t aoe
e ax
c vc
t i s
ts ? i i
h mt
e
y Hs
s o
t
e wsh e ga
xs r
i o?
s fe
t t
i w
n
s
p
ee
d
pd
re
o
v
i?
d
Du te
o qe d
e i n
s r n
a e e
r m
e
Smt tt e
y uc h d
s s ue
te t
m e r
e i
x nu
e st
Ut d
n a is
d ci
e on
rwt
h o
n d t' v
a ia l
ta a
as i e
t nl
ht ab
At en
d u ve
a in n
e or t
xn m
ec i
o
cc eu
ae es
ns d
esc
xp e
s a tu Ha
h t Sf
rh Tc
o e ir ?
gh nt e
e
de
en
r t
a?
i
l
m
Wc ee r y
hse eae
a ' s d ia
te s ' nl
does m i
xp n?
t Cu b
a ft e
nn
t c
h i
i
s o
n
p den
r e ht
oo x
vn i
i
dt s
e g
eien
xno ?
e n e
c vn
u im
tor t

98. Goal-based derivation
• Relates non-functional requirements to the
goals of the enterprise
• Goal-based NFR derivation is a 3 step
approach:
– Identify the enterprise goal
– Decompose of the goal into sub-goals
– Identify non-functional requirements.

99. Example of goal-based derivation
Go al IS - g o al
motivates The system should perform in
Visualise air traffic scenarios
real-time
OM
motivates
IS - NFR IS - NFR
Display radar data The display must accommodate
in real-time all data from the scenario
motivates
motivates
IS - NFR
Aircraft position should be displayed in less
than 3/16 sec of the radar sweep period
IS - NFR IS - NFR IS - NFR IS - NFR
Display 100 tracks Display 100 Display 200 vectors Display 500 table
meteorological plots symbols

100. Testable NFRs
• Stakeholders may have vague goals which
cannot be expressed precisely
• Vague and imprecise ‘requirements’ are
problematic
• NFRs should satisfy two attributes
– Must be objective
– Must be testable (Use measurable metrics)
• It is not always possible to express NFRs
objectively

101. Examples of measurable metrics
for NFRs
Property Metric
P erfo rm an ce 1 . P ro cessed tran sactio n s p er seco n d
2 . R esp o n se tim e to u ser in p u t
R eliab ility 1 . R ate o f o ccu rren ce o f failu re
2 . M ean tim e to failu re
A v ailab ility P ro b ab ility o f failu re o n d em an d
S ize K b y tes
U sab ility 1 . T im e tak en to learn 8 0 % o f th e facilities
2 . N u m b er o f erro rs m ad e b y u sers in a g iv en tim e
p erio d
R o b u stn ess T im e to restart after sy stem failu re
P o rtab ility N u m b er o f targ et sy stem s

102. Requirements for critical systems
• Systems whose ‘failure’ causes significant
economic, physical or human damage to
organisations or people.
• There are three principal types of critical
system:
– Business critical systems
– Mission critical systems
– Safety critical systems

103. NFRs for critical systems
• The principal non-functional constraints which
are relevant to critical systems:
– Reliability
– Performance
– Security
– Usability
– Safety

104. Reliability
• Constraints on the run-time behaviour of the
system
• Can be considered under two separate
headings:
• Availability - is the system available for service
when requested by end-users.
• Failure rate - how often does the system fail to
deliver the service expected by end-users.

105. Performance
• Constrain the speed of operation of a system
• Types of performance requirements:
• Response requirements
• Throughput requirements
• Timing requirements

106. Security
• Security requirements are included in a system to ensure:
– Unauthorised access to the system and its data is not
allowed
– Ensure the integrity of the system from accidental
or malicious damage
• Examples of security requirements are:
– The access permissions for system data may only be
changed by the system’s data administrator
– All system data must be backed up every 24 hours
and the backup copies stored in a secure location
which is not in the same building as the system

107. Usability
• Concerned with specifying the user interface
and end-user interactions with the system
• Well structured user manuals, informative error
messages, help facilities and consistent
interfaces enhance usability

108. Usability metrics
• Measurable attributes of usability requirements include:
– Entry requirements Measured in terms of years of
experience with class of applications or simply age
– Learning requirements Denotes the time needed to
learn the facilities of the system. This could be
measured in terms of speed of learning, say hours
of training required before independent use is
possible
– Handling requirements Denotes the error rate of
the end-users of the system. This could be
measured in terms of the errors made when

109. COQUAMO approach to measuring
usability
• Provides an automated support facility for
setting and measuring usability
• Provides a set of ‘templates’ which have to be
filled in

110. COQUAMO usability template
Ci
lf o
at
s n
s
ii
c
a G l-li en
eq a td t
na p nd
e i p p
r t
a yion
lu c e
a e
Lu
e i
v r
e e
l
r d
e
q H
i
g
h
Adi
st u
sel
oqs
c a
i
a i t
e
sy
ys
no
nm l a o i se s
ei p yrl s
ai e , rn
rl rt e d
n, a u i
bt
yb f n
i
l i e
rdp
ect
l o
ac
t n
ee su ny
nd
da
e b
r i
s l
t i
at
D
en
fi
io
n
i1
t ei h r l t em
ah un os
s w crue
e i s e st
w e a s
t cs n y
ha
E1
xn
p .
lo1
s
io aef e l ssa llcte
vi ofafrc e o c
e m i s u hv mi
rt rc s e i e p w
a e ic ot e o e t
g s ce
p oe f e h
v n
s
y
st
em
Mu
em
a ns
set
u n
rt e
e i d
ay
s
mt a c rfs e f e
e g t us od o y
a os
s oo u r nt s
u /
r d r v auu
i
n a e eyml r
rs v
s
M co edt
em i
a nt
se d
u o sn u k
rt i
e n n wi e
g n
rt a
aae
n rr r i
ue f s
m dt 0
b i os
e ee
rq t 2
u
W
oe
rs
tc
a
s 8
Pe
lel
av
ne
nd
l 4
B
ee
s
tc
as 2
Cv
ue
r e
r l
e
nt
l 1
0
Ja
ui
st
t o
i n
f
i
c i ot cy t y
m si r s X
pe ile d Z
r nf q b
v pl u
e e
mc e Y
a e
C ci
on l
n eu c
s oe o
e f r
q f
u a
e s
t

111. Safety
• No consensus in the system’s engineering
community about what is meant by the term
‘safety requirement’
– Sometimes considered to be all requirements
(functional and non-functional) on safety-related
systems
– Sometimes the sub-set of these requirements which
are directly related to ensuring safe operation and
sometimes requirements on protection systems
which are designed to protect against accident
• Usage of the term often depends on the culture

112. Safety requirement definition
• Informal definition:
Safety requirements are the ‘shall not’
requirements which exclude unsafe situations
from the possible solution space of the system

113. Examples of safety requirements
• The system shall not permit operation unless
the operator guard is in place
• The system shall not allow the sedative dose
delivered to the patient to be greater than the
maximum value which is determined by the
patient’s physician
• The system shall not operate if the external
temperature is below 4 degrees Celsius

114. Requirements engineering for
safety-related systems
• The requirements engineering process for
safety-related systems should incorporate a
specific safety-analysis activity
• The widely accepted model of the system
critical systems life cycle (BCS and IEE 1989)
identifies two stages in the safety analysis
process:
– Safety requirements discovery
– Safety validation

115. Hazard analysis
• As part of the process of safety analysis, there
are various activities such as hazard
identification and analysis
• Various methods such as fault-tree analysis
and Petri net analysis have been developed for
safety validation

116. Integrating safety analysis with RE
• We illustrate in the following sections a simple
technique for integrating safety analysis with a
requirements engineering method
• The technique is intended to support the
process of requirements discovery (safety
requirements) and validation

117. Integrating safety analysis with RE
(contd.)
• The starting point for specifying the system is
a set of abstract organisational needs and
constraints
• It is important that the approach used
incorporates a systematic approach to dealing
safety issues. These include:
– Identifying hazards, risks and risk criteria
– Identifying the necessary risk reduction to meet the
risk criteria
– Defining the overall safety requirements

118. Integrating safety analysis with RE
(contd.)
• The requirements process, shown in , has been
extended to incorporate an explicit safety
analysis activity
• The safety analysis process is based on
requirements information drawn from the
requirements elicitation and documentation
process
• A set of abstract safety requirements serves as
a reference model for identifying initial safety
considerations or concerns

119. Integrating safety analysis with RE
(contd.)
• The safety analysis process includes:
– The identification of safety considerations
– Hazard identification
– Hazard analysis
– Risk analysis and derivation of safety requirements
• Proposed safety requirements are analysed
together with other system requirements to
ensure that safety is not compromised

120. Integrating safety analysis with RE
(contd.)
Abstract requirements Requirements
process
Elicit Analyse Document Validate
requirement requirements requirements requirements
s
Requirements
document
Identify Identify Analyse
safety hazards hazards
consideratio
ns
Abstract safety Risk Suggested safety
requirements assessment requirements Safety
analysis

121. Key points
• Non-functional requirements define the overall qualities or
attributes of the resulting system
• Non-functional requirements may be classified into three
main types; product, process and external requirements
• Product requirements specify the desired characteristics
that the system or subsystem must posses
• Non-functional requirements tend to conflict and interact with
other system requirements
• The principal non-functional constraints which are relevant to
critical systems are reliability, performance, security, usability
and safety

122. How to write requirements:

123. Guidelines for writing requirements
• 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 !!!

124. Problems with natural language

125. Problems with natural language
• Lack of clarity
– Precision is difficult without making the document difficult
to read
• Requirements confusion
– Functional and non-functional requirements tend to be
mixed-up
• Requirements combination
– Several different requirements may be expressed together

126. Alternatives to NL specification

127. Alternatives to NL specification
Notation Description
Structured This approach depends on defining standard forms or
natural templates to express the requirements specification.
language
Design This approach uses a language like a programming
description language but with more abstract features to specify the
languages requirements by defining an operational model of the
system.
Graphical A graphical language, supplemented by text annotations is
notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT
(Ross, 1977; Schoman and Ross, 1977). More recently,
use-case descriptions (Jacobsen, Christerson et al., 1993)
have been used. I discuss these in the following chapter.
Mathematical These are notations based on mathematical concepts
specifications such as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer
and contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract. I discuss formal
specification in Chapter 9.

128. What is Requirement Document

129. The requirements document
• The requirements document is the official
statement of what is required of the system
developers
• Should include both a definition and a
specification of requirements
• It is NOT a design document. As far as
possible, it should set of WHAT the system
should do rather than HOW it should do it

130. Users of a requirements document

131. S e if th r q i e e t a d
p c y e e u mns n
r
r a t e t c e k a th y
e d h mo h c th t e
S s m u t mr
y te c so e s me t ern e s T e
e t h i e d. h y
s e i yc a g stot e
p cf h n e h
r q ie e t
e ur mns
Ueth r q ir mn
s e e u e e ts
Mn g r
a a es d c mn t p nab f r
o u e t o la id o
th s se a dt p nt e
e y t m n o la h
s s m e eo mn p o e s
y te d v l p e t r c s
Ueth r q ir mn t
s e e u e e ts o
Ss mni er
y te e gn e s u d r t n wa s se ist
n e sa d h t y t m o
b dv l pd
e e eo e
S s me t
y te t s Ueth r q ir mn t
s e e u e e ts o
e gn e s
ni er d v l pv li aio t ssf r
e eo a d t n e t o
th s se
e yt m
Users of a
Ss m
y te Ueth r q ir mn t h lp
s e e u e e ts o e requirements
mi t n n e
ane a c u d r t n t es s m n
n esa d h y te a d
th r laio s i sb t e ni
e e t n hp ewe ts
document
e gn e s
ni er
pr
ats

132. Requirements document requirements

133. Requirements document requirements
• Specify external system behaviour
• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the
system i.e. predict changes
• Characterise responses to unexpected events

134. IEEE requirements standard
• Introduction
• General description
• Specific requirements
• Appendices
• Index
• This is a generic structure that must be
instantiated for specific systems

135. Requirements document structure
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index