Chapter 2

Types of Requirements

1
 Contents
 User Requirements
 System Requirements
 Software Design Specification Requirements
 Functional Vs Non-Functional Requirements
 Domain Requirements
 Classification of NFRs
 Some NFRs
 Deriving NFRs
 Stakeholder Concerns
 Goal-based derivation
Testable NFRs

2
 User Requirements
Should describe functional and non-functional
requirements so that they are understandable by system
users who don’t have detailed technical knowledge
They are called user requirements because they are
written from a user’s perspective
User requirements are defined using statements in natural
language, tables, diagrams.
 Written primarily for customers
User Requirement Readers

3
 User Requirement Specification

Problems with Natural Language

 Lack of clarity
Sometimes natural language statements be clear to read,
understand and interpret
 Requirements confusion
Functional and non-functional requirements tend to be mixed-up
 Requirements amalgamation
Several different requirements may be expressed together

4
 System Requirements
 are expanded versions of the user requirements that are used by software
engineers as the starting point for the system design.
 They add detail and explain how the user requirements should be provided
by the system
 capture the vision of the customer, enable defining the scope of the system,
and allow estimating the cost and schedule required to build the system.
 A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
 Defines what should be implemented so may be part of a contract between
client and contractor.
 May serve as a contract between client and developer.
System Requirement Readers

5
 System Requirements Specification

6
 Software Design Specification Requirements
 Implementation oriented abstract description of software
design which may utilize formal (mathematical) notations.
 Written for developers.
Software Design Specification Readers

7
 Types of requirements
 Functional requirements
 Non functional requirements - Quality Attributes
 Domain requirements

Functional requirements
 Describes system services or functions which are expected by the users of the
system.
 How it should react to particular inputs,
 How it should behave in particular situations.
 Examples:
• 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.
 Functional requirements describe what the system or software must do and sometimes called
behavioral or operational requirements.
 In order to find out functional requirements of a system try to answer the questions below
8  What inputs the system should accept?
 Types of requirements
 Functionalrequirements
 Non functional requirements - Quality Attributes
 Domain requirements

Functional requirements
 Describes system services or functions which are expected by the users of the
system.
 How it should react to particular inputs,
 How it should behave in particular situations.
 Examples:
• 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.
 Functional requirements describe what the system or software must do and sometimes called
behavioral or operational requirements.

9
 Types of requirements
 In order to find out functional requirements
of a system try to answer the questions
below
What inputs the system should accept?
What outputs the system should produce?
What data the system should store that other
systems might use?
What computations the system should
perform?

10
 Types of requirements
Non- Functional requirements
 define the overall qualities or attributes of the resulting system like: (security),
Usability, Reliability, Performance & Supportability
 NR specify system properties, such as reliability and safety.
 NFRs are often called “quality attributes”
 More critical than functional requirements.
 Represents 20% of the requirements of a system
 Hardest to elicit and specify
 Defining good NFRs requires not only the involvement of the customer but
the developers too
 All requirements must be verifiable
– If not ‘verifiable’ then there is no indications that these requirements have
been satisfied.
 Some must also be measured.
– Some may be directly measured; some measured via simulation.
If not met, the system may be useless.
11 (They are not “second class” requirements.)
 Types of requirements…
 NR place restrictions on the product being developed, the
development process, and specify external constraints that the
product must meet.
 Example
The product must be available at the beginning of the next year
The product shall operate on a 3G mobile telephone.
The system shall be easy to use
The system should not fail more than twice in a week.
The system shall respond to every user action in less than 3
seconds

12
 Types of requirements…
 Functional Vs 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.

13
 Types of requirements…
 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 data.
In this form, the requirement looks rather more like a functional
requirement as it specifies a function (user login) which must be
incorporated in the system.

14
 Domain Requirements
 Requirements that come from the application domain of the system and that reflect
