Classification of Requirements
Functional Requirements
Functional and non-functional requirements
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.
The word processor must include a spell checking and
correction command
Non-functional requirements
Constraints on the services or functions offered by
the system such as timing constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than
individual features or services.
The system must ensure that personal information is never
made available without authorization
The status of sensor must be checked 10 times per second The system must be developed using C++
Classification of NFRs
Non-functional requirements
Process requirements
Product requirements External requirements Delivery requirements implementation requirements standards requirements Usability requirements Reliability requirements Safety requirements Efficiency requirements Performance requirements Capacity requirements Legal constraints Economic constraints Interoperability 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.
Product requirements
Usability
Usability is the ease with which a user can learn to operate,
prepare inputs for, and interpret outputs of system
Reliability
Reliability is the ability of a system to perform its required
functions under stated conditions for a specific period of time
Safety
Safety requirements are the ‘shall not’ requirements which
exclude unsafe situations from the possible solution space of the system
Charging the credit card but not booking a ticket in online
transactions or data loss due to accidental deletes.
Efficiency
The resultant product ought to use resources efficiently.
(CPU, RAM, disk space, bandwidth on the network, backup storage etc.)
Product requirements
Maintainability
The ease with which it is possible to make
changes in the system
Portability
porting is referred to as shifting the software
Robustness
Robustness is the degree to which a system
continues to function properly when confronted with invalid inputs, defects in connected software or hardware components, external attack, or unexpected operating conditions.
Example: ROB-1. If the text editor fails before the
user saves the file, it shall recover the contents of the file being edited as of, at most, one minute prior to the failure the next time the same user launches the application.
Reusability
Reusability indicates the relative effort required to convert a
software component for use in other applications. Reusable software must be modular, well documented, independent of a specific application and operating environment, and somewhat generic in capability.
Examples
REU-2. At least 30 percent of the application architecture shall
be reused from the approved reference architectures.
REU-3. The pricing algorithms shall be reusable by future store-management applications.
Scalability
Scalability requirements address the ability of the
application to grow to accommodate more users, data, servers, geographic locations, transactions, network traffic, searches, and other services without compromising performance or correctness.
SCA-1. The capacity of the emergency telephone
system must be able to be increased from 500 calls per day to 2,500 calls per day within 12 hours.
Verifiability
More narrowly referred to as testability, verifiability
refers to how well software components or the
integrated product can be evaluated to demonstrate whether the system functions as expected.
VER-1. The development environment configuration
shall be identical to the test configuration
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 efficiency requirement which specifies the maximum
memory size of the system.
The system shall not operate if the internal temperature is
above 60 degrees Celsius
Safety requirement
A door unlock that results from a successful security badge read
shall keep the door unlocked for 8.0 seconds
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 development process to be used must be
explicitly defined and must be conformant with CMMI standard
Standard requirement
The system must be developed using the XYZ suite
of CASE tools
Implementation requirement
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:
the need for the system to work with other systems
Legal requirements such as health or data protection
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.
Legal requirement
Interoperability
Interoperability indicates how readily the system can exchange data and services with other software systems and how easily it can integrate with external hardware devices.
IOP-1. The Chemical Tracking System shall be able to import any valid chemical structure from the ChemDraw (version 13.0 or
Functional and non functional requirements
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.
Non functional problem
A common problem with non-functional requirements
is that users or customers often propose these requirements as general goals,
Such as ease of use, the ability of the system to
recover from failure, or rapid user response.
Causes problems for system developers as they
leave scope for interpretation and subsequent dispute once the system is delivered.
Goals and non functional 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 convey the intentions of the system users to
Usability requirement
The system should be easy to use by medical
staff and should be organized in such a way
that user errors are minimized. (Goal)
Medical staff shall be able to use all the
system functions after four hours of training.
After this training, the average number of
errors made by experienced users shall not
exceed two per hour of system use. (Testable
non-functional requirement)
Metrics for specifying
nonfunctional requirements
Property Measure
Performance Processed transactions/second User/event response time
Screen refresh time
Capacity Mbytes
Ease of use Training time
Reliability Mean time to failure
Probability of unavailability Rate of failure occurrence Availability
Robustness Time to restart after failure
Portability Percentage of target dependent statements Number of target systems
