Non-Functional Requirements

Notes taken from:

Object Oriented Software Engineering text;
Art of Software Architecture (Stephen Albin)
Use Case Analysis (Bittner and Spence);
Use Cases Requirements in Context (Kulak and Guiney)
Some notes from Rational Software Corporation slides
Other personal notes

36

Use-Case Analysis Steps Heres

where we are:

Supplement the Use-Case Descriptions

For each use-case realization
Find Classes from Use-Case Behavior
Distribute Use-Case Behavior to Classes
For each resulting analysis class
Describe Responsibilities
Describe Attributes and Associations

Non-Functional Requirements

We have a:

good understanding of the nature of the

analysis classes and their responsibilities

collaborations required to support the

functionality described in the Use Cases via
analysis classes

Need to address the non-functional requirements

IBM-Rational calls these analysis
36 mechanisms.2

Non-Functional Requirements

The purpose of identifying non-functional

requirements is to get a handle on these
absolutely necessary requirements that are
normally not functional.

During Analysis, this information is

speculative.
Will be refined later.
Philosophy: Capture now; Realize later
(Essential points in design)

36

Non-Functional Requirements
OOSE Text p.115-

36

Types of Requirements

Functional
Describe

requirements

what the system should do

Non-functional

requirements

Consists

of Constraints that must be

adhered to during development (design
and implementation)
Operative word: Constraints.

36

Functional requirements
What

inputs the system should accept

What

outputs the system should produce

What

data the system should store that other

systems might use

What
The

computations the system should perform

timing and synchronization of the above

36

Non-Functional requirements

Mostly not unique to a single use case.

Generally thread themselves throughout
some use cases

Transcend locality

Some of these conflict with each other

Some support efficiency of code and
inefficiency in maintenance
Lets contrast functional and non-functional
requirements
36

Non-functional Requirements
Verifiable; Measured
All

requirements must be verifiable

If

not verifiable then there is no indications that these

requirements have been satisfied.

Some

must also be measured.

Some

requirements are measurable, such as response time;

availability time, etc.
Some may be directly measured; some measured via
simulation.
We

parse the non-functional requirements into categories

36

Categories of Non-Functional Requirements

1. Quality Non-Functional Requirements (1 of 2)

All constrain the design to meet desired quality levels of usability,

efficiency, reliability, maintainability and reusability
Examples:
Response time particularly important for processes that process a
lot of data or use networks a great deal.
Requirements might stipulate < two second response.

Might use a Timing bar indicating progress

Response time may be considered a functional requirement for

some real time systems.

Throughput for computationally-intensive applications or for heavy

transaction-oriented systems, the number of transactions per minute
or number of computations per minute can/must be measured.

Resource usage Application cannot use > xxMB of memory

Very practical in a large multiprogramming / multiprocessing system.

36

Categories of Non-Functional Requirements

1. Quality Non-Functional Requirements (2 of
2)

Reliability typically Mean Time Between Failures (MTBF)

(number of failures per week; define failure.)

Availability Measures the time application is up and the

period of down time, when down.

Recovery from failure Mean Time To Repair: (MTTR)

critical to some applications; not so for others; checkpoint
restarts; auto-saves, etc. If you specify the detailed
procedure to follow, then this is a functional requirement.

Allowances for Reusability may specify that a certain

percentage of the system must be designed generically to
support reusability

36

10

Categories of Non-Functional Requirements

2. Environment and Technology Constraints

Platform

What hardware / software the software must

be able to work on.
Normally indicate least platform
e.g.
Windows XP, Vista; 120 MB free disk
space.

Technology to be used

Programming language; database system. All

individuals are familiar with these languages /
database nuances.
May/may not reduce need to train people

36

11

Categories of Non-Functional Requirements

3. Project Plan and Development Methods

Development Process/Methodology

This may be specified and will greatly impace

