The document discusses different types of requirements for software systems including user requirements, system requirements, domain requirements, functional requirements, and non-functional requirements. It provides details on each type, including that user requirements are written for customers in natural language, system requirements serve as a contract between client and developer, and domain requirements reflect characteristics of the application domain. Functional requirements describe system services while non-functional requirements constrain system functions and development processes. The document also discusses challenges with specifying non-functional requirements and provides examples of performance, reliability, security, usability, and safety requirements for critical systems.

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

2. 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

3. 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.

4. What are User requirements

5. 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

6. What are System requirements

7. 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

8. What are Domain requirements

9. 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

10. What is Functional Requirement

11. 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

12. Types of Non-functional requirement

13. 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

14. 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.

15. Features of Non-Functional
Requirements
1. Non-Functional requirements mostly define
the overall attributes of the “resulting”
system.

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

17. IEEE Standard 830 – 1993
• List of 13 non-functional requirements Examples:
1. Performance: 100 transactions per minute
2. Interface: capable of importing data with EDI format
3. Operational: must not require more than 1 megabyte of main memory
4. Resource: will use wireless encryption algorithm that is “better” than WEP
5. Verification: all data updates must be traceable
6. Acceptance: must pass a user defined system test bucket
7. Documentation: user manual is needed for novice users only
8. Security: user request to access any data must be authorized first
9. Portability: the system must operate with “any” relational db systems
10. Quality: the system must install with zero defect
11. Reliability: the system must be accessible 99.9 % of the time
12. Maintainability: the system must be modifiable (e.g. designed with exits)
13. 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

18. Difficulties in Specifying
Non-functional Requirements

19. 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
similar
they can not be well understood or validated until much later
• e.g. reliability or quality
– Certain non-functional requirements may be conflicting
• e.g. performance .vs. security .vs. reliability
– Certain non-functional requirements may be difficult to express and
validate; may require more refinements.

20. What are“Critical” Systems

21. “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.

22. Requirements for System Criticality

23. 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

24. Performance Related Requirements

25. 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.

26. Reliability Related Requirements

27. 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.

28. Security Related Requirements

29. 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.

30. Usability Related Requirements

31. 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.

32. Safety Critical System Requirements

33. 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

34. Requirements measures

35. 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

36. Relationship Between Requirement
and Design

37. 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

38. Relationships between user
needs, concerns and NFRs

39. 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.
3. Ease of interfacing Verifiability
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 4. Expandability
capacity or performance ?

40. 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

41. How to write requirements:

42. 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 !!!

43. Problems with natural language

44. 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

45. Alternatives to NL specification

46. 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.

47. What is Requirement Document

48. 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

49. Users of a requirements document

50. 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

51. Requirements document requirements

52. 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

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

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