COIS 3030

Lecture#12

Mastering the Requirement Process, Robertson and Robertson

Non-Functional Requirements
(Chapter 12)
✦ Non-Functional Requirements: describe the qualities
or the attributes that the functionality must have.
✦ Functional requirements as those that cause the
product to do the work and the non-functional
requirements as those that give character to the work.
✦ Example: Recording data: functional requirement.
Recording data within 5 seconds: non-functional
requirement (speed).
✦ Non-Functional requirement can be specific to
particular functional requirements, or to a product use
case, or to an entire project.

Mastering the Requirement Process, Robertson and2Robertson

Non-Functional Requirements

Mastering the Requirement Process, Robertson and3Robertson

Look and Feel Requirements: Type 10
✦ Description: The product shall comply with corporate
branding standards.
The product shall be conservative.

The product shall be intriguing.

The product shall appear authoritative.

The product shall be attractive to an older audience.
The product shall appear simple to use.

The product shall appear state of the art.

The product shall have an expensive appearance.
The product shall comply with Windows User
Experience Interaction Guidelines for Windows 8.

Mastering the Requirement Process, Robertson and4Robertson

Usability and Humanity Requirements: Type 11

✦ Usability requirements make the product conform to

the user’s abilities and expectations of the usage
experience.
✦ Example: The product shall be usable by customers
with limited experience of using computers.
Description: The product shall be easy to use by
certified mechanical engineers.
Description: The product shall be easy to learn.

Mastering the Requirement Process, Robertson and5Robertson

 Usability and Humanity Requirements: Type 11

Description: The product shall be easy to use on the

first attempt by a member of the public without training.

Rationale: This is a new product and we need our

customers to voluntarily switch to using it.

Fit Criterion: Ninety percent of a panel that is

representative of the customer base shall successfully
complete [list of tasks] within 90 seconds of their first
encounter.

Mastering the Requirement Process, Robertson and6Robertson

Usability and Humanity Requirements: Type 11
✦ Sometimes the client/stakeholder can use words with
wide-range of meaning, such as the the product
should be “friendly”
Description: The product shall provide the preferred
way of working for the personnel consultants.
Rationale: To build the consultants’ confidence in the
product.
Fit Criterion: Seventy-five percent of the consultants
shall switch to using the product after a six-week
familiarization period.

Mastering the Requirement Process, Robertson and7Robertson

Usability and Humanity Requirements: Type 11

✦ Rate of acceptance or adoption by the users

✦ Productivity gained as a result of the product’s
introduction.
✦ Error rates (or reduction thereof).
✦ Use by people who do not speak the language of the
country where the product is to be used.
✦ Personalization and internationalization to allow users
to change to local spelling, currency, and other
preferences.

Mastering the Requirement Process, Robertson and8Robertson

Usability and Humanity Requirements: Type 11

✦ Accessibility to handicapped people (this is

sometimes mandated by law).
✦ Use by people with no previous experience with
computers (an important, albeit often-forgotten
consideration).
✦ Usage during the hours of darkness (this caters to the
vampire community) 


Mastering the Requirement Process, Robertson and9Robertson

Usability and Humanity Requirements: Type 11

✦ Politeness:
Description: The product shall avoid asking the user to
duplicate any entered data.
Rationale: To build the user’s confidence in the
product.

Mastering the Requirement Process, Robertson and10

Robertson
 Performance Requirements: Type 12

Description: The product shall have the capacity for

5,000 roads.

Rationale: The maximum number of roads in the area
of any potential customer for the product.

The product shall support 2,000 concurrent users.

The product shall accommodate the largest

geographical area of any road authority in the world.

✦ The performance requirements come mainly from

the operating environment. Each environment has
its own set of circumstances and conditions.

Mastering the Requirement Process, Robertson and11

Robertson
 Performance Requirements: Type 12
✦Speed to complete a task.
✦Accuracy of the results.
✦Safety to the operator.
✦Volumes of data to be held by the product.
✦Ranges of allowable values.
✦Throughput, such as the rate of transactions.
✦Efficiency of resource usage .

