Non Fuctional Requirements White-Paper-Riti Agarwal

8/3/2019 Non Fuctional Requirements White-Paper-Riti Agarwal

1/16

This paper was submitted for eWORLDFORUM 2011 conference Page 1

NON FUNCTIONAL REQUIREMENTS WHITE

PAPER/GUIDEBOOK

The Guide to Analysis and Design of

Non-functional requirements


2/16

This paper was submitted for eWORLDFORUM 2011 conference Page 2

TABLE OF CONTENTS

Introduction ........................................................................................ 1

Effectiveness ....................................................................................... 2

Efficiency .............................................................................................. 3

Disaster Recovery and High Availability ................................. 4

Maintainability ................................................................................... 5

Reliability.............................................................................................. 6

Availability ........................................................................................... 7

Scalability ............................................................................................. 8

Performance and Time Response............................................... 9

Compatibility / Interoperability .............................................. 10

Usability ............................................................................................. 11

Documentation ................................................................................ 12

Robustness ........................................................................................ 13

Conclusion ......................................................................................... 14

Useful information ......................................................................... 14


3/16

Non-functional Requirement white paper

1 | P a g e

INTRODUCTION

80% of the requirements for success of a project are Non-functional requirements; the remainder is the specification

of functional requirements. Why is it that analysts spend the more than 90% of their time documenting functional

requirements at the cost of the non-functional? It is ironic that for a system to be fully functional, it is dependent on

non-functional requirements. There are two components to non-functional requirements; the hard and the soft

capabilities.

Given some of the focus of Business Analyst training, guidelines and methodology, non-functional requirements are

seldom well documented.

I have put together this short, concise guide booklet to serve as a entry-point for business analysis. Since system

projects have a high dependence on technology systems, incorrect specification of non-functional requirements have a

huge impact on solution success.

Purpose of Document

Guide books by nature are never fully comprehensive; it is not a definitive document. This booklet serves as a

pragmatic direction tool, a compass. It helps analysts navigate. Since each project is a new distinct journey, the white

paper serves as a checklist and a reference tool. The final tweaks and alignment in a project depends on the skill of the

analyst. As the analyst continues to use this tool, individuals skills will be honed. More use means more competence.

To ensure ongoing learning it is imperative that this booklet evolves as the team becomes more adept with non-

functional requirements definition and testing.

This document is not an original piece of work. Major portions are extracted from various sources. It was always the

intention to produce a piece of work, without over-engineering the research process, to provide quick high-valuebenefit at the least cost and time.

This end result serves that purpose well.

Document Audience

Business Analysts, Project Managers, Architects and Developers, Change Managers and Testing personnel will find this

document useful during conceptual definition, project analysis and design, build and deployment stage.

While this document was intended for the growth and development of the Business Analysts, it is appropriate for

other roles as well.


4/16


2 | P a g e

EFFECTIVENESS

DefinitionEfficiency is about process - the use of resources and

energy such as people, technology, production, waste

management and energy management, including

output and productivity.

Effectiveness is about outcome, impact and quality -

how well the solution addresses the problem, how

well the product works, how well the person fulfils

their role, including cost effectiveness and value for

money.

Effectiveness focuses primarily on doing only what

will bring about a goal. If a plan includes an action that

would entail a waste of resources in which the desiredgoal is not possible to be achieved, then the theory of

effectiveness would eradicate

EFFICIENCYmeans: saving TIME, MONEY or

EFFORT

EFFECTIVENESSmeans how well the job gets

done. i.e. the quality of the output

Focus Areas

Production (maximising productivity) Process extent to which the process is

effective in producing the desired outcomes.

Operations in order to support the system,to what extent is the business and support

operations capable and competent to deliver

adequate capacity to run and maintain the

processes and infrastructure.

Example 1:

A company could spend millions of dollars on

commercials and billboards to get a product out there- being effective but not efficient. That same company

