mtat.03.139)informa1on)systems lecture 15: non-functional ... · functional vs. non-functional –...
TRANSCRIPT
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