✦Reliability, often expressed as the mean time

between failures.
✦Availability—the uptime or time periods when users
can access the product.
✦Fault tolerance and robustness.
✦Scalability of most of the above.
Mastering the Requirement Process, Robertson and12
Robertson
 Performance Requirements: Type 12

Description: The product shall schedule de-icing

activities so that the minimum necessary amounts of
de-icing material are spread on roads.
Rationale: To minimize environmental damage.

Mastering the Requirement Process, Robertson and13

Robertson
Operational and Environmental Requirements: Type 13

Description: The product shall be used in and around

trucks at night and during rainstorms, snow, and
freezing conditions.
Rationale: These are the most likely conditions that
the truck drivers encounter when de-icing roads.

✦ Operational requirements specify what the product

has to do if it is to operate correctly in its
environment.

Mastering the Requirement Process, Robertson and14

Robertson
 Operational and Environmental Requirements: Type 13

✦ Operational requirements are also written when

the product has to collaborate with partner
products, access outside databases, or interact
with other systems that supply information.

The product shall interact in compliance with the Visa

International and Regional Operating Regulations
issued January 15, 2012.

Mastering the Requirement Process, Robertson and15

Robertson
 Operational and Environmental Requirements: Type 13

Mobile devices:

The product shall survive being dropped from

shoulder height.

The product shall be usable in variable lighting

conditions.

The product shall conserve battery life.

Mastering the Requirement Process, Robertson and16

Robertson
 Maintainability and Support Requirements: Type 14

Description: The product shall be readily portable to

Android and iOS. Rationale: We anticipate moving into
the mobile device market.

The product shall be translated into various foreign

languages. As yet, the languages are unknown.

Mastering the Requirement Process, Robertson and17

Robertson
 Security Requirements: Type 15

Mastering the Requirement Process, Robertson and18

Robertson
 Security Requirements: Type 15

Aspects of security:
Access: The product’s data and functionality are
accessible to authorized users and can be produced
in a timely manner. Other access requirements focus
on denying access to unauthorized people. 


Privacy: Data stored by the product is protected from

unauthorized or accidental disclosure. 


Integrity: The product’s data is the same as the

source, or authority, of the data, and is protected from
corruption. 

Mastering the Requirement Process, Robertson and19
Robertson
 Security Requirements: Type 15

Access:
The product shall ensure that only authorized users
have access to the [name of] data (or function).





Mastering the Requirement Process, Robertson and20
Robertson
 Security Requirements: Type 15

Privacy:
The product shall prevent all personal and confidential
data from being printed.

The product shall deliver data in a manner that

prevents further or second-hand use by unauthorized
people.

Mastering the Requirement Process, Robertson and21

Robertson
 Security Requirements: Type 15

Integrity:

The product shall ensure its road temperature data

corresponds to the data transmitted by the weather
station.

Mastering the Requirement Process, Robertson and22

Robertson
 Security Requirements: Type 15

✦Auditing: consider normal auditing to be part of the

security section of your specification

Description: The product shall retain a journal of all

transactions for the statutory period.
Rationale: This is required by the auditors and is
required by applicable accountancy laws.



Mastering the Requirement Process, Robertson and23
Robertson
 Security Requirements: Type 15

✦Add no more …

The product shall allow access to authorized users.

The product shall ensure that only authorized users are

able to gain access.



Mastering the Requirement Process, Robertson and24
Robertson
 Cultural Requirements: Type 16

✦Spelling: The product shall use American spelling.

✦Political or cultural alignment: The product shall offer
the choice of language in the order appropriate for
the region of the country.
✦Political correctness: The product shall not use any
terms or icons that might possibly offend anyone on
the planet.
✦Religious observances: The product shall not display
religious symbols or words associated with
mainstream religions.

Mastering the Requirement Process, Robertson and25

Robertson
 Legal Requirements: Type 17

The product shall comply with the Americans with

