of 30
8/14/2019 Requirement Engineering Lecture 03
1/30
8/14/2019 Requirement Engineering Lecture 03
2/30
2
Kinds of Software Requirements
Functional requirements
Non-functional requirements Domain requirements
Inverse requirements
Design and implementation constraints
8/14/2019 Requirement Engineering Lecture 03
3/30
3
Non-Functional Requirements Discussion
NFRs are very important to capture theemergent behavior of the system in thesethere major dimensions
ProductUsability, reliability, portability, efficiency
(performance, space)
Organizational
Standards, implementation, delivery
External
Interoperability, ethical, legislative (privacy,
safety)
8/14/2019 Requirement Engineering Lecture 03
4/30
4
NFRs as Goals
Non-functional requirements are
sometimes written as general goals,
which are difficult to verify
They should be expressed
quantitatively using metrics (measures)that can be objectively tested
8/14/2019 Requirement Engineering Lecture 03
5/30
5
Example: Goal converted into an NFR
Goal (unverifiable)
The system should be easy to use byexperienced controllers and should be
organized in such a way that user errors areminimized
Non-functional requirement (verifiable)
Experienced controllers shall be able to use allthe system functions after a total of two hourstraining. After this training, the averagenumber of errors made by experienced usersshall not exceed two per day
8/14/2019 Requirement Engineering Lecture 03
6/30
Metrics for
Non-Functional Requirements
(NFRs)
8/14/2019 Requirement Engineering Lecture 03
7/30
7
Metrics for NFRs - 1
Property Measure
Speed1. Processed
transactions/second
2. Response time
3. Screen refresh time
Requirements related to Speed can use different
measures to quantify the goal
8/14/2019 Requirement Engineering Lecture 03
8/30
8
Metrics for NFRs - 2
Property Measure
Size 1. K bytes2. Number of function points
Requirements related to Size can use different measures
to quantify the goal
8/14/2019 Requirement Engineering Lecture 03
9/30
9
Metrics for NFRs - 3
Property Measure
Ease of use 1. Training time2. Number of help frames
Requirements related to Ease of use can use different
measures to quantify the goal
8/14/2019 Requirement Engineering Lecture 03
10/30
8/14/2019 Requirement Engineering Lecture 03
11/30
11
Metrics for NFRs - 5
Property Measure
Robustness1. Time to restart after failure
2. Percentage of events
causing failure
3. Probability of data
corruption on failure
Requirements related to Robustness can use different
measures to quantify the goal
8/14/2019 Requirement Engineering Lecture 03
12/30
12
Metrics for NFRs - 6
Property Measure
Portability1. Percentage of target-
dependent statements
2. Number of target systems
Requirements related to Portability can use differentmeasures to quantify the goal
8/14/2019 Requirement Engineering Lecture 03
13/30
13
Discussion on Metrics for NFRs
With the help of these measures the NFRscan be verified quantitatively
It should also be noted that the cost ofquantitatively verifying each NFR may be
very high
8/14/2019 Requirement Engineering Lecture 03
14/30
14
Kinds of Software Requirements
Functional requirements
Non-functional requirements
Domain requirements
Inverse requirements
Design and implementation constraints
8/14/2019 Requirement Engineering Lecture 03
15/30
Domain Requirements
8/14/2019 Requirement Engineering Lecture 03
16/30
16
Domain Requirements - 1
Requirements that come from the
application domain and reflect
fundamental characteristics of that
application domain
These can be both the functional ornon-functional requirements
8/14/2019 Requirement Engineering Lecture 03
17/30
17
Domain Requirements - 2
These requirements, sometimes, are
not explicitly mentioned
Domain experts find it difficult to
convey domain requirements
Their absence can cause significantdissatisfaction
8/14/2019 Requirement Engineering Lecture 03
18/30
18
Domain Requirements - 3
Domain requirements can impose strict
constraints on solutions. This is
particularly true for scientific and
engineering domains
Domain-specific terminology can alsocause confusion
8/14/2019 Requirement Engineering Lecture 03
19/30
19
Domain Requirements - 4
Example:
In a commission-based sales
businesses, there is no concept of
negative commission. However, if
care is not taken novice developers canbe lured into developing systems,
which calculate negative commission
8/14/2019 Requirement Engineering Lecture 03
20/30
20
Domain Requirements - 5
Banking domain has its own specific
constraints, for example, most banks
do not allow over-draw on most
accounts, however, most banks allow
some accounts to be over-drawn
8/14/2019 Requirement Engineering Lecture 03
21/30
21
Kinds of Software Requirements
Functional requirements
Non-functional requirements
Domain requirements
Inverse requirements
Design and implementation constraints
8/14/2019 Requirement Engineering Lecture 03
22/30
Inverse Requirements
8/14/2019 Requirement Engineering Lecture 03
23/30
23
Inverse Requirements - 1
They explain what the system shall notdo.
Many people find it convenient to describe
their needs in this manner
These requirements indicate the indecisive
nature of customers about certain aspects ofa new software product
8/14/2019 Requirement Engineering Lecture 03
24/30
24
Inverse Requirements - 2
Example:
The system shall not use red color in
the user interface, whenever it is
asking for inputs from the end-user
8/14/2019 Requirement Engineering Lecture 03
25/30
25
Kinds of Software Requirements
Functional requirements
Non-functional requirements
Domain requirements
Inverse requirements
Design and implementation constraints
8/14/2019 Requirement Engineering Lecture 03
26/30
Design and Implementation
Constraints
8/14/2019 Requirement Engineering Lecture 03
27/30
27
Design and Implementation
Constraints - 1 They are development guidelines
within which the designer must work
These requirements can seriously limit
design and implementation options
Can also have impact on humanresources
8/14/2019 Requirement Engineering Lecture 03
28/30
8/14/2019 Requirement Engineering Lecture 03
29/30
29
Summary
Discussed different kinds of
requirements including domain,
inverse, and implementation
constraints
Requirements should be explored fromdifferent perspectives and categorized
differently
8/14/2019 Requirement Engineering Lecture 03
30/30
30
References
Requirements Engineering: Processes andTechniques by G. Kotonya and I.
Sommerville, John Wiley & Sons, 1998 Software Requirements: Objects, Functions,
and States by A. Davis, PH, 1993
Software Engineering 6thEdition, by I.Sommerville, 2000
Software Engineering 5thEdition, by R.Pressman