MTAT.03.139)Informa1on)Systems Lecture 15:

Non-functional Requirements

Lecture 13

•  Easterbrook S. (2004), What are requirements? Draft of the book for Requirements Engineering. University of Toronto

422

What are Non-functional Requirements?

Functional vs. Non-Functional –  Functional requirements describe what the system should do

•  things that can be captured in use cases •  things that can be analyzed by drawing sequence diagrams,

statecharts, etc. •  Functional requirements will probably trace to individual chunks of a

program

–  Non-functional requirements are global constraints on a software system

–  e.g. development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

•  Often known as the “ilities” •  Usually cannot be implemented in a single module of a program

423

What are Non-functional Requirements?

•  The challenge of NFRs –  Hard to model –  Usually stated informally, and so are:

•  often contradictory •  difficult to enforce during development •  difficult to evaluate for the customer prior to delivery

–  Hard to make them measurable requirements •  We’d like to state them in a way that we can measure how well

they’ve been met

424

Example)NFRs)•  Interface requirements

–  how will the new system interface with its environment?

• User interfaces and �user-friendliness� • Interfaces with other systems

•  Performance requirements –  Time/space bounds

•  workloads, response time, throughput and available storage space

–  “the system must handle 1,000 transactions per second"

–  Reliability • the availability of components • integrity of information maintained and supplied to the system

– "system must have less than 1hr downtime per three months"

–  Security –  permissible information flows, or who can do what

–  Survivability –  system will need to survive fire, natural catastrophes

•  Operating requirements –  physical constraints (size, weight), –  personnel availability & skill level –  accessibility for maintenance –  environmental conditions –  etc

•  Lifecycle requirements –  �Future-proofing�

•  Maintainability •  Enhanceability •  Portability •  Expected market or product lifespan

–  Limits on development •  development time limitations, •  resource availability •  methodological standards

•  Economic requirements •  e.g. restrictions on immediate and/or long-term

costs. 425

Approaches)to)NFRs)

•  Product vs. Process –  Product-oriented Approaches

•  Focus on system (or software) quality •  Aim is to have a way of measuring the product once it�s built

–  Process-oriented Approaches •  Focus on how NFRs can be used in the design process •  Aim is to have a way of making appropriate design decisions

•  Quantitative vs. Qualitative –  Quantitative Approaches

•  Find measurable scales for the quality attributes •  Calculate degree to which a design meets the quality targets

–  Qualitative Approaches •  Study various relationships between quality goals •  Reason about trade-offs etc. 426

So@ware)Quali1es)

•  Think of an everyday object –  e.g. a chair –  How would you measure it�s �quality�?

•  construction quality? (e.g. strength of the joints,…) •  aesthetic value? (e.g. elegance,…) •  fit for purpose? (e.g. comfortable,…)

•  All quality measures are relative –  there is no absolute scale –  we can sometimes say A is better than B…

•  … but it is usually hard to say how much better!

427

So@ware)Quali1es)•  For system:

–  Construction quality? •  System is not manufactured

–  Aesthetic value? •  But most of the software is

invisible •  Aesthetic value matters for

the user interface, but is only a marginal concern

–  Fit for purpose? •  Need to understand the

purpose

•  Software quality is all about fitness to purpose –  does it do what is needed? –  does it do it in the way that its

users need it to? –  does it do it reliably enough? fast

enough? safely enough? securely enough?

–  will it be affordable? will it be ready when its users need it?

–  can it be changed as the needs change?

428

Quality is not a measure of software in isolation

•  It measures the relationship between software and its application domain –  cannot measure this until you place the software into its environment… –  …and the quality will be different in different environments!

•  During design, we need to predict how well the software will fit its purpose –  we need good quality predictors (design analysis)

•  During requirements analysis, we need to understand how fitness-for-purpose will be measured –  What is the intended purpose? –  What quality factors will matter to the stakeholders? –  How should those factors be operationalized?

Source:!Budgen,!1994,!pp58/9!

429

Boehm�s'NFR'list' deviceGindependence)selfGcontainedness)accuracy)completeness)robustness/integrity)consistency)accountability)device)efficiency)accessibility)communica1veness)selfGdescrip1veness)structuredness)conciseness)legibility)augmentability)

Source:!See!Blum,!1992,!p176!

General))u1lity)

portability)

AsGis)u1lity)

Maintainability)

reliability)

efficiency)

usability)

testability)

understandability)

modifiability)

430

McCall�s)NFR)list)