Disabilities Act of 1990 as amended.

Warning. Do not use blanket as a hurricane shelter.

✦ Standards: The product shall comply with our ISO

9001 certification.

Mastering the Requirement Process, Robertson and26

Robertson
 Finding Non-Functional Requirements

✦ Use cases: consider the non-functional

requirements for each use case.
Description: The product shall appear familiar to
new engineers.
Rationale: We frequently have new junior engineers
and want the product to have an appearance that is
acceptable to them.

Description: The product shall produce a schedule

that is easy to read.
Rationale: It is important that only the correct roads
are treated.

Mastering the Requirement Process, Robertson and27

Robertson
 Finding Non-Functional Requirements

✦ Use cases: consider the non-functional

requirements for each use case.

The product shall enable the addition of new road

authority areas within two days.

Mastering the Requirement Process, Robertson and28

Robertson
 Finding Non-Functional Requirements

✦ Use cases: consider the non-functional

requirements for each use case.

Description: The product shall be self-supporting.

Rationale: The help desk will not be manned. There
will be no fellow users available to help.

Mastering the Requirement Process, Robertson and29

Robertson
Finding Non-Functional Requirements

Mastering the Requirement Process, Robertson and30

Robertson
 Do not write solutions

The product shall require a password to access

account data. This is not a correct way of writing
non-functional requirement

The product shall ensure account data can be

accessed only by authorized users.

Mastering the Requirement Process, Robertson and31

Robertson
 Chapter 12: Fit Criterion

✦ If you can’t measure a requirement, it is not really

a requirement.
✦ The rationale is not only a guide to help you find
the fit criterion, but also a means to help you know
when you have several different requirements
masquerading as one.
✦ You have to pass along a way to measure the
requirement’s real meaning.

Mastering the Requirement Process, Robertson and32

Robertson
 Chapter 12: Fit Criterion
✦ The fit criterion is an unambiguous benchmark that
the product is compared against.
✦ Fit criterion can be for use cases, project goals,
constraints, functional requirements, and non-
functional requirements.
✦ Description: The software part of the product must
run on Linux.
✦ Fit Criterion: All functionality of the software shall
operate as specified when run using Red Hat
Enterprise Linux 5.0.



Mastering the Requirement Process, Robertson and33
Robertson
Fit Criterion for Non-Functional
Requirements
Description: The product shall be cool.

Fit Criterion: Forty percent of the people who see the

product on display in a store pick it up.

✦ Even vague, ambiguous requirements can be

measured.

Mastering the Requirement Process, Robertson and34

Robertson
 Fit Criterion for Non-Functional
Requirements

✦ Branding standards.

Fit Criterion: The product shall be certified as

complying with this year’s corporate branding
standards by the head of communications.

Mastering the Requirement Process, Robertson and35

Robertson
 Fit Criterion for Usability and
Humanity Requirements


Description: The product shall be intuitive.

Rationale: The road engineers must find it easy and

intuitive; otherwise, they will not use it.

Fit Criterion: A road engineer shall be able to produce

a correct de-icing forecast within 10 minutes of
encountering the product for the first time without
reference to any out-of-product help.

Mastering the Requirement Process, Robertson and36

Robertson
 Fit Criterion for Performance
Requirements
Description: The response shall be fast enough to
avoid interrupting the user’s flow of thought.

Fit Criterion: The response time shall be no more than

0.5 second for 95 percent of responses, and no more
than 2 seconds for the remainder.

Fit Criterion: In the first three months of operation, the

product shall be available for 98 percent of the time
between 8 A.M. and 8 P.M.

Mastering the Requirement Process, Robertson and37

Robertson
 Fit Criterion for Operational
Requirements
Description: The product shall be used in and around
trucks at night, and during rainstorms, snow, and
freezing conditions.

Fit Criterion: The operator shall successfully complete

[list of tasks] within [time allowed] in a simulation of a
five-year storm and the product shall function correctly
after 24 hours’ exposure.

Fit Criterion: The product must comply with HTML5