characteristics of that domain.
 Functional or non-functional requirements derived from application domain (e.g.,
legal requirements or physical laws).
 Derived from the application domain rather than user needs.
 May be new functional requirements or constraints on existing requirements.
 If domain requirements are not satisfied, the system may be unworkable.
For example,
A train control system has to take into account the braking characteristics in
different weather conditions. This is a domain requirement for a train protection
system.
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.
15
 NFRS
Non-functional requirements (NFR) define the overall
qualities of the resulting system;
 They are global constraints on a software system , on the
development process or external constrains outside the
enterprise
Importance
All functional requirements may be satisfied, but if
nonfunctional requirements are overlooked, the system will fail.
Non-functional properties may be the difference between an
accepted, well-liked product & unused one.
Though all NFRs are important their relative importance differs
from stakeholder to stakeholder and from system to system.
Reliability, Performance, Security, Usability, Safety NFRs are
more important than others for critical systems
16 Non-functional requirements like Usability, efficiency,
 NFRs…
 The challenge of NFRs
 Hard to model
Usually stated informally, and so are:
often contradictory,
difficult to enforce during development
difficult to evaluate for the customer prior to delivery
Hard to make them measurable requirements
We’d like to state them in a way that we can measure how well
they’ve been met
Different people and organizations use different terminologies
and different definition (though basically the definitions have the
same meaning)

17
 Classification of NFRs…
A more general classification distinguishes between product,
process and external requirements is recently proposed by
Sommerville [2007] Non-functional
requirements

Process Product requirements External

requirements requirements
Usability requirements
Delivery Legal
requirements Reliability requirements constraints
implementation Safety requirements Economic
requirements constraints
standards Efficiency requirements
Interoperability
requirements requirements
Performance requirements
18 Capacity requirements
 Non-functional classifications
Product requirements
specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
 Examples
The System service X shall have an availability of 999/1000 or
99%.
System Y shall process a minimum of 8 transactions per
second.
The executable code of System Z shall be limited to
512Kbytes.

19
 Organisational requirements
are a consequence of organizational policies and procedures
e.g. process standards used, implementation requirements,
etc.
 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
 Examples
 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

20  Management reports setting out the effort expended on each identified

system component must be produced every two weeks
 External requirements
 arise from factors which are external to the system and its
development process e.g. interoperability requirements,
legislative requirements, etc.
 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 physics
 Examples
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
21
Examples of nonfunctional requirements in the MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during
normal working hours (Mon–Fri, 0830–17.30).
Downtime within normal working hours shall not
exceed five seconds in any one day.
Organizational requirement
Users of the MHC-PMS 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-2006-priv.
22
 What are Quality Attributes…?
A set of constraints the system must satisfy and the
standards which must be met by the delivered
system.
Performance, Reliability, Usability, Efficiency,
Maintainability, Portability, Scalability, Security, Integration etc.,
Describes “how” the system achieves its
functional requirements

23
 Performance
 Response time
 Definition : particularly important for processes that process a lot of
data or use networks a great deal.
 Example
– Requirements might stipulate < two second response.
– Might use a Timing bar indicating progress…
– Response time may be considered a functional requirement for some
‘real time systems.
Deadline:
Definition : ‘Something must be completed before some specified time’
Example :
 Payroll system must complete by 2am so that electronic transfers
can be sent to bank
 Weekly accounting run must complete by Monday 6am -so that
24 figures are available to management
 Reliability
 Definition : The extent to which the software system consistently
performs the specified functions without failure.
 Example
 No more than 10 claim assignments out of 5000 can be
“unassigned” because of system failures.
 Reliability Criteria
Maturity: Capability of the software to avoid failure as a result of
faults in the software.
Fault tolerance: Capability of the software to maintain a specified level
of performance in cases of software faults.
Recoverability: Capability of the software to re-establish its level of
performance and recover the data directly affected in the case of a
failure.
Availability: Capability of the software to be in a state to perform a
required function at a given point in time. The Automated Teller Machine shall
25 be at least 99.5 percent available on weekdays between 6:00 a.m
 Usability
 Definition : The capability of the software to be understood,