Product)opera1on)

usability)

Product)revision)

Product)transi1on)

integrity)

maintainability)

testability)

reusability)

portability)

interoperability)

operability)training)

I/O)volume)

Access)control)Access)audit)Storage)efficiency)

consistency)

instrumenta1on)expandability)generality)SelfGdescrip1veness)modularity)machine)independence)s/w)system)independence)comms.)commonality)

efficiency)

correctness)

reliability)

flexibility)

communicata1veness)

I/O)rate)

execu1on)efficiency)

Source:!See!van!Vliet!2000,!pp111/3!

traceability)completeness)accuracy)error)tolerance)

simplicity)conciseness)

data)commonality) 431

Making Measurable •  We have to turn our vague ideas about quality into

measurables The Quality Concepts (abstract notions of quality properties)

Measurable Quantities (define some metrics)

Counts taken from Design Representations (realization of the metrics)

usability

minutes taken for some user task???

time taken to learn how to use?

complexity

count procedure calls???

information flow between modules?

reliability

run it and count crashes per hour???

mean time to failure?

432

Example Metrics Quality '' Metric'

Speed) transac1ons/sec)response)1me)screen)refresh)1me)

Size) Kbytes)number)of)RAM)chips)

Ease)of)Use) training)1me)number)of)help)frames)

Reliability) meanG1meGtoGfailure,)probability)of)unavailability)rate)of)failure,)availability)

Robustness) 1me)to)restart)a@er)failure)percentage)of)events)causing)failure)

Portability) percentage)of)targetGdependent)statements)number)of)target)systems)

433

Usability requirements Lausen, 2002

Usability = Fit for use + Ease of use •  Ease of learning

–  How easy is the system to learn for various groups of users?

•  Task efficiency –  How efficient is it for the frequent user?

•  Ease of remembering –  How easy is to remember for the occasional user?

•  Subjective satisfaction –  How satisfied is the user with the system?

•  Understandability –  How easy is it to understand what the system does?

434

Usability requirements Lausen, 2002

•  Problem counts –  R.1: At most 1 of 5 novices shall encounter critical problems during tasks Q

and R. –  R.2: At most 5 medium problems on the list.

•  Task time –  R.3: Novice users shall perform tasks Q and R in 15 minutes. –  R.4: Experienced users complete tasks Q, R and S in 2 minutes

•  Keystroke counts –  R.5: Recording breakfast shall be possible within 5 keystrokes per guest. No

mouse.

•  Opinion poll –  R.6: 80% of users shall find system easy to learn. –  R.7: 60% of users shall recommend system to others.

435

Usability requirements Lausen, 2002

•  Score for understanding –  R.8: Show 5 users 10 common error messages, e.g., Amount too large.

Ask for the cause. 80% of the answers shall be correct

•  Design-level requirements –  R.9: System shall use screen pictures in app. xx, buttons work

as app. yy.

•  Product level requirements –  R.10: For all code fields, user shall be able to select value from drop-

down lists.

•  Guideline adherence –  R.11: System shall follow style guide zz. –  R.12: Menus shall have at most three levels.

•  Development process requirements –  R.13: Three prototype versions shall be made and usability tested

during design. 436

Efficiency requirements Lausen, 2002

•  Efficiency - the capability of the software to provide the required performance relative to the amount of resources used, under stated conditions

–  R.14: Product shall be able to process 100 payment transactions per second in

peak load. –  R.15: Product shall be able to process one alarm in 1 second, 1000 alarms

in 5 seconds. –  R.16: In standard workload, CPU usage shall be less than 50 %, leaving 50% for

background jobs. –  R.17: Scrolling one page up or down in a 200 page document shall take at most 1s.

Searching for a specific keyword shall take at most 5s. –  R.18: When moving to the next field, typing must be possible within 0,2s. When

switching to the next screen tying must be possible within 1.3s. Showing simple report screens, less than 20s.

–  R.19: A simple report shall take less than 20s for 95% of the cases. None shall take above 80s.

437

Maintainability requirements Lausen, 2002

•  Maintenance performance –  R.20: Supplier’s hotline shall analyse 95% of reports within

2 work hours. –  R.21: Urgent detects (no work-around) shall be repaired within 30 work

hours in 95% of cases –  R.22: When repairing a defect, related non-repaired defects shall be

less than 0.5 coverage –  R.23: For the period of 2 years, supplier shall enhance the

product at a cost of x per Function Point

•  Support features –  R.24: Installation of a new version shall leave all database