standard as published April 2011 by W3C.
Mastering the Requirement Process, Robertson and38
Robertson
 Fit Criterion for Maintainability
Requirements

Fit Criterion: All functionality must be migrated to the

new website with no more than 10 minutes of
unavailability of the site.

Mastering the Requirement Process, Robertson and39

Robertson
 Fit Criterion for Security
Requirements

✦ Branding standards. If breach happens, you can say

your product complies to the standards.

Mastering the Requirement Process, Robertson and40

Robertson
 Fit Criterion for Cultural
Requirements

Fit Criterion: The Shatnez Laboratory of Brooklyn shall

certify that the product complies with the shatnez rules.

Fit Criterion: The communications department shall give

the opinion that the product displays no words or
symbols that could be construed as religious or political.

Mastering the Requirement Process, Robertson and41

Robertson
 Fit Criterion for Legal
Requirements

Fit Criterion: Your client will win a court case brought by

someone who uses the product.

Mastering the Requirement Process, Robertson and42

Robertson
 Fit Criterion for Functional
Requirements
✦ Make sure that your product successfully carried out
the action.
✦ In Agile development: Test cases can be written
before the code.
Description: The product shall record the weather
station readings.
Rationale: The readings are necessary for preparing
the de-icing schedule, and must be kept for audit
purposes.
Fit Criterion: The recorded weather station readings
shall be identical to the readings as recorded by the
transmitting weather station.
Mastering the Requirement Process, Robertson and43
Robertson
 Defining Data for Fit Criterion

✦ Use Data Dictionary.

✦ For the fit criteria to be complete, the specification
must contain definitions of the terms used in the fit
criteria.
✦ Road Section = Road Section Identifier + Road
Section Coordinates.
✦ Road Section Identifier = *Unique identifier for 500
meters of road. The maximum number of road
sections per road is 10,000.*

Mastering the Requirement Process, Robertson and44

Robertson
 COIS 3030
Lecture#13

Mastering the Requirement Process, Robertson and Robertson

 Quality Gateway
(Chapter 13)

✦ The Quality Gateway defends the specification against

unwelcome, unwanted, and undesirable requirements.
✦ To pass through the Quality Gateway and be included
in the requirements specification (remember the
specification does not have to be a formal, written
document), a requirement must pass a number of
tests.
✦ One main thing to check: if the product is within the
scope?

Mastering the Requirement Process, Robertson and46

Robertson
 Quality Gateway
(Chapter 13)

Mastering the Requirement Process, Robertson and47

Robertson
 Quality Gateway: Within Scope?
✦ Find if the data that is needed for the requirement is
kept by the work.
✦ The product shall pay truck drivers for working
overtime.
✦ There is no data flowing into the work to provide
information about drivers.

Mastering the Requirement Process, Robertson and48

Robertson
 Quality Gateway: Within
Scope?

✦ Description: The product shall record the hours that

the trucks are active.

Mastering the Requirement Process, Robertson and49

Robertson
 Quality Gateway: Within
Scope?
✦ Description: The product shall record the hours that
the trucks are active.
✦ Rationale: Trucks may not be scheduled for more than
22 out of 24 hours to allow for maintenance and
cleaning.
✦ Examine the rationale, find if the data that is needed
for the requirement is kept by the work.

Mastering the Requirement Process, Robertson and50

Robertson
 Quality Gateway: Relevancy
✦ Does this requirement contribute to the purpose of
the project?
✦ Description:The product shall maintain a lookup table
of the times of sunrise and sunset throughout the
year.
✦ Check if the requirement contributes to the project’s
goal.
✦ Project Goal: To accurately predict when ice will form
on road surfaces and to efficiently schedule the
appropriate de-icing treatment.
✦ In this example, although it can be relevant, the
temperature is recorded from weather stations.

Mastering the Requirement Process, Robertson and51

Robertson
 Quality Gateway: Relevancy

✦ Description: The product shall record the salt capacity

