Scribd
Upload
4 views

Lecture 15

Uploaded by

Laiba Anwaar
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
4 views

Lecture 15

Uploaded by

Laiba Anwaar
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

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

You might also like