Department of Information Systems
Subject : Requirement Engineering
Functional Requirement (FR)
Non Functional Requirements (NFR)
IS184309, 3 sks
Feby Artwodini M.
[Link]@[Link]
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
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 3
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 4
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 5
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
Functional Requirements (2)
A functional requirement is testable
◦ fold this activity right into the writing
A general rule is: a functional requirement is a “shall statement”
Functional Requirements (3)
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
Functional Requirements (4)
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
Functional Requirements (5)
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
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 19
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
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 26
Doll and
Torkzadeh
Elicitating the NFRs
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 31
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 32
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 33
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+
REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 34