learned, used and liked by the user, when used under specified
conditions.
 Example:A trained order-entry clerk shall be able to submit a
complete information in a maximum of 7 minutes
Usability Criteria
Understandability: capability of the software product to enable the
user to understand whether the software is suitable, and how it
can be used for particular tasks and conditions of use.
Learnability: capability of the software product to enable the user
to learn its application
Operability: capability of the software product to enable the user
to operate and control it.
Likeability: capability of the software product to be liked by the user.

26
 Efficiency
 Definition :The
capability of the software to provide the required
performance relative to the amount of resources used, under stated
conditions
Resources may include other software products, hardware facilities,
materials, (e.g. print paper, diskettes).
 The extent to which the software system handles capacity,
throughput, and response time.
Example - The system must download the new rate parameters
within ten minutes of a non-scheduled rate change.
Efficiency Criteria
Time behaviour: The capability of the software to provide appropriate
response and processing times when performing its function, under
stated conditions.
Resource utilisation: The capability of the software to use appropriate
resources in an appropriate time when the software performs its
27
function under stated conditions.
 Maintainability
 Definition :
The capability of the software to be modified.
Modifications may include corrections, improvements or adaptation of
the software to changes in environment, and in requirements and
functional specifications.
 the ease in finding and fixing faults in the software system.
 Example - The application development process must have a regression
test procedure that allows complete re-testing within 2 business days.
Maintainability Criteria
Changeability: The capability of the software product to enable a
specified modification to be implemented.
Stability: The capability of the software to minimise unexpected effects
from modifications of the software
Testability: The capability of the software product to enable modified
software to be validated.

28
 Portability
 Definition :The capability of software to be transferred from one
environment to another. The environment may include
organisational, hardware or software environment.
Example - The system is designed to run in business offices, but
the intent is to have a version which will run in manufacturing
assembly plants.
Portability Criteria
Adaptability: The capability of the software to be modified for
different specified environments without applying actions or means
other than those provided for this purpose for the software considered.
Installability: The capability of the software to be installed in a
specified environment.
Conformance: The capability of the software to adhere to standards or
conventions relating to portability.
Replaceability: The capability of the software to be used in place of
other specified software in the environment of that software.
29
 Scalability
 Definition :
 “How well a solution to some problem will work when the size of
the problem increases.”
 the degree in which the software system is able to expand its
processing capabilities upward and outward to support business
growth.
Example - Any increase in the number of customers shall not
degrade system availability to an extent noticeable by any users.
4 common scalability issues in IT systems:
• Request load
• Connections
• Data size
• Deployments

30
 Security
 Definition:

 The extent to which the system is safeguarded against deliberate and

intrusive faults from internal and external sources.
Quality attribute for security
Authentication: Applications can verify the identity of their users and
other applications with which they communicate.
Authorization: Authenticated users and applications have defined
access rights to the resources of the system.
Encryption: The messages sent to/from the application are encrypted.
Example - Employees shall be forced to change their password the
next time they log in if they have not changed it within the length of
time established as “password expiration duration.”

31
 Integration
 Definition:the degree to which the data maintained by the software system
is accurate, authentic, and without corruption.
 Example - The integrity of the system data area must be checked by the
internal audit system twice per second; if inconsistencies in the data are
detected, the system operation should be disabled.
 Typically achieved by:
Programmatic APIs
Data integration

32
  Survivability
Definition - the extent to which the software system continues
to function and recovers in the presence of a system failure.
Example - All policy statement parameters shall have default
values specified, which the Report Writer system shall use if a
parameter’s input data is missing or invalid.
 Flexibility
Definition — the ease in which the software can be modified
to adapt to different environments.
Example - It shall be possible to add a new delivery option for
customer mailing method by developing and “plugging in” the
functionality necessary to support that delivery option.

