University Of Toronto Department Of Computer Science .

Department of Computer ScienceUniversity of TorontoÜÜDepartment of Computer ScienceWhat are Non-functional Requirements?Lecture 18:Non-Functional Requirements (NFRs)ÜUniversity of TorontoÜ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 programDefinitionsÄ Quality criteria; metricsÄ Example NFRsÄ 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 programProduct-oriented Software QualitiesÄ Making quality criteria specificÄ Catalogues of NFRsÄ Example: ReliabilityÜThe challenge of NFRsÄ Hard to modelÄ Usually stated informally, and so are:Process-oriented Software QualitiesÄ Softgoal analysis for design tradeoffsØ 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 met1 2000-2003, Steve EasterbrookDepartment of Computer ScienceUniversity of TorontoUniversity of TorontoExample NFRsÜInterface requirementsÜÄ how will the new system interfacewith its environment?ØUser interfaces and “user-friendliness”ØInterfaces with other systemsÜPerformance requirementsÄ time/space boundsØworkloads, response time, throughputand available storage spaceØe.g. ”the system must handle 1,000transactions per second"ÜØthe availability of componentsØintegrity of information maintained andsupplied to the systemØe.g. "system must have less than 1hrdowntime per three months"ØE.g. permissible information flows, orwho can do whatØE.g. system will need to survive fire,natural catastrophes, etc 2000-2003, Steve EasterbrookÄ Product-oriented ApproachesØ Focus on system (or software) qualityØ Aim is to have a way of measuring the product once it’s builtØ Focus on how NFRs can be used in the design processØ Aim is to have a way of making appropriate design decisionsLifecycle requirementsÄ “Future-proofing”ÜQuantitative vs. Qualitative?Ä Quantitative ApproachesØ Find measurable scales for the quality attributesØ Calculate degree to which a design meets the quality targetsÄ Qualitative ApproachesØE.g development time limitations,Øresource availabilityØmethodological standardsØetc.ÜProduct vs. Process?Ä Process-oriented ApproachesÄ limits on developmentÄ securityÄ survivabilityÜphysical constraints (size, weight),personnel availability & skill levelaccessibility for maintenanceenvironmental rtabilityØexpected market or product lifespanÄ reliabilityDepartment of Computer ScienceApproaches to NFRsOperating requirementsÄÄÄÄÄ2 2000-2003, Steve EasterbrookØ Study various relationships between quality goalsØ Reason about trade-offs etc.Economic requirementsÄ e.g. restrictions on immediate and/orlong-term costs.3 2000-2003, Steve Easterbrook41

Department of Computer ScienceUniversity of TorontoSoftware QualitiesÜFitnessSource: Budgen, 1994, pp58-9Think of an everyday objectÄ e.g. a chairÄ How would you measure it’s “quality”?ÜSoftware quality is all about fitness to purposeÜQuality is not a measure of software in isolationØ 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 Ä 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?Ä 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!Ø but it is usually hard to say how much better!ÜFor software:Ä during design, we need to predict how well the software will fit its purposeØ we need good quality predictors (design analysis)Ä construction quality?Ä during requirements analysis, we need to understand how fitness-forpurpose will be measuredØ software is not manufacturedÄ aesthetic value?Ø What is the intended purpose?Ø What quality factors will matter to the stakeholders?Ø How should those factors be operationalized?Ø 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 purpose5 2000-2003, Steve EasterbrookUniversity of TorontoDepartment of Computer ScienceFactors vs. CriteriaÜQuality FactorsÜDesign CriteriaDepartment of Computer ScienceUniversity of Toronto6 2000-2003, Steve EasterbrookDepartment of Computer ScienceUniversity of TorontoBoehm’s NFR listdevice-independenceSource: See Blum, 1992, p176self-containednessportabilityÄ These are customer-related concernsØ Examples: efficiency, integrity, reliability, correctness, survivability, rityÄ These are technical (development-oriented) concerns such as anomalymanagement, completeness, consistency, traceability, visibility,.ÜGeneralutilityQuality Factors and Design Criteria are related:efficiencyÄ Each factor depends on a number of associated criteria:consistencyaccountabilityAs-is utilityusabilityØ E.g. correctness depends on completeness, consistency, traceability,.Ø E.g. verifiability depends on modularity, self-descriptiveness and simplicitydevice efficiencyaccessibilityÄ There are some standard mappings to help you ÜaccuracyDuring ivenessÄ Identify the relative importance of each quality factorØ From the customer’s point of view!MaintainabilityÄ Identify the design criteria on which these factors dependÄ Make the requirements ssmodifiabilitylegibilityaugmentability 2000-2003, Steve Easterbrook7 2000-2003, Steve Easterbrook82