of the trucks.
✦ Rationale: Different trucks have different capacities.
The scheduling of trucks depends on their capacity to
treat the number of road sections predicted to have
ice formation.

Mastering the Requirement Process, Robertson and52

Robertson
 Quality Gateway: Relevancy
✦ When considering relevancy, pay particular attention
to the following sections of your requirements
specification:
✦ Users: Who are you building the product for, and is it a
product suitable for these users?
✦ Requirements Constraints: Is the product relevant
within the constraints? Have all the constraints been
observed by the requirements?
✦ Relevant Facts: Have the requirements failed to
account for any external factors?
✦ Assumptions: Are the requirements consistent with
any assumptions you are making 

about the project? 

Mastering the Requirement Process, Robertson and53
Robertson
Quality Gateway: Testing Completeness

✦ In Snow Cards:
Find any missing attributes.
Find if the attributes are meaningful to the
stakeholders.

Supporting Material: Specification of Rosa Weather

Station.
Supporting Material: Specification of DRS511 Rosa
Weather Station, release 1.1, published January 22,
2010.

Mastering the Requirement Process, Robertson and54

Robertson
 Quality Gateway: Fit Criterion

✦ Make sure that the requirement clearly specifies fit

criterion.
✦ Remember:
Description: The product shall be easy to learn.
Fit Criterion: A user shall be able to learn to process a
claim within 30 minutes of starting to use the product for
the first time.

Mastering the Requirement Process, Robertson and55

Robertson
 Quality Gateway: Consistent
Terminology

✦ Does the specification contain a definition of the

meaning of every essential subject-matter term within
the specification?
✦ Is every reference to a defined term consistent with
its definition?

Mastering the Requirement Process, Robertson and56

Robertson
 Quality Gateway: Viable within
Constraints
✦ Truck drivers shall receive weather forecasts and
schedule their own de-icing.
✦ This is not a realistic requirement.
✦ You have to check:
✦ Do you have the technological skills to build the
requirement?
✦ Do you have the time and the money to build the
requirement?
✦ Is the requirement acceptable to all stakeholders?

Mastering the Requirement Process, Robertson and57

Robertson
 Quality Gateway: Requirement or
Solution?

✦ The more abstract the requirement, the less likely it is

to be a solution.
✦ The product shall use JavaScript for the interface.
✦ The above requirement is too specific—it’s a solution.
✦ The product shall have a clock on the menu bar. —
solution.
✦ The product shall make the user aware of the current
time. —requirement.

Mastering the Requirement Process, Robertson and58

Robertson
 Quality Gateway: Requirement Value

✦ The customer satisfaction/dissatisfaction ratings

indicate the value that the customer places on a
requirement.
✦ Gold Plating: A low dissatisfaction rating indicates a
requirement that is probably gold plating.

Mastering the Requirement Process, Robertson and59

Robertson
 Quality Gateway: Requirement Creep

✦ Requirements creep refers to the process in which

new requirements enter the specification after the
requirements are considered complete.
✦ Creep can be costly. If they have high dissatisfaction
value, then they can be tolerated.
✦ Most creep occurs because the requirements were
never gathered properly in the first place.

Mastering the Requirement Process, Robertson and60

Robertson
 Implementing Quality Gateway

✦ Start your Quality Gateway with two people—perhaps

the lead requirements analyst and a tester. This
gateway is meant to be a fast, easy test of
requirements, not a laborious process involving half of
the development team.
✦ The use of automated tools can help to reduce the
amount of human intervention in the Quality Gateway
process.

Mastering the Requirement Process, Robertson and61

Robertson
 Implementing Quality Gateway
✦ Start your Quality Gateway with two people—perhaps
the lead requirements analyst and a tester. This
gateway is meant to be a fast, easy test of
requirements, not a laborious process involving half of
the development team.
✦ The use of automated tools can help to reduce the
amount of human intervention in the Quality Gateway
process.
✦ In “buddy pairing,” requirements analysts test each
other’s requirements.

Mastering the Requirement Process, Robertson and62

Robertson