33
 Scalability
Definition — the degree in which the software
system is able to expand its processing capabilities
upward and outward to support business growth.
Example - Any increase in the number of customers
shall not degrade system availability to an extent
noticeable by any users.

34
 Verifiability
Definition — the extent to which tests, analysis, and
demonstrations are needed to prove that the software
system will function as intended.
Example - The maximum number of test cases to
cover testing of any particular source code module
shall be 20.
Interoperability
Definition — the extent to which the software system
is able to couple or facilitate the interface with other
systems.
Example - The system must be able to interface with
any HTML (HyperText Markup Language) browser.
35
Correctness
Definition - Deals with the extent to which the
software design and implementation conform to the
stated requirements
Example - The requirements can be e.g. time limits,
effort constraints, development techniques to be used
etc.
Safety
Definition - meant to eliminate conditions hazardous
to equipment as a result of errors in process control
software.
Example - The system shall not operate if the external
temperature is below 4 degrees Celsius
36
Expandability
Definition - refer to future efforts that will be needed to
serve larger populations, improve services, or add new
applications in order to improve usability.
Example - The Automated Money Machine (AMM)
System shall be designed in such a manner as to allow for
future addition of 4 user buttons and 4 additional banking
services.
Manageability
Definition - refer to the administrator tools that support
software modification during the software development
and maintenance periods.
Example - the system must be self-configure with respect
to load and data distribution and self-heal with respect to
37
failure and recovery
 Deriving NFRs
Non-functional requirements 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
(response time to failure)
Certain constraints, are highly subjective and can
only be determined through complex empirical
evaluations (associated with human beings)
Non-functional requirements tend to be related to
one or more functional requirements

38
 Contd…
Non-functional requirements tend to conflict and
contradict
There are no ‘universal’ rules and guidelines for
determining when non-functional requirements
are optimally met.
In spite of the fact, two different ways of driving
NFRs are discussed here: Stakeholder concerns &
goal-based derivation

Stakeholder concerns
Stakeholders normally have a number of
‘concerns’
 Concerns are typically non-functional
39
Vaguely defined user concerns may be related to
What are Concerns?
A way of expressing critical ‘holistic’ requirements
which apply to the system as a whole rather than any
specific sub-set of its service or functionality.
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
The concerns may lead directly to system requirements
or to questions which must be answered during the
requirements engineering process.

40
 Stakeholder concerns…
Relationships between user needs, concerns and NFRs

To illustrate this approach the following figure shows the

decomposition of safety & compatibility concerns for train
41protection system
 Concern decomposition
Safety Compatibility

Personal Software Physical

Collision Derailment Hardware
accident

Execution Timing Interface

Excess speed
Track damage Environment
for track conditions

What information about Will a requirement affect

System must be able to
track damage is required by the performance of the
detect and avoid excess
the system? How is this existing software?
speed
provided?
Does a requirement need
System must execute in the trusted
Under what conditions data that isn't available
Ada execution environment
can excess speed cause through the HST interface?
derailment?

What does 'excess speed' mean in reality? Can this function be

provided on the existng
execution environment?
42
 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 goals
Decompose the goals into sub-goals
Identify non-functional requirements.
One advantage of this approach is that it provides a
means of tracing non-functional requirements to
originally stated , vague expressions in the enterprise
domain

The approach is illustrated using a requirement drawn

43
from the air traffic domain, on the next slide
 Example of goal-based derivation

44
 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 and
testable (Use measurable metrics)
Property Metric
Performance 1. Processed transactions per second
2. Response time to user input
Reliability 1. Rate of occurrence of failure
2. Mean time to failure
Availability Probability of failure on demand
Size Kbytes
Usability 1. Time taken to learn 80% of the facilities
2. Number of errors made by users in a given time
period
Robustness Time to restart after system failure
45Portability Number of target systems
 Use a template to document the nonfunctional requirements.

46