could make a silly viral video and "leak" it for free on

the internet or any number of guerilla marketing

tactics. That would be efficient, but may not be totally

effective.

Example 2:

Rolls-Royce value effectiveness over efficiency: to

them, quality is everything, and they sacrifice

efficiency to achieve it.


5/16


3 | P a g e

EFFICIENCY

DefinitionEfficiency is a measure of time, cost and effort.

Measures of an efficient information system include

its productivity, processing time, operational costs

and level of automations.

Focus Areas

Measurement of efficiency

In order to determine the efficiency of a system,

metrics should be in place. Metrics are detailed

measures that feed Key Performance Indicators (KPI).

Efficiency IT metrics measure the performance of an

IT system. An effective IT metrics program should

measure many aspects of performance including

throughput, speed, and availability of the system.

There should also be an organized way of

documenting and reporting the findings of efficiency

IT metrics. Although measuring efficiency of an IT

system is important for evaluating and improving

performance of an IT system, it is also important to

make sure that an IT system is being utilized in a

proper way to ensure effectiveness of business

processes and is also in line with business objectives.

Ease to use

To help the organization to increase efficiency and

reduce costs the system solution that is chosen should

easily intergrate with business processes and provide

an easy to use solution

Level of support

The level of support determines how efficient is the

system. Support includes both people and system.

Some systems can be fully automated but complicated

in such a way that staff members needs added support

. Such a system cannot be classified as efficient. Also if

the system itself required a lot of support being itphysical or monetary it is not efficient.


6/16


4 | P a g e

DISASTER RECOVERY AND

HIGHAVAILABILITY

DefinitionThe DR Plan indicates the exact steps to be taken by

business to recover from any type of disaster. The

plan would encapsulate relocating employees to

getting a copy of your data restored immediately on a

fully functioning server located off site in order to

continue normal business operations.

A High Availability (HA) solution must provide

uninterruptible service (24/7). Each HA solution may

include identical pairs of servers, firewalls, switches,

routers, etc. If one of these hardware devices fails, the

backup unit must seamlessly kick-in and service must

not be interrupted. This process is known as failover.

Focus areas

SLA defining explicit uptime and performancelevels and specific remittance for under

compliance

o Mean time to recovery i.e. basic and fullrecovery

o Mean time between failureso Required availability percentage i.e. how

much of outage time can be tolerated

over a period of time

o Planned restrictions schedule i.e. howoften and for how long planned

maintenance activity can interfere with

full, unencumbered availability.

o DR Mode performance tolerance i.e. howmuch performance degradation the

business can deal with and for how long -

after failing over to a secondary DR site.

o Max and min decision time i.e. how muchtime occurs before deciding on therecovery solution for the crisis situation

Criticality for HAo Mission critical e.g. internet, POS, support

services

o Business critical e.g. payroll, procuremento Business critical Business intelligence e.g.

supply chain intelligence

Responsibilities Organizational practices and standards Disaster recovery drills System backup and restore procedures Data and system level recovery

Alternative practices and fail-over plans


7/16


5 | P a g e

MAINTAINABILITY

DefinitionA characteristic of design and installation, expressed

as the probability that an item will be retained in or

restored to a specified condition within a given period

oftime, when the maintenance is performed in

accordance with prescribed procedures and

resources.

Maintainability is a design parameter and it is used to:

correct defects meet new requirements make future maintenance easier, or cope with

a changed environment;

Maintainability is about a product's ability to stay the

same or to adapt to change and is a compared-to-

what question.

Focus AreasMaintainability is the ability of an item to be

maintained, whereas maintenance constitutes a series

of actions necessary to ensure an item or items is

restored or retained in an effective operational state.

Key aspects of maintainability include updating

documentation pertaining to a product or service,

through making necessary corrections and

enhancements to documents as changes are made. It

also includes continuous testing of item/s ensuring

that maintainability occurs.