contents and personal settings unchanged. –  R.25: Supplier shall station a qualified developer at the customer’s site.

438

Maintainability requirements Lausen, 2002

•  Development process requirements –  R.26: Every program module must be assessed for maintainability

according to procedure xx. 70% must obtain “High maintainable” and none “poor”.

–  R.27: Development must use regression test allowing full re- testing in 12 hours.

•  Program complexity requirements –  R.28: No method in any object may exceed 200 lines of code

•  Product feature requirements –  R.29: Product shall log all actions and provide remote diagnosis

functions. –  R.30: Product shall provide facilities for tracing any database

field to places where it is used. 439

Security requirements Lausen, 2002

•  R.31: Safeguards against loss of database. Estimated losses to be <1 per 50 years

•  R.32: Safeguards against disk crashes. Estimated losses to be < 1 per 100 years

•  R.33: Product shall duplicate disk (RAID disks) •  R.34: Product shall include firewalls for virus detection •  R.35: Product shall follow good accounting practices. Supplier

shall obtain certification •  R.36: Product shall prevent users deleting invoices before transfer to

the account systems •  R.37: The supplier shall as an option offer features for checking and

reserving deposits made by credit cards •  R.38: The supplier must enclose a risk assessment and suggest

optional safeguard 440

i*!/)Tropos!Strategic!RaConale!Model)

441

Secure)Tropos)

442

•  Security'constraint'–  Restric1on)related)to)

the)security)of)the)system)

–  Influence)the)analysis)and)design)of)a)system)

–  Restricts)alterna1ve)design)solu1ons)

•  Secure'dependency'–  Introduces)security)

constraint(s))that)must)be)fulfilled)for)the)dependency)to)be)sa1sfied)

443

Security)risk)management)process)

Security)Risk)Management))Domain)Model)

444

445

Context)and)Assets)Iden1fica1on)

•  Descrip:on'of'organisa:on'and'its'environment'–  sensi1ve)ac1vi1es)related)to)informa1on)security)

446

Security)Objec1ves)Determina1on)

•  Determine'the'security'objec:ves'to'be'reached'–  Confiden1ality,)Integrity,)Availability)

447

Risk)Analysis)and)Assessment)

•  Iden:fy'risks'and'es:mate'them'qualita:vely'or'quan:ta:vely'

448

Risk)Analysis)and)Assessment)

•  Iden:fy'risks'and'es:mate'them'qualita:vely'or'quan:ta:vely'

449

Risk)Treatment)Decisions)

Risk'treatment'decisions'

Defini:on'

Avoiding'risk' Decision)not)to)be)involved)in,)or)to)withdraw)from)a)risk)

Transferring'risk' Sharing)with)another)party)the)burden)of)loss)for)a)risk)

Retaining'risk' Accep1ng)the)burden)of)loss)from)a)risk)

Reducing'risk' Ac1on)to)lessen)the)probability,)nega1ve)consequences,)or)both,)associated)with)a)risk)

450

Security)Requirements)Defini1on)•  Security'requirements'F'security'solu:ons'to'mi:gate'the'

risks'•  If)security)requirements)are)unsa1sfactory)

–  Revise)the)risk)treatment)step)–  Revise)all)of)the)preceding)steps)

451

Control)Selec1on)and)Implementa1ons)•  Implement'system'countermeasures'within'organisa:on''

TradeGoff)analysis)

452

TradeGoff)analysis)

453

50.000 $

TradeGoff)analysis)

454

50.000 $

Need (Confidentiality)= 3

Likelihood= 3 V.

level= 3

Impact = 3 Event potentiality = 5 Risk level = 15 Reduced Risk level (improve authorisation) = 9

Reduction level = 6

Reduced Risk level (Install crypto) = 0

Reduction level = 12

TradeGoff)analysis)

455

50.000 $

Likelihood= 3 V. level= 3

Impact = 3 Event potentiality = 5 Risk level = 15 Reduced Risk level (improve authorisation) = 9

Reduction level = 6 Cost = 25.000$ ROSI = 220%

Reduced Risk level (Install crypto) = 0

Reduction level = 12 Cost = 75.000$ ROSI = 166%

25.000 $

75.000 $

Need (Confidentiality)= 3

What)have)we)learnt)today?)

•  What)are)nonGfunc1onal)requirements)– Usability)– Efficiency)– Maintainability)– Security)

•  Modelling)of)nonGfunc1onal)requirements)

456