University of Toronto Department of Computer Science Lecture 16 Non Functional Requirements NFRs Refresher Modeling notations we ve met What are NFRs Quality factors design criteria metrics Example NFRs Product oriented approaches to NFRs Making quality factors specific Example Reliability Process oriented approaches to NFRs Softgoal analysis for design tradeoffs 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 1 University of Toronto Department of Computer Science We ve seen these UML diagrams Use Cases Sequence Diagrams user s view individual scenario Lists functions interactions between users and system visual overview of the main requirements Activity diagrams business processes concurrency and synchronization dependencies between tasks Sequence of messages Statecharts responses to events dynamic behavior event ordering reachability deadlock etc Class Diagrams information structure relationships between data items modular structure for the system 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 2 University of Toronto Department of Computer Science and the following non UML diagrams Goal Models Capture strategic goals of stakeholders Good for exploring how and why questions with stakeholders Good for analysing trade offs especially over design choices Fault Tree Models as an example risk analysis technique Capture potential failures of a system and their root causes Good for analysing risk especially in safety critical applications Strategic Dependency Models i Capture relationships between actors in an organisational setting Helps to relate stakeholders s goals to their organisational setting Good for understanding how the organisation will be changed Entity Relationship Models Capture the relational structure of information to be stored Good for understanding constraints and assumptions about the subject domain Good basis for database design Mode Class Tables Event Tables and Condition Tables SCR Capture the dynamic behaviour of a real time reactive system Good for representing functional mapping of inputs to outputs Good for making behavioural models precise for automated reasoning 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 3 University of Toronto Department of Computer Science What are Non functional Requirements Functional vs Non Functional Functional requirements describe what the system should do functions that can be captured in use cases behaviours that can be analyzed by drawing sequence diagrams statecharts etc and 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 software qualities or just 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 met 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 4 Department of Computer Science University of Toronto 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 limits on development E g development time limitations resource availability methodological standards etc security E g system will need to survive fire natural catastrophes etc Lifecycle requirements 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 E g permissible information flows or who can do what Operating requirements Economic requirements e g restrictions on immediate and or long term costs 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 5 University of Toronto Department of Computer Science Approaches to NFRs Product vs Process Product oriented Approaches Focus on system or software quality Capture operational criteria for each requirement so that we can measure it once the product is built Process oriented Approaches Focus on how NFRs can be used in the design process Analyze the interactions between NFRs and design choices so that we can make 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 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 6 Department of Computer Science University of Toronto Software 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 is a marginal concern fit for purpose Need to understand the purpose 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 7 Department of Computer Science University of Toronto Fitness Source Budgen 1994 pp58 9 Software quality is all about fitness
View Full Document
Unlocking...