SBSA specific IssuesMaintainability issues within SBSA include (but are

not limited to) the following:

Work is never updated and a gap begins toemerge. Documents become less and lessuseful as it falls out of sync with the product.

Within the SBSA environment this is most

clearly seen with regards to FSSs. The

product changes but the specification

describing the product is still describing the

very first version of the project.

Lack of experience (People who did the workhave left SBSA due to being consultants etc).

Expensive maintainability is not part of thebudget, and therefore not carried out.

Design flaw. The original project scope paidlittle or no attention to including

maintainability as a factor. Meaning that

project stakeholders overlook it.
http://www.its.bldrdoc.gov/fs-1037/dir-037/_5459.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-022/_3199.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-022/_3199.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-037/_5459.htm


8/16


6 | P a g e

RELIABILITY

DefinitionReliability pertains to how hardware, software and

operators consistently perform or under perform

under different scenarios and situations. Reliability is

divided into 3 categories

Hardware reliability

Is theprobability of a hardware component failing?

Software reliability

Is the probability that the software system will

function properly withoutfailure over a certain time

period.

Operator reliabilityIs the probability that a system user (or operations

support) will make an error

Focus Areas

Thorough testing Extensive training of users Investment in high quality products Follow good design principles

Hardware Reliability Metrics

Hardware components can wear out. This could result

in failure. The intent is to measure the time that the

component is operating (uptime) before it fails i.e.

Mean Time Between Failures (MTBF). This will assist

in proactive maintenance schedules, ensuring

maximum uptime.

Software Reliability Metrics

Design and Code Reliability Metrics

It is generally accepted that more complex modules

are more difficult to understand and have a higherprobability of defects than less complex modules.

Design and code metrics are quite technical e.g.

Weighted Methods per Class (WMC) is a predictor of

how much time and effort is required to develop and

maintain the class. The higher the WMC, the more

testing is necessary.

Testing Reliability Metrics

Testing metrics must take two approaches to

comprehensively evaluate the reliability. The first

approach is the evaluation of the test plan, ensuring

that the system contains the functionality specified in

the requirements. This activity should reduce the

number of errors due to lack of expected functionality.

The second approach, one commonly associated with

reliability, is the evaluation of the number of errors in

the code and rate of finding/fixing them.

Specific SBSA Issues

No or poorly defined non functional requirementspertaining to reliability

Lack of adequate redundancy and recoverymechanisms result in failures with serious

consequences

Insufficient focus placed on adopting good designprinciples due to project delivery time pressures

Lack of validation of reliability NFR, after projecthas been implemented to ensure NFR has been

met.


9/16


7 | P a g e

AVAILABILITY

DefinitionAvailability is the proportion of time a system is in a

functioning condition. The ratio of (a) the total time a

functional unitis capable of being used during a given

interval to (b) the length of the interval (eg. 99.5%)

Availability indicates when a system is operational as

well as how reliable it is during operational periods.

Focus area

Hours of operationLength of the interval for which the system should run

.What are the hours that a given system will be

available?

Days of operationWhat days will the system be operational? Not allsystems operate on a 24/7 basis. Some internal facing

systems may only be needed when there are people in

place to operate them.

ReliabilityIs the consistency of your measurement, or the degree

to which a System measures the same way each time.

Focus area for NFR is during a system's hours of

operation, what reliability is needed?

The higher the number, the greater is the cost.

Cost of running systemAn amount paid for making the system available for

the parameters defined in other Non Functional

Requirements such as Hours/days of operation,

Reliability, speed etc.

Internal Support required operating the

system What support will be given to keep thesystem available according to the Hours/days of

operation and reliability parameters defined

Vendor Support required operating the

system (If system is outsourced)

What support will be given by Vendor/OutsourcingCompany to keep the system available?

Maximum acceptable time for starting the

systemWhat will be the turnaround time for a system to start

up?

