Lecture
-16
University of Management & Technology
School of Systems and Technology
Software Engineering
CC-2101
Non-Functional Requirements
Somerville | Ch-4 (Pg.
101)
Non-functional requirements
• These define system properties and constraints e.g.
reliability, response time and storage requirements.
• Constraints are I/O device capability, system
representations, etc.
• Process requirements may also be specified mandating
a particular IDE, programming language or development
method.
• Non-functional requirements may be more critical than
functional requirements.
• If these are not met, the system may be useless. 2
Types of nonfunctional requirement
3
Non-functional requirements implementation
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
• For example, to ensure that performance requirements are met, you
may have to organize the system to minimize communications
between components.
• A single non-functional requirement, such as a security
requirement, may generate a number of related
functional requirements that define system services that
are required.
• It may also generate requirements that restrict existing requirements.
4
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. 5
Goals and 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 are helpful to developers as they convey the
intentions of the system users.
6
Usability requirements
• 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)
7
Metrics for specifying non-functional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
8
Number of target systems
Thankyou
Q&A
