Non-Functional Requirements

honorableclunkΛογισμικό & κατασκευή λογ/κού

30 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

68 εμφανίσεις

36

1

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


Non
-
Functional Requirements

36

2


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 mechanisms.”

Use
-
Case Analysis Steps


Here’s
where we are:

36

3

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

4

Non
-
Functional Requirements



OOSE Text p.115
-


36

5

Types of Requirements




Functional requirements



Describe
what

the system should do




Non
-
functional requirements


Consists of
C
onstraints

that must be
adhered to during development

(design
and implementation)


Operative word: ‘
Constraints
.’


36

6

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
computations

the system should perform



The
timing and synchronization

of the above



36

7

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…


Let’s contrast functional and non
-
functional requirements


36

8

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

9

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

10

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

11

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

12

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

13

Random Thoughts

-

Non
-
functional Requirements


Not always clear that a requirement is non
-
functional and functional.


If requirement is a
fundamental

part of the
application’s 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

14

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

15

More attributes…(2 of 2)


According to
Barry Boehm
: Overall quality is a function of
these

metrics:


Validity, clarity, understandability, modifiability, modularity,
generality, economy, resilience, documentation



Laurence Best’s

Application Architecture identifies:


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

16

Looking down on these…(1 of 2)


Functional models
such as use cases
, typically drive object
-
oriented
projects (although they certainly don’t
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

17

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

18


Where are Non
-
Functional
Requirements Captured / Modeled?


Use Case Modeling


Bittner and Spence


p. 43



In the RUP
, we place the non
-
functional requirements in the
Supplementary Specifications


But this is
usually considered a ‘standard’…..



Consider: (Bittner and Spence: different categories!!!)



Legal and Regulatory Requirements


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


Application Development Standards


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 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 written in Java 2….


Others…

36

19

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

20

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

21

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

22

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. “Don’t let
[a user’s] 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

23

Non
-
Functional

Category*

Number

Non Functional
Requirement Name

Description

Applies to Use
Case(s):

Exceptions

Use something like the table below.

You may add ‘column attributes’ as needed.

You may wish to categorize these (or not). If not, omit column.

You may also wish to add columns. You may wish a
priority

column!

36

24

Non
-
Functional

Category*

Number

Non Functional
Requirement Name

Description

Applies to Use
Cases:

Exceptions

1

Persistency

Student objects need
to be persistent

Where Student
Objects are
Updated

None

2

Security

System Administrator
actor needs to be
authenticated

Those Use
Cases that
access the
Profile Database

None

3

Availability

The Profile Database
must be available
95% of the time

All Use Cases
that require
authentication

None

Examples

36

25

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

26

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

27


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

Use
-
Case Analysis Steps

36

28

<<control>>

<<boundary>>

<<entity>>

<<entity>>

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.

36

29

Supplementary

Specification

Glossary

Use
-
Case Model

Analysis Classes

Evaluate Your Results

Are the Names appropriate?

Are the Descriptions accurate?

Are classes that should be merged actually merged?

Are appropriate entity classes merged?

Are aggregations captured?

36

30

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

31

Use
-
Case Analysis Steps


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


Qualify Analysis Mechanisms


Unify Analysis Classes


Checkpoints
-

Check the ‘quality’ of the model
against criteria that the Designer looks for…

36

32

(continued)

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

33

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
are not needed by the use
-
case realizations.

36

34

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

35

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.