Budget available to operate the systemBudget approved by management to operate the

system plays a major role to determine theparameters to be decided for Availability. 365x24x7

costs dearly!

SBSA Specific issues1. System unavailability- Some systems not

available when there are people in place to

operate them.

2. Vendor support unavailability -Vendor maynot provide support to keep the system

available according to the parameters defined

in other Non Functional Requirements such

as Hours/days of operation, Reliability, speed

etc.

3. Systems operate on a 24/7 basis- Someinternal facing systems may only be needed

when there are people in place to operate

them.

4. Slow response times during operating times-Systems response times affect service to

customers, staff morale and work throughput.
http://en.wikipedia.org/wiki/Functional_unithttp://en.wikipedia.org/wiki/Functional_unit


10/16


8 | P a g e

SCALABILITY

DefinitionScalability is a desirable property of a system, a

network, or a process, which indicates its ability to

either handle growing amounts of work in a graceful

manner or to be enlarged.

Focus areasThe concept of scalability applies to technology as

well as business settings. The base concept is

consistent - The ability for a business or technology to

accept increased volume without impacting the

contribution margin (= revenue - variable costs). For

example, a given piece of equipment may have

capacity from 1-1000 users, and beyond 1000 users,

additional equipment is needed or performance will

decline (variable costs will increase and reduce

contribution margin).

Scalability can be measured in various dimensions,

such as:

Load scalabilityIt is the ability for a distributed system to easily

expand and contract its resource pool to

accommodate heavier or lighter loads. Alternatively,

the ease with which a system or component can be

modified, added, or removed, to accommodate

changing load.

Geographic scalabilityIt is the ability to maintain performance, usefulness,

or usability regardless of expansion from

concentration in a local area to a more distributed

geographic pattern.

Administrative scalabilityIt is the ability for an increasing number of

organizations to easily share a single distributed

system.

Functional scalability:It is the ability to enhance the system by adding new

functionality at minimal effort.

Scale vertically (scale up)

To scale vertically (or scale up) means to add

resources to a single node in a system, typically

involving the addition of CPUs or memory to a single

computer.

Scale horizontally (scale out)

To scale horizontally (or scale out) means to add more

nodes to a system, such as adding a new computer to a

distributed software application. An example might be

scaling out from one web server system to three.


11/16


9 | P a g e

PERFORMANCE AND TIME

RESPONSE

DefinitionTraditionally, response time is often defined as the

interval from when a user initiates a request to the

instant at which the first part of the response is

received at by the application.

However, such a definition is not usually appropriate

within a performance related application requirement

specification.

Key ConceptsThe definition of response time must incorporate the

behaviour, design and architecture of the systemunder test.

Time to display order details

Average time to display order details less than 5.0

seconds.

90th percentile time to display order details less

than 7.0 seconds.

The above specification, or response time service level

agreement, is a reasonably tight specification that is

easy to validate against.

The following form part and parcel of the performance

and response time testing

Types of tests: Loads tests, Failover tests, Soak tests,

Stress tests, Targeted infrastructure tests,

Performance tests, Network sensitivity tests, Volume

tests (Sociability sensitivity Tests, Tuning Cycle Tests,

Protocol Tests, Thick Client Application Tests, Thin

Client Application Tests)

Application


12/16


10 | P a g e

COMPATIBILITY/

INTEROPERABILITY

Description:If products designed for the new standard can receive,

read, view or play older standards or formats, then the

product is said to be backward-compatible. The

reverse is forward compatibility, which implies that

old devices allow (or are expected to allow) data

formats generated by new (or future) devices,

perhaps without supporting all new features. A

standard supports forward compatibility if older

product versions can receive, read, view or play the

new standard.

Key Concepts:These requirements address the need for the product

to interface with other applications or systems

without interfering with the operation of those other

applications or systems. They may consider or specify:

Named applications or systems with which to

interface

Messaging format, medium, and content