development.
SDLC; RUP; Agile Methods, Scrum; XP, Feature-Driven
Development (FDD), etc.
Particular approaches to testing (done by separate
group; Where in supervisory chain?
References to these must be included; not the details

Cost and Delivery Dates; Traceability

A Bigee!! Usually a very important constraint.

Usually found in the Contract for the system or in a
separate project plan.

36

12

Random Thoughts - Non-functional

Requirements
Not

always clear that a requirement is non-functional and

functional.
If requirement is a fundamental part of the applications
functionality, then it should be stated as a functional
requirement
Think performance of a real time / manufacturing app.
Think reliability of a safety-critical application

If

requirement is a constraint on design or some kind of

restriction on design, then the requirement is almost
always non-functional.
Certainly the presented list is not exhaustive!

36

13

Quality Models Many and Varied (1 of 2)

Quality Models from a different source:

from Art of Software Architecture (p.70-72)
Note the different categories for Quality Modeling
according to this source:
Product Operation Quality:
Accuracy, Reliability, Efficiency, Integrity, and
Usability
Product Revision Quality are:
maintainability, flexibility, testability
Product Transition Quality are:
Interface facility, reusability, transferability
36
14

More attributes(2 of 2)

According to Barry Boehm: Overall quality is a function of

these metrics:

Laurence Bests Application Architecture identifies:

Validity, clarity, understandability, modifiability, modularity,

generality, economy, resilience, documentation

Accuracy and comprehensiveness; simplicity of use,

operational flexibility, ease of development, maintenance and
extension, security and control, resource efficiency, recovery

And there are numerous other lists..

These are presented to show you that there are different
takes on quality and what determines quality

36

15

Looking down on these(1 of 2)

Functional models such as use cases, typically drive object-oriented

projects (although they certainly dont have to)

Attributes such as modifiability are not easily expressed in

purely object-oriented terms and need supplemental text
descriptions to represent the design.

Each attribute MUST be considered during design and usually

requires the architect to make multiple passes as a design.

Class design: start by addressing functionality only

Second pass to incorporate modifiability constraints while making sure

that the functionality is not compromised.

Sometimes, multiple passes are needed to incorporate various

requirements and to evaluate the design tradeoffs.

How can these methods be efficient and yet maintainable?

Efficient and yet reusable?
Reusable yet modifiable?
36

16

Looking down on these(2 of 2)

Many competing non-functional requirements.

Architect must find a design that realizes a balance among
them.
Example:

Performance design techniques, however, usually incorporate

fewer levels of indirection and optimizations to data structures in
order to improve operation execution times.
Performance gains may bring decreased maintainability /
reusability features.
Cost is usually competing with everything else and it is common
that usability is sacrificed first!

36

17

Where are Non-Functional

Requirements Captured / Modeled?

Use Case Modeling Bittner and Spence p. 43

In the RUP,
RUP we place the non-functional requirements in the
Supplementary Specifications
But this is usually considered a standard..

Consider:

Legal and Regulatory Requirements

e.g.: The system must be available at least 90% of the time.

Constraints placed on the design and implementation of the system

such as operating system, environments,

e.g.: The system must be developed in accordance with the Rational

Unified Process

Quality attributes of the system to be built must include usability,

reliability, performance, supportability requirements

e.g.: The customer must be of legal age to purchase alcohol.

Application Development Standards

(Bittner and Spence: different categories!!!)

e.g.: The system must be written in Java 2.

Others

36

18

Supplementary Specifications

Very misleading to think supplementary specs are

inferior or lesser than functional specs.
Many projects have run amuck because they did not consider
these requirements.
May have formed a major part of the overall critical success
criteria.
Consider the following problems / results:

E.g. System must support 300-500 simultaneous users; On

entry into user acceptance testing, system supported eight
simultaneous users; Developers had concentrated on the user
interface and completely ignored this supplementary spec item.
Upon further review, it was noticed that the developer did not
investigate any of the requirements beyond the scope of the
most basic flow of events.
Not surprisingly, the system was never deployed.

36

19

Supplementary Specifications
Complement to Use Cases

Note use cases can capture non-functional requirements especially those

that apply within the context of a single use case.

Use Supplementary Specs to capture non-functional requirements that are

global in nature or do not vary from one use case to the next.

Within the Use Case: Typically, if the amount of interaction in use cases is
large, the majority of requirements will be captured here and there may be just a
few, global, non-functional requirements.

Within the Supplementary Specifications: Conversely, if the amount of

interaction in the use case is small, then the majority of requirements may be
captured as non-functional requirements and found in the Supplementary
Specifications.

Keep a balance between using the use cases and non-functional requirements.

We need both if the overall requirements objectives are to be met.

36

20

Non-Functional Requirements the Process

Use Cases Kulak and Guiney

Identify the non-functional requirements

Validate with appropriate stakeholders
Document the requirements
Capture its name, its effect, both the system and
business degradation that would result if the
requirements are not satisfied
Best time to capture them when exploring the
functional requirements
Document it right away from your sources of
information (interviews, questionnaires, )
Ask users about response times, what bothers them
now; what is fine.
Be certain to differentiate between business-related
concerns which can often be added to a use case
description, with non-functional requirements.

36

21

Non-Functional Requirements the Process

Rank the non-functional requirements. Very Important!

Sometimes accommodating non-functional requirement

may cost more than implementing the use case.

There is no free lunch, and some things are not worth

the cost to accommodate.

e.g. Infinite availability; levels of performance. Dont let

[a users] initial assumptions drive you into an architectural
nightmare.

Use a template to document the non-functional

requirements, as found in our Use Case book, ~ p. 79.

36

22

Use something like the table below.

You may add column attributes as needed.
NonFunctional
Category*

Number

Non Functional
Requirement Name

Description

Applies to Use
Case(s):

Exceptions

You may wish to categorize these (or not). If not, omit column.
36wish a priority column!
23
You may also wish to add columns. You may

Examples
NonFunctional
Category*

Number

Non Functional
Requirement Name

Description

Applies to Use
Cases:

Exceptions

Persistency

Student objects need

to be persistent

Where Student
Objects are
Updated

None

Security

System Administrator
actor needs to be
authenticated

Those Use
Cases that
access the
Profile Database

None

Availability

The Profile Database

must be available 95%
of the time

All Use Cases

that require
authentication

None

36

24

Supplementary Specifications

Inserted table(s) into Supplementary Specifications.

The Supplementary Specifications document

constitutes an additional artifact that we will be
using.

Note also that in some cases, the non-functional

requirements are called analysis mechanisms (RUP)

Have persistency mechanism; security mechanism, etc.

Means that there will be some process to accommodate
persistency, security, etc.

36

25

Analysis Classes Use of tags { }

Non-Functional Requirements Map UML

As analysis classes are identified, it is important to identify the

non-functional requirements that might apply to them
Classes that must be persistent are mapped to the Persistency
Mechanism and tagged as persistent. Persistency tag: {persistent}
Classes that are maintained with the Legacy Course Catalog
system are tagged to the Legacy Interface mechanism;
Classes for which access must be controlled (like who can read
and modify instances of the class) are mapped to a Security
mechanism., etc. {security} or {secure mechanism}
Distributed classes mapped to a Distribution mechanism, etc.)
(Often control classes are distributed.) {distributed}

