Lecture
-15
University of Management & Technology
School of Systems and Technology
Software Engineering
CC-2101
Functional & Non-Functional
Requirements
Somerville | Ch-4 (Pg.
101)
Requirements engineering
• The process of establishing the services that a
customer requires from a system and the
constraints under which it operates and is
developed.
• The system requirements are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
2
What is a requirement?
• It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a dual
function
• May be the basis for a bid for a contract - therefore must be
open to interpretation;
• May be the basis for the contract itself - therefore must be
defined in detail;
• Both these statements may be called requirements.
3
Types of requirement
• User requirements
• Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
• System requirements
• 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. 4
Readers of different types of requirements
specification
5
System stakeholders
• Any person or organization who is affected by
the system in some way and so who has a
legitimate interest.
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders 6
Agile methods and requirements
• Many agile methods argue that producing detailed
system requirements is a waste of time as
requirements change so quickly.
• The requirements document is therefore always out of
date.
• Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’ (discussed in Chapter 3).
• This is practical for business systems but problematic
for systems that require pre-delivery analysis (e.g., critical
systems) or systems developed by several teams.
7
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.
• May state what the system should not do.
• 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.
• Domain requirements 8
• Constraints on the system from the domain of operation
Functional requirements
• Describe functionality or system services.
• Depend on the type of software, expected
users and the type of system where the
software is used.
• Functional user requirements may be high-level
statements of what the system should do.
• Functional system requirements should describe
the system services in detail.
9
Requirements imprecision
• Problems arise when functional requirements are
not precisely stated.
• Ambiguous requirements may be interpreted in
different ways by developers and users.
• Consider the term ‘search’ in requirement 1
• User intention – search for a patient name across all
appointments in all clinics;
• Developer interpretation – search for a patient name
in an individual clinic. User chooses clinic then search. 10
Requirements completeness and consistency
• In principle, requirements should be both complete and
consistent.
• Complete
• They should include descriptions of all facilities required.
• Consistent
• There should be no conflicts or contradictions in the descriptions
of the system facilities.
• In
practice, because of system and environmental
complexity, it is impossible to produce a complete
and consistent requirements document. 11
Thankyou
Q&A
12