Compatibility with products from different vendors

Conversion requirements for hardware,

applications, or data

Middleware architecture Messaging and transmission protocols

Frequency

Multiple time zones

Process timing and sequencing


13/16


11 | P a g e

USABILITY

DefinitionUsability is generally acknowledged as a factor of

system quality representing the answer to many

interactions with technology. It describes the quality

of products and systems from the point of view of

humans who use them.

Usability is crucial to create websites that your

customers will want to return to. If they cant use the

site, they wont stay.

Focus Area

Visibility of system status

The system should always keep users informed aboutwhat is going on, through appropriate feedback within

reasonable time. Probably the two most important

things that users need to know at your site are "Where

am I?" and "Where can I go next?" Instructions for use

of the system should be visible or easily retrievable.

Match between system and the real worldThe system should speak the users' language, with

words, phrases and concepts familiar to the user,

rather than system-oriented terms. Follow real-world

conventions, making information appear in a natural

and logical order.

User control and freedomUsers often choose system functions by mistake and

will need a clearly marked "emergency exit" to leave

the unwanted state without having to go through an

extended dialogue.

Consistency and standardsUsers should not have to wonder whether different

words, situations, or actions mean the same thing.

Follow platform conventions.

Error preventionError message is a careful design which prevents a

problem from occurring in the first place. Error

messages should be expressed in plain language (no

codes), precisely indicate the problem, and

constructively suggest a solution.

Help and documentationEven though it is better if the system can be used

without documentation, it may be necessary to

provide help and documentation. Such information

should be easy to search, focused on the user's task,

list concrete steps to be carried out, and be concise.

TrainingUsers need to be trained before they can start using

the system and be provided with training manuals

which they can always refer to when using the system.

SBSA specific issues

1. Page Layout and Content-If customers don'tfind relevant content quickly; they will be

more likely to leave. Keep your pages clean

and simple. Try removing elements, and see if

your page needs them, if the page functionswithout them - take them out.

2. Download speed-After 10 seconds; yourcustomer has lost interest in your page, no

matter how interested they were in the topic.

3. Advanced Technology Usage-The bestsolution is to avoid beta-level technology until

it has been in use for at least one year.


14/16


12 | P a g e

DOCUMENTATION

DefinitionNon Functional requirements documentation is the

communicable material that details the system

architecture. It explains how the system is supposed

to be rather than do. It also references documentation

that forms part of the development which contains the

all the impacted areas of the system development and

implementation. The questions that one should ask is

what kind of documentation are required and what

audience is to be addressed by each document.

Focus Areas

Project Overview

Project Overview contains a summary of known majortechnical constraints. Add these to the non-functional

requirements document and update the project

overview with references to them.

Stakeholder Needs ListThese are single line statements of needs gather early

in the project from all stakeholders. Scan through the

list and look for those needs that would not have been

included in the use case documents. Add them to the

appropriate section of the non-functional

requirements documents as single sentencestatements. Update the stakeholder needs list with the

reference to the requirement in the non-functional

requirements document.

Business Process ModelWhen the business process model is created notes

may have been added to the processes as attachment

to activities on activity diagrams regarding

stakeholder requirements as they have been

mentioned by the stakeholder representative or

process owner.

Hint: Search all relevant activities for notes relating to

non-functional requirements and add them to the

non-functional requirements document. Update the

activity notes with the reference to the requirement in

the non-functional requirements document.

Use Case ModelUse Case Documents have a specific section for non-

functional requirements. These should normally apply

specifically to the use case in question. It may be,

however, that requirements that apply across more

than one use case have been included. If so, add the

requirements to the non-functional requirements

document and reference them in the use case

document.

SBSA Specific Issue1. Unavailability of SBSA structural information,

such as infrastructure architecture and

organization structure makes it difficult to do

impact analysis.

2. Standard methodology that should beenforced and implemented to ensure