Department of Computer ScienceUniversity of TorontoMcCall’s NFR listSource: See van Vliet 2000, pp111-3Making Requirements ce: Budgen, 1994, pp60-1I/O volumeProduct operationÜI/O rateintegrityAccess controlAccess auditefficiencyStorage efficiencyexecution bilityDepartment of Computer ScienceUniversity of TorontooperabilityWe have to turn our vague ideas about quality intomeasurablesexamples.The Quality Concepts(abstract notions ofquality ityusabilityusabilityMeasurable Quantities(define some use?Counts taken fromDesign Representations(realization of the task?task?accuracyerror toleranceProduct uct transitionmodularitymachine independenceportabilitys/w system independencecomms. commonalityinteroperabilitydata commonality9 2000-2003, Steve EasterbrookDepartment of Computer ScienceUniversity of TorontoUniversity of TorontoExample MetricsQualitytransactions/secresponse timescreen refresh timeSizeKbytesnumber of RAM chipsEase of Usetraining timenumber of help framesReliabilitymean-time-to-failure,probability of unavailabilityrate of failure, availabilityRobustnesstime to restart after failurepercentage of events causing failurePortabilitypercentage of target-dependent statementsnumber of target systems 2000-2003, Steve EasterbrookDepartment of Computer ScienceExample: Measuring ReliabilityMetricSpeed10 2000-2003, Steve EasterbrookÜDefinitionÜComments:Ä the ability of the system to behave consistently in a user-acceptablemanner when operating within the environment for which it was intended.Ä Reliability can be defined in terms of a percentage (say, 99.999%)Ä This may have different meaning for different applications:Ø Telephone network: the entire network can fail no more than, on average, 1hrper year, but failures of individual switches can occur much more frequentlyØ Patient monitoring system: the system may fail for up to 1hr/year, but in thosecases doctors/nurses should be alerted of the failure. More frequent failure ofindividual components is not acceptable.Ä Best we can do may be something like:Ø ".No more than X bugs per 10KLOC may be detected during integration andtesting; no more than Y bugs per 10KLOC may remain in the system afterdelivery, as calculated by the Monte Carlo seeding technique of appendix Z; thesystem must be 100% operational 99.9% of the calendar year during its firstyear of operation."11 2000-2003, Steve Easterbrook123

Department of Computer ScienceUniversity of TorontoDepartment of Computer ScienceUniversity of TorontoMeasuring Reliability Example model: Reliability growthSource: Adapted from Pfleeger 1998, p359Example reliability requirement:ÜUse bebuggingÄ “The software shall have no more than X bugs per thousand lines of code”Ä .But is it possible to measure bugs at delivery time?Ä Measures the effectiveness of the testing processÄ a number of seeded bugs are introduced to the software systemÜMotorola’s Zero-failure testing modelÜReliability estimation processtesting timeÄ Inputs needed:Ø then testing is done and bugs are uncovered (seeded or otherwise)Number of bugs in systemÄ Predicts how much more testing is needed to establish a given reliability goalÄ basic model:empirical constantsfailures ae-b(t)failuresÜØ fd target failure density (e.g. 0.03 failures per 1000 LOC)Ø tf total test failures observed so farØ th total testing hours up to the last failure# of seeded bugs x # of detected bugs# of detected seeded bugstest timeÄ Calculate number of further test hours needed using:ln(fd/(0.5 fd)) x thln((0.5 fd)/(tf fd))Ä Result gives the number of further failure free hours of testing needed toestablish the desired failure densityÄ .BUT, not all bugs are equally important!Ø if a failure is detected in this time, you stop the clock and recalculateÄ Note: this model ignores operational profiles!13 2000-2003, Steve EasterbrookUniversity of TorontoDepartment of Computer ScienceUsing softgoal analysisDefine ‘fit criteria’ for each requirementÜØe.g. a design choiceÄ ClaimØsupporting/explaining a choiceÜContribution Types:ÄÄÄÄChoosing good fit criteriaÄ Stakeholders are rarely this specificÄ The right criteria might not be obvious:Ø Things that are easy to measure aren’t necessarily what the stakeholders wantØ Standard metrics aren’t necessary what stakeholders wantÜ15AND links (decomposition)OR links (alternatives)Sup links (supports)Sub links (necessary subgoal)Evaluation of goalsÄÄÄÄÄ Stakeholders need to construct their own mappings from requirements to fitcriteria 2000-2003, Steve EasterbrookGoal types:Ä Non-functional RequirementÄ Satisficing TechniqueÄ Give the ‘fit criteria’ alongside the requirementÄ E.g. for new ATM softwareØ Requirement: “The software shall be intuitive and self-explanatory”Ø Fit Criteria: “95% of existing bank customers shall be able to withdraw moneyand deposit cheques within two minutes of encountering the product for the firsttime”ÜDepartment of Computer ScienceUniversity of TorontoMaking Requirements MeasurableÜ14 2000-2003, Steve EasterbrookSatisficedDeniedConflictingUndetermined 2000-2003, Steve EasterbrookSource: Chung, Nixon, Yu & Mylopoulos, 1999164

Department of Computer ScienceUniversity of TorontoNFR CataloguesSource: Cysneiros & Yu, 2004ÜPredefined catalogues of NFR decompositionÄ Provides a knowledge base to check coverage of an NFRÄ Provides a tool for elicitation of NFRsÄ Example: 2000-2003, Steve Easterbrook175

Ü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 chunksof a program Non-functional requirements are global constraints .