University of Toronto 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 Product oriented Software Qualities Making quality criteria specific Catalogues of NFRs Example Reliability Functional vs Non Functional Functional requirements describe what the system should do Definitions Quality criteria metrics Example NFRs Department of Computer Science What are Non functional Requirements Lecture 18 Non Functional Requirements NFRs University of Toronto Department of Computer Science 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 met 1 2000 2003 Steve Easterbrook University of Toronto University of Toronto Department of Computer Science 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 e g the system must handle 1 000 transactions per second E g permissible information flows or who can do what E g system will need to survive fire natural catastrophes etc 2000 2003 Steve Easterbrook 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 Lifecycle requirements 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 Quantitative vs Qualitative Quantitative Approaches limits on development security Product vs Process Product oriented Approaches Maintainability Enhanceability Portability expected market or product lifespan the availability of components integrity of information maintained and supplied to the system e g system must have less than 1hr downtime per three months survivability physical constraints size weight personnel availability skill level accessibility for maintenance environmental conditions etc Future proofing reliability Department of Computer Science Approaches to NFRs Operating 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 or long term costs 3 2000 2003 Steve Easterbrook 4 1 University of Toronto University of Toronto Department of Computer Science Software Qualities Fitness Source Budgen 1994 pp58 9 Think of an everyday object e g a chair How would you measure it s quality 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 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 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 but it is usually hard to say how much better Department of Computer Science 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 purpose 5 2000 2003 Steve Easterbrook University of Toronto Department of Computer Science Factors vs Criteria 6 2000 2003 Steve Easterbrook University of Toronto Department of Computer Science Boehm s NFR list device independence Source See Blum 1992 p176 Quality Factors portability These are customer related concerns Examples efficiency integrity reliability correctness survivability usability reliability Design Criteria These are technical development oriented concerns such as anomaly management completeness consistency traceability visibility General utility efficiency As is utility Quality Factors and Design Criteria are related usability Each factor depends on a number of associated criteria testability There are some standard mappings to help you robustness integrity consistency accountability device efficiency communicativeness self descriptiveness During Analysis Maintainability understandability Identify the relative importance of each quality factor structuredness conciseness From the customer s point of view Identify the design criteria on which these factors depend Make the requirements measurable 2000 2003 Steve Easterbrook completeness accessibility E g correctness depends on completeness consistency traceability E g verifiability depends on modularity self descriptiveness and simplicity self containedness accuracy modifiability legibility augmentability 7 2000 2003 Steve Easterbrook 8 2 University of Toronto McCall s NFR list Source See van Vliet 2000 pp111 3 Product operation University of Toronto Department of Computer Science training usability communicatativeness integrity I O rate Source Budgen 1994 pp60 1 I O volume Access control Access audit efficiency Storage efficiency execution
View Full Document
Unlocking...