elimination of loop hole.


15/16


13 | P a g e

ROBUSTNESS

DefinitionRobustness is the quality of being able to withstand

stresses, pressures, or changes in procedure or

circumstance. A system or design may be said to be

"robust" if it is capable of coping well with variations

(sometimes unpredictable variations) in its operating

environment with minimal damage, alteration or loss

of functionality.

Robustness is defined as the degree to which a system

operates correctly in the presence of exceptional

inputs or stressful environmental conditions

Robustness testing is a testing methodology to detect

vulnerabilities of a component under unexpected

inputs or in a stressful environment.

Focus Areas"Happy-path testing" (that is, testing that is only

meant to show that the system meets its functional

requirements). While testing to ensure that

requirements are met is necessary, often tests aimed

at ensuring that the system handles errors and

failures appropriately are neglected

Robustness testing is known by many different names.Many of these are equivalent, and some are used to

define a specific type of robustness testing. Many of

these terms are defined below.

Adhoc testing: a testing phase where the tester tries

to break the system by randomly trying the systems

functionality. This can include negative testing.

Boundary value analysis/testing: an analysis that

focuses on corner cases or values that are usually

out of range as defined by the specification. This

means that if a function expects all values in the range

of negative 100 to positive 1000, test inputs would

include negative 101 and positive 1001.

Compatibility testing: testing whether software is

compatible with other elements of a system with

which it should operate (e.g., browsers, operating

systems, or hardware)

Endurance testing: checks for memory leaks or other

problems that may occur with prolonged execution

End-to-end testing: testing a complete application

environment in a situation that mimics real-world use

(such as interacting with a database, using network

communications, or interacting with other hardware,

applications, or systems, if appropriate)

Exhaustive testing: testing that covers all

combinations of input values and preconditions for an

element of the software under test

Exploratory testing: Exploratory testing has several

uses: the one that is germane to robustness testing is

to provide rapid feedback on a products quality on

short notice, with little time, without advance thought,

or early in development when the system may not be

stable.Negative testing: testing aimed at showing that

software does not work. This is also known as test to

fail or dirty testing.


16/16


14 | P a g e

CONCLUSION

Non-functional requirements definition and design done early in the SDLC pre-empts flaws and inherent constraints

in the business and technical systems. With careful consideration, looking at the various aspects this whitepaper will

ensure that a more comprehensive solution is created.

This document will guide Business Analysts through the SDLC process indicating NF touch points, roles,

responsibilities, artefacts and deliverables. As the team grows, and the skill of the team grows, this document will

evolve and provide a useful tool for the work of Business Analysts.

USEFUL INFORMATIONThe following list provides some details that supplement the categories listed in this whitepaper.

Accessibility Archiving and backup strategy Audit and control

Auditability Availability (see service level

agreement)

Backup

Back-up and store Capacity, current and forecast Certification

Compliance Configuration management Conversion

Data Purification Content and Data Retention/Purging Dependency on other parties

Escrow Extensibility (adding features, and

carry-forward of customizations at

next major version upgrade)

Failure management

Flexibility/customizability Global/Geographical reach Integrity

Legislation that requires conformance Legal and licensing issues or patent-

infringement-avoidability

Longevity

Modifiability Network topology Open source

Operability Physical environment Platform compatibility

Portability Price PrivacyQuality (e.g. faults discovered, faults

delivered, fault removal efficacy)

Recovery / recoverability (e.g. mean

time to recovery - MTTR)

Reliability (e.g. mean time between

failures - MTBF)

Resilience Resource constraints (processor

speed, memory, disk space, network

bandwidth etc)

Resources and Management issues

Safety Security Software, tools, standards etc.

Supplier contracts and SLAs Technical or organizational

standards compliance

Testability

Non Fuctional Requirements White-Paper-Riti Agarwal

Documents

Transcript of Non Fuctional Requirements White-Paper-Riti Agarwal