Chapter 2

Types of Requirements
 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
 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
 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
 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
System Requirements Specification
Software Design Specification Requirements
 Implementation oriented abstract description of software
design which may utilize formal (mathematical) notations.
 Written for developers.
Software Design Specification Readers
 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.
 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?
 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.
(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
 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.
 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.
 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.
 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
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)
 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
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.
 Organizational requirements(Process)
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
 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
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.
 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
 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
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
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.
 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
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.
 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.
 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
 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.”
 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
 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.
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.
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.
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
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
failure and recovery
 Quize1
1. Group the following as Product,Organazetional and
External requirements
 A. A disaster recovery plan for the system development must be
specified.organization
 B. The system X shall process a minimum of 8 transactions per
second.p
 C. The system must be able to interface with any HTML
browser.External
2. Define functional and Non-functional requirements
and give at least one examples for each requirement.
 Quiz 1
1. Which one of the following is a requirement that fits in a
developer’s module ?
a). Availability b). Testability c). Usability d). Flexibility
2. “Consider a system where, a heat sensor detects an intrusion
and alerts the security company.” What kind of a
requirement the system is providing ?
a). Functional b). Non-Functional c). Known Requirement
3. State Functional or Non-functional Requirement.
a. The library system must allow up to 5 books to be reserved.FR
b. The average response time for ATM should not be more than
5s.NFR
4. Non-functional requirements are not second class requirements
why?
=the system may useless