11University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookLecture 18:Non-Functional Requirements (NFRs) Definitions Quality criteria; metrics Example NFRs Product-oriented Software Qualities Making quality criteria specific Catalogues of NFRs Example: Reliability Process-oriented Software Qualities Softgoal analysis for design tradeoffs2University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookWhat 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 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 met3University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookExample NFRs Interface requirements how will the new system interfacewith its environment?User interfaces and “user-friendliness”Interfaces with other systems Performance requirements time/space boundsworkloads, response time, throughputand available storage spacee.g. ”the system must handle 1,000transactions per second" reliabilitythe availability of componentsintegrity of information maintained andsupplied to the systeme.g. "system must have less than 1hrdowntime per three months" securityE.g. permissible information flows, orwho can do what survivabilityE.g. system will need to survive fire,natural catastrophes, etc Operating requirements physical constraints (size, weight), personnel availability & skill level accessibility for maintenance environmental conditions etc Lifecycle requirements “Future-proofing”MaintainabilityEnhanceabilityPortabilityexpected market or product lifespan limits on developmentE.g development time limitations,resource availabilitymethodological standardsetc. Economic requirements e.g. restrictions on immediate and/orlong-term costs.4University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookApproaches 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.25University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookSoftware Qualities 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! For software: construction quality? software 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 purpose6University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookFitness 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? 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-97University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookFactors vs. Criteria Quality Factors These are customer-related concerns Examples: efficiency, integrity, reliability, correctness, survivability, usability,... Design Criteria These are technical (development-oriented) concerns such as anomalymanagement, completeness, consistency, traceability, visibility,... Quality Factors and Design Criteria are related: Each factor depends on a number of associated criteria: E.g. correctness depends on completeness, consistency, traceability,... E.g. verifiability depends on modularity, self-descriptiveness and simplicity There are some standard mappings to help you… During Analysis: Identify the relative importance of each quality factor From the customer’s point of view! Identify the design criteria on which these factors depend Make the requirements measurable8University of TorontoDepartment of Computer Science© 2000-2003, Steve EasterbrookBoehm’s NFR listGeneral utilityportabilityAs-is
View Full Document
Unlocking...