In this slide
_______________________________________________________
SRE –
Non-Functional Requirements
Non-Functional Requirements
BSEF15
(V)
Abdul
Razaq Ali
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
Non-Functional Requirements (NFRs)
Non-functional
requirements:
●
Define the overall qualities or attributes of the resulting system
●
Place restrictions on the product being developed & its development process
●
Specify external constraints that the product must meet.
Types of NFRs
The
‘IEEE-Std 830 - 1993’ lists 13, non-functional requirements to be included in a
Software Requirements Document.
●
Performance requirements
●
Interface requirements
●
Verification requirements
●
Documentation requirements
●
Security requirements
●
Quality requirements
●
Reliability requirements
●
Maintainability requirements
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
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.
● 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 requirement which specifies the maximum memory size
of the system.
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
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
●
Examples:
● The
development process to be used must be explicitly defined and must be
conformance with ISO 9000 standards
● The system must be developed using the XYZ suite of
CASE tools
● Management
reports setting out the effort expanded on each identified system component
must be produced every two weeks
● A disaster recovery plan for the system development
must be specified
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 physics
Relationship between User needs, concerns and NFRs
Goal-based Derivation
●
Relates non-functional requirements to the goals of the enterprise
●
Goal converted into a NFR:
● Goal (unverifiable)
● The system should be easy to use by experienced
controllers and should be organized in such a way that user errors are
minimized
● Non-functional requirement (verifiable)
● 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
Testable NFRs
●
Stakeholders may have vague goals which cannot be expressed precisely
●
Vague and imprecise ‘requirements’ are problematic
●
NFRs should satisfy two attributes for being Testable:
● Make it objective
● Use measurable metrics
Objective
NFR is based on facts, can be measured and can be verified.
Subjective
NFR is based on personal choices and desires
**
It is not always possible to express NFRs objectively
Examples of measurable metrics for NFRs
Reliability
●
Describe 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.
Performance
●
Describe the speed of operation of a system
●
Types of performance requirements:
● Response requirements
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
● All external communications between the system’s data
server and clients must be encrypted
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
Questions ?
