Functional Requirement (FR) Non Functional Requirements (NFR)

Department of Information Systems
Subject : Requirement Engineering
Functional Requirement (FR)

Non Functional Requirements (NFR)
IS184309, 3 sks
Feby Artwodini M.
feby.artwodini@gmail.com
Learning Objectives
•To introduce types of requirement
•To comprehend the differences between functional and non functional requirements
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 2

Outline
 FR
 NFR
 Example

Functional Requirement
Functional Requirements (1)
specify functions that a system or component must be able to perform
describe what the system should do
things that can be captured in use cases
things that can be analyzed by drawing sequence diagrams, statechart, etc.
will probably trace to individual chunks of a program
A functional requirement is testable
◦ fold this activity right into the writing
A general rule is: a functional requirement is a “shall statement”
These can be high level or low level (generally we’re at high level in this class)
High level: The system shall charge users credit cards for purchases
Low level: The system shall validate all passwords contain upper and lowercase
characters and one number
Are testable
◦ your “test lead” should be collecting sets of basic tests generated for each
requirement linked to the requirement
◦ this is part of writing the requirement!
Should be one thing (not multiple). (Because a requirement is a single entity… it

passes or fails as one piece)
Should have a source (who/what decided this was required)
Should have a priority
Should not be a design choice
◦ The system shall store user information including name, DOB, address and SSN. <-- Good!
◦ The system shall store user information in an Oracle database including name, DOB, address,
SSN. <-- bad
Must have a unique ID.

◦ When testing you need to reference REQ-1 or REQ-287. Multiple things cannot be labeled
REQ-1.
Functional Requirement Prioritisation
Must have requirement
Should have requirement

Could have requirement
Wish list requirement

FR - Prioritization Logic
M - MUST: Describes a requirement that must be satisfied in the final solution
for the solution to be considered a success.
S - SHOULD: Represents a high-priority item that should be included in the
solution if it is possible. This is often a critical requirement but one which can be
satisfied in other ways if strictly necessary.
C - COULD: Describes a requirement which is considered desirable but not
necessary. This will be included if time and resources permit.
W - WISHLIST: Represents a requirement that stakeholders have agreed will not
be implemented in a given release, but may be considered for the future. (note:
occasionally the word "Would" is substituted for "Won't" to give a clearer
understanding of this choice)
Example: The LIBSYS system
A library system that provides a single interface to a number of databases of
articles in different libraries.
Users can search for, download and print these articles for personal study.
Examples of functional requirements
The user shall be able to search either all of the initial set of databases or select
a subset from it.
The system shall provide appropriate viewers for the user to read documents in
the document store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account’s permanent storage area.
Non Functional
Requirement
Non-functional Requirements (1)
•Define the overall qualities or attributes of the resulting system
•Place restrictions on the product being developed, the development process,
and specify external constraints that the product must meet.
Examples of NFR include safety, security, usability, reliability and performance
requirements.
May be more critical than functional requirements
◦ If these are not met, the system is useless!
Types of Non Functional Requirements
•IEEE-Std 830 – 1993
•(Jacobson, 1999)
•Ian Sommervile
•Nielsen Model
•Mc Call
•Doll & Torkzadeh
IEEE-Std 830 – 1993
Performance requirements: Documentation requirements:
‹1. Interface requirements 1. Security requirements
‹2. Operational requirements ‹2. Portability requirements
‹3. Resource requirements ‹3. Quality requirements
‹4. Verification requirements ‹4. Reliability requirements
‹5. Acceptance requirements ‹5. Maintainability requirements
‹6. Safety requirements
(Jacobson, 1999)
Usability Implementation requirements
Reliability Interface requirements
Performance Operations requirements
Supportability Packaging requirements
Legal requirements
Ian Sommervile
specify that the delivered product must behave in a
Product particular way
requirements: e.g. execution speed, reliability, etc.
are a consequence of organizational policies and

Organisational procedures
requirements: e.g. process standards used, implementation
requirements, etc.
arise from factors which are external to the system
External and its development process
requirements: e.g. interoperability requirements, legislative
requirements, etc.
Examples of Non-functional Requirements by Ian Sommervile
The System service X shall have an availability of 999/1000 or

99%. This is a reliability requirement which means that out of
Product requirement
every 1000 requests for this service, 999 must be satisfied.
The system development process and deliverable documents shall

Organisational conform to the process and deliverables defined in XYZCo-SP-STAN-
requirement 95.
The system shall provide facilities that allow any user to check if
personal data is maintained on the system. A procedure must be
External requirement defined and supported in the software that will allow users to inspect
personal data and to correct any errors in that data.
Types of Non Functional Requirements Ian Sommervile
Non-functional
requir ements
Product Or ganizational External

requir ements requir ements requirements
Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements
Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements
Performance Space Privacy Safety

requirements requir ements requirements requirements
Nielsen Model
Easy to use
Utility Easy to learn
System Acceptability
Usefulness
Social Acceptability Usability Easy to remember
Cost
Practical Acceptability Few errors
Compatibility
Subjectively pleasing
Reliability
System Acceptability Model - Nielsen Model

Doll and
Torkzadeh
Elicitating the NFRs

Group Assignment:
Paper Review – Software Quality
Indikator Definisi/Deskripsi Teori (by) Tahun How to tets?*
*How to test (tools/methods/approach/?)
Ex.
1. IEEE vs Sommerville
2. Van Vliet vs Keller
3. ISO 9126 vs Nielsen Model
4. Gilb 2005 vs Mc Calls
5. Miller 2009 vs FURPS+

Functional Requirement (FR) Non Functional Requirements (NFR)

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Functional Requirement (FR) Non Functional Requirements (NFR)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Functional Requirement (FR) Non Functional Requirements (NFR)

Uploaded by

Copyright:

Available Formats

Department of Information Systems

Subject : Requirement Engineering

Functional Requirement (FR)

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 2

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 3

Should be one thing (not multiple). (Because a requirement is a single entity… it

Must have a unique ID.

Should have requirement

Wish list requirement

are a consequence of organizational policies and

The System service X shall have an availability of 999/1000 or

The system development process and deliverable documents shall

Product Or ganizational External

Ef ficiency Reliability Portability Interoperability Ethical

Usability Delivery Implementation Standards Legislative

Performance Space Privacy Safety

Utility Easy to learn

Social Acceptability Usability Easy to remember

Practical Acceptability Few errors

System Acceptability Model - Nielsen Model

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 31

*How to test (tools/methods/approach/?)

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 34

You might also like