36

26

Use-Case Analysis Steps

Supplement the Use-Case Descriptions

For each use case realization
For each Analysis Class describe

responsibilities, etc.

..

Know (now) about analysis classes

their responsibilities,
the analysis mechanisms / non-functional requirements that these
analysis classes need to implement (persistence, security, legacy,
) and
the collaborations required to support the functionality described
in the use cases.

Unify Analysis Classes: Now lets review everything to

ensure it is complete and consistent before moving on.

Checkpoints

36

27

Unify Analysis Classes

The purpose of Unify Analysis
Classes activity is to ensure that
each analysis class represents a
single well-defined concept, with
non-overlapping responsibilities.
Name of analysis class should capture
role; (e.g. EnrollmentForm)
Description of class should capture
role played by class in the system.
Merge classes that define similar
behavior or represent the same thing.
Merge entity classes that define the
same attributes
Aggregate behaviors of merged
classes.
If you do any of these things, make
sure you update any supplemental
use case descriptions where
necessary.

<<boundary>>

<<control>>

<<entity>>

36

<<entity>>

28

Evaluate Your Results

Glossary

Analysis Classes
Supplementary
Specification
Are
Are
Are
Are
Are

the Names appropriate?

the Descriptions accurate?
classes that should be merged actually merged?
appropriate entity classes merged?
aggregations captured?
36

Use-Case Model29

Evaluating and Verifying

Now, verify analysis classes meet functional requirements of the

system.

Trace down through the Use Case specifications for each Use Case.
Are all responsibilities covered? Are domain / application objects
captured? Properties?

Verify the analysis classes and their relationships are consistent with
collaborations that they may support.

If one class is sending messages to another, there is a collaboration needed. If

one class defines an array of objects from another class, have we modeled this
as an aggregation! etc.

Very important that you evaluate your results at the conclusion of Use
Case Analysis.

36

30

Use-Case Analysis Steps

Supplement the Use-Case Descriptions

For each use-case realization

For each resulting analysis class

Find Classes from Use-Case Behavior

Distribute Use-Case Behavior to Classes
Describe Responsibilities
Describe Attributes and Associations
Qualify Analysis Mechanisms

Unify Analysis Classes

Checkpoints - Check the quality of the model
against criteria that the Designer looks for

36

31

Checkpoints: Analysis Classes

Are the classes reasonable?

Does the name of each class clearly reflect the
role it plays?
Does the class represent a single well-defined
abstraction?
Are all attributes and responsibilities
functionally coupled? (What does this mean to
you?)
Does the class offer the required behavior?
Are all specific requirements on the class
addressed?

36

(continued)

32

Checkpoints: Analysis Classes

Note: All checkpoints should be evaluated with regards to

the use cases being developed for the current iteration.

The class should represent a single well-defined abstraction. If not,

consider splitting it.

The class should not define any attributes and responsibilities that
are not functionally coupled to the other attributes or responsibilities
defined by that class.

The classes should offer the behavior the use-case realizations and
other classes require. (These will be methods later)

The class should address all specific requirements on the class

from the requirement specification the Use Cases in our case.

Remove any attributes and relationships if they are redundant or

36
33
are not needed by the use-case realizations.

Checkpoints: Use-Case Realizations

Have all the main and/or sub-flows been handled,

including exceptional cases?\

Have all the required objects been found?

Have all behaviors been unambiguously

distributed to the participating objects?

Have behaviors been distributed to the right

objects?

Where there are several interaction diagrams, are

their relationships clear and consistent? (next
lecture)
36
34

Review: Use-Case Analysis

What is the purpose of Use-Case Analysis?

What is an analysis class? Name and describe the
three analysis stereotypes.
What is a use-case realization?
Describe some considerations when allocating
responsibilities to analysis classes.
Describe the role of non-functional requirements in
complementing functional requirements.
Describe the tie-in of non-functional requirements to
use cases.

36

35