Understanding Non-Functional Requirements: Classification & Interdependencies, Study notes of Design

Download Understanding Non-Functional Requirements: Classification & Interdependencies and more Study notes Design in PDF only on Docsity! 1 Non-Functional Requirements Lawrence Chung Department of Computer Science The University of Texas at Dallas Non-Functional Requirements Practices and Recommendations: A Brief Synopsis
Why
What
Some Classification Schemes
NFRs and RE Processes
Some Individual NFRs
With Rational Unified Process and UML
With Volere Requirements Specification Templates Lawrence Chung Why Non-Functional Requirements (NFRs)? • Consider a brochure from an automobile manufacturer: – When you buy our car, you can now drive to a store… • Consider a brochure from a cellular phone manufacturer: – When you buy our cellular phone, you can now call your friend. – Well, … Lawrence Chung Why NFRs? • With automobiles: – The basic function is transportation from one location to another. – “With premium luxury, outstanding safety features and superior off-pavement capability, … continues to exceed the high expectations of its owners, … continue to set the standard for premium luxury in its segment." • With cellular phones: – The basic function is communication with another party – “… enhancements enable the best possible operation of your mobile … in various conditions. … The earpiece fits in either ear allowing for convenient and discreet access to all basic call controls. ... To maximize call security, the headset also supports encryption of the wireless connection for compatible … models. • With home networking: “… is the total home networking solution … linking variety of digital home appliances as one. It enables you to enjoy convenient, pleasant, and comfortable living environment at any time and any place. • With CASE tool software: – The basic function is provision of some services – “… is a powerful, easy-to- use application definition platform used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours. … Using the easy to learn, drag-and-drop paradigm …, business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, …” 2 Lawrence Chung NFRs: IEEE definition “non functional requirement – in software system engineering, a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.” General Observations “non functional requirement – generally informally stated, often contradictory, difficult to enforce during development and evaluate for the customer prior to delivery” Lawrence Chung What are Non-Functional Requirements? • -ilities: understandability, usability, modifiability, inter- operability, reliability, portability, maintainability, scalability, (re-)configurability, customizability, adaptability, variability, volatility, traceability, … • -ities: security, simplicity, clarity, ubiquity, integrity, modularity, nomadicity, … • -ness: user-friendliness, robustness, timeliness, responsiveness, correctness, completeness, conciseness, cohesiveness, … • …and many other things: performance, efficiency, accuracy, precision, cost, development time, low coupling, … Lawrence Chung NFRs: Some classification schemes - 1 • Interface requirements: describe how the system is to interface with its environment, users and other systems. E.g., user interfaces and their qualities (e.g., user-friendliness) • Performance requirements: describe performance constraints involving – time/space bounds, such as workloads, response time, throughput and available storage space. E.g., “system must handle 100 transactions/second” – reliability involving the availability of components and integrity of information maintained and supplied to the system. E.g., “system must have less than 1hr downtime/3 months” – security, such as permissible information flows – survivability, such as system endurance under file, natural catastrophies • Operating requirements: include physical constraints (size, weight), personnel availability, skill level considerations, system accessibility for maintenance, etc. • Lifecycle requirements: can be classified under two subcategories: – quality of the design: measured in terms such as maintainability, enhanceability, portability. – limits on development, such as development time limitations, resource availability, methodological standards, etc. • Economic requirements: immediate and/or long-term costs • Political requirements  [Roman, IEEE Computer 1985] Lawrence Chung NFRs: Some classification schemes - 2  Process, Product and External considerations [Sommerville 1992] 5 Lawrence Chung NFRs: Portability • The degree to which software running on one platform can easily be converted to run on another platform • E.g., number of target statements (e.g., from Unix to Windows) • Hard to quantify, since it is hard to predict what a “next generation” platform might be like • Can be enhanced by using languages, OSs and tools that are universally available and standardized. E.g., C/C++/C#/Java J2EE/J2ME/.NET Lawrence Chung • the ability of the system to behave consistently in a user-acceptable manner when operating within the environment for which the system was intended. • theory and practice of hardware reliability are well established; some try to adopt them for software • one popular metric for hardware reliability is mean-time-to-failure (MTTF) "Bathtub" curve characterizes MTTF: • Infant mortality: Given a large population of a particular component, many will fail soon after development due to inaccuracies in the manufacturing process; • Issues: Do 2 different software copies have different characteristics? Does software wear & tear by decomposition? Does software obey physical laws? NFRs: Reliability time # o f fa ilu re s Infant motility Constant operation Wear & tear MTBF MTTFMTTR Availability = [MTTF/(MTTF + MTTR)] x 100% Lawrence Chung • Sometimes reliability requirements take the form: "The software shall have no more than X bugs/1K LOC" But how do we measure bugs at delivery time? • Bebugging Process - based on a Monte Carlo technique for statistical analysis of random events. 1. before testing, a known number of bugs (seeded bugs) are secretly inserted. 2. estimate the number of bugs in the system 3. remove (both known and new) bugs. # of detected seeded bugs/ # of seeded bugs = # of detected bugs/ # of bugs in the system # of bugs in the system = # of seeded bugs x # of detected bugs /# of detected seeded bugs Example: secretely seed 10 bugs an independent test team detects 120 bugs (6 for the seeded) # of bugs in the system = 10 x 120/6 = 200 # of bugs in the system after removal = 200 - 120 - 4 = 76 • But, deadly bugs vs. insignifant ones; not all bugs are equally detectable; ( Suggestion [Musa87]: "No more than X bugs/1K LOC may be detected during testing" "No more than X bugs/1K LOC may be remain after delivery, NFRs: Reliability original seeded seeded original = :: 6 10 114 ? 190 - 114 Lawrence Chung • refers to the level at which a software system uses scarce computational resources, such as CPU cycles, memory, disk space, buffers and communication channels • can be characterized along a number of dimensions: Capacity:maximum number of users/terminals/transactions ... Degradation of service: what happens when a system with capacity X widgets per time unit receives X+1 widgets? - Let the system handle the load, perhaps with degraded performance - Let the system crash Timing constraints: Let stimulus refer to an action performed by the user/environment, and response refer to an action generated by the system. NFRs: Efficiency response response stimulus stimulus - stimulus-response: e.g., "the system will generate a dial tone within 10 secs from the time the phone is picked up" - response-response: e.g., "the system will record that the phone is in use no later than 1 micro-second after it had generated a dial tone" - stimulus-stimulus: e.g., "the user will type her password within 15 secs from typing her login name" - response-stimulus: e.g., "the user will start dialing the phone number within 1 minute from getting the dial tone" 6 Lawrence Chung NFRs: Usability • broadly – quality; fit to use narrowly - good UI • Usability inspection: finding usability problems in UI design, making recommendations for fixing them, and improving UI design. • Heuristics: a set of criteria against which usability of UI design is evaluated • "9 usability heuristics" [Nielsen90] • Promptness no undue delay in accepting info items and responding to requests • Tolerance no hang-ups against errors, delays, unexpected behavior, etc. • Guidance providing guidance for correcting errors, generating reminders, etc. • Coherence ... ... • "10 usability heuristics" [Molich and Nielsen90] • Simple and natural dialogue; Speak the user’s language • Minimize the user’s memory; Consistency; Feedback • Clearly makred exits; Shortcuts • Precise and constructive error messages; Prevent errors • Help and documentation Lawrence Chung NFRs: Usability • All users will be satisfied with the usability of the product. • 95% of all users will be satisfied with the usability of the product. • 95% of the users will be able to complete representative tasks without requiring assistance (e.g., modifying exclusion date set) • 95% of the users will be able to complete representative tasks by the third attempt without requiring assistance • 95% of the users will be able to complete tasks X Y Z by the third attempt without requiring assistance • 95% of the users will be able to complete tasks X Y Z in less than 10 minutes without requiring assistance • 95% of the users will be able to complete task X in less than 10 minutes without requiring assistance • 80% of the users will be able to complete task Y in less than 10 minutes • 77% of the users will be able to complete task Z in less than 5 minutes Lawrence Chung Dependability • Dimensions of Dependability – Availability - The ability of the system to deliver services when requested – Reliability - The ability of the system to deliver services as specified – Safety - The ability of the system to operate without catastrophic failure – Security - The ability of the system to protect itself against accidental or deliberate intrusion• Cost of development - Geometric rise in cost from low dependability to highest • Effects of low dependability – Often unused – Failure recovery costs may be high – Difficult to retrofit dependability – Loss of information • Repeatable improvement process helps – CMM -SEI – More later • Critical Systems – Safety critical – Mission critical – Business critical • Dependability a key aspect – A system failure causes • Significant economic loss • Physical damage • Threat to or loss of human life Lawrence Chung Dependability • Cost of failure – direct • Loss of life / Injury • Loss of business – Indirect • Litigation • Good will • Availability and Reliability – Factors effecting • Environment office versus university • Perception (frequency of occurrence) • Degrees – Failure - service that is expected is not delivered – Error – behavior that does not conform to the specification – Fault – incorrect state – un- anticipated – Human error • Improve reliability – Fault avoidance – Fault detection and removal – testing and debugging – Fault tolerance - self checking and redundancy • Errors of this type are random – Remain after testing due to unforeseen combinations of input or use – Random based on user methods • Not all inputs done the same • Learn to avoid • Therefore removal of some faults will not improve perception 7 Lawrence Chung Dependability - Safety • Ability to operate normally or abnormally without threat to life or environment • Classes – Primary safety critical • Embedded as controller – Secondary • There output could effect indirectly other processes (CAD) • Reasons for less than 100% certainty of fault tolerant/free – Incomplete specification – Hardware malfunction – causing exceeded limits in software – Incorrect input • Methods to lessen chance of safety failure – Hazard avoidance • Added control features (I.e. two man rule) – Hazard detection and removal • Scans for known causes and cause preventive action – Damage limitation (control) • Firewalls and other protective reactions to results • Terms – Accident – Hazard – Damage – Hazard Severity – Hazard Probability – Risk Lawrence Chung Specification • Safety – IEC 61508 safety life cycle • Concept to death – Hazard analysis – Safety requirements definition – Planning , validation, development, external risk reduction – Separate safety validation – installation and commissioning – O&M – Decommissioning – Hazard and Risk Analysis • Iterative process – Hazard Identification » Hazard description – Risk analysis and hazard classification » Risk assessment – Hazard decomposition » Analysis as to potential causes (fault-tree analysis) – Risk reduction analysis – Preliminary safety requirements • Fault tree – Deductive – start with a hazard – Inductive – start with failure – Fault tree starts with the failure and works backwards to potential causes • Risk assessment – Classifications • Intolerable • As low as reasonably practical (ALARP) • Acceptable – For each hazard • Probability • Severity • Estimated risk • Risk reduction – Avoidance – Detection and removal – Damage limitation Lawrence Chung Dependability - Security • Lack of security comprise to availability and reliability • Types – Denial of service – Corruption of programs or data – Unauthorized disclosure • Terms – Exposure – Vulnerability – Attack – Threats – Controls • Methods – Vulnerability avoidance – Detection and neutralization – Damage limitation • Security Specification – Similar to safety – Impractical to specify – Usually are “shall not” • Cycle in General – Asset ID and evaluation • Degree of importance – Threat analysis and risk assessment – Threat assignment lists all threats against each asset – Technology analysis what is available to counteract – Security specification Lawrence Chung Specification • Requirements specification – Functional for error detection and recovery – Non functional for reliability and availability – Shall not requirements • Reliability specification – Hardware – Software – Operator • Decrease probability of failure – For a series of dependent components Pt = sum of P1 to Pn – But if there are n replicated (redundant) and independent components then the Pt=pa to the nth • Metrics for reliability – POFD probability of failure on demand .0001 = 1 on 10000 • Systems with unpredictable demand over long time periods – emergency systems – ROCOF Rate of failure occurrence 2/1000 • Systems with a regular demand atm/airline reservations – MTTF Mean time to Failure avg time between observed failures 500 = avg of 1 in 500 time units • Systems with long transactions (auto save) – AVAIL probability system is available at any given time .999 equals in every given 1000 time units system is • Non-functional reliability requirements – ID type of failure to occur – Partition them into • Transient • Permanent • Recoverable • Unrecoverable • Non-corrupting • Corrupting – Define the appropriate requirement (metric) • E.g. recoverable w/intervention – POFOD • If automatic the ROCOF 10 Lawrence Chung • (mathematical) function: f(x, y) = f1(f2(x), f3(y)) • non-functional: nf(x, y) = nf1(nf2(x), nf3(y)) nf(x, y) = nf1(nf2(n(x)), nf3(n(y))) Global nature NFRs: functional vs. non-functional: a mathematical perspective Lawrence Chung NFRs: subjective, graded, interacting • Subjective vs. objective: subjective objective • Graded: worse better expensive cheaper slower faster • Interacting: – Conflicting: the whole is less than the sum of its parts – Synergistic: the whole is more than the sum of its parts Lawrence Chung NFRs: subjective in both definitions & solutions Classification 2 - Process, Product and External considerations [Sommerville 1992] Classification 5 - Software Quality Tree [Boehm 1976] Classification 1 [Roman, IEEE Computer 1985] Lawrence Chung NFRs: subjective in both definitions & solutions Consider “security” – problem is subjective • Protection of data alone, fine with Chris • Protection of data, and data availability, fine with Pat • Protection of data, and data availability, and data accuracy, fine with Alex • Protection of data, and data availability, and data accuracy, and filtering of viruses, fine with Neo • Protection of data, and data availability, and data accuracy, and filtering of viruses, and blocking adware, fine with Gail Consider “security” – solutions are subjective • A password authentication fine with Chris • A password authentication, with periodic change, fine with Pat • A password, together with a fingerprint verification, fine with Alex • A password, with a fingerprint verification rechecked every hour, fine with Neo • A password, with a fingerprint verification rechecked every hour, and co- presence of two people, fine with Gail 11 Lawrence Chung NFRs: subjective – and also relative in priorities security performance reliability usability security safety reliability reliability security Lawrence Chung NFRs: graded in both definitions and solutions – and relative very bad bad good very good worse better expensive cheaper slower faster
Protection of data alone good
A password authentication alone bad
Protection of data alone << Protection of data, and data availability
A password authentication << A password, together with a fingerprint verification Lawrence Chung – Conflicting: the whole is less than the sum of its parts  A password, with a fingerprint verification rechecked every hour, fine for security  Simplicity is the key for ease-of-use – Synergistic: the whole is more than the sum of its parts NFRs: interacting A password, with a fingerprint verification rechecked every hour, fine for security  Restricted access is good for data accuracy Non-Functional Requirements What - Essential Concepts
non-functional,
subjective,
graded,
interacting
– and relative
- in both definitions & solutions 12 Non-Functional Requirements How 1 - Essential Tasks softgoal satisficing Lawrence Chung NFRs: functional vs. non-functional: a mathematical perspective • (mathematical) function: f1: I -> O f2: I1 X I2 -> O e.g.: sum: R X R -> R • non-functional: – How fast can it be done? Fast, Fast(f), Fast(f2) – How precise is the answer? Precise, Precise(f), Precise(O) – How easy is it to figure out how to use it? Easy-to-learn, Easy-to-learn(f), Easy-to-learn(f2), Easy-to- learn(x) – How robust is the input? Robust, Robust(I1) , Robust(I2) – Who can use it? Security, Security(f), Security(I), Security(O), Security (f2), Accessibility, Accessibility(f), Accessibility(O) – Can it be changed easily? Changeability, Changeability(f), Changeability(f2) – How much would it cost? Cost, Design-cost(f), Implementation-cost(f), Testing-cost(f2) f(x, y) = f1(f2(x), f3(y)) nf(x, y) = nf1(nf2(x), nf3(y)) nf(x, y) = nf1(nf2(n(x)), nf3(n(y))) Lawrence Chung The NFR Framework • Based on traditional framework for problem solving in AI [Nilsson] – Establish the goals – Introduce sub-goals to satisfy the goal where the relationship is AND or OR • AND goal is satisfied when all of sub goals are satisfied • OR goal is satisfied when any of the sub goals are met – Continue until you cannot decompose further • Softgoal: no clear-cut definition and or criteria as to whether it is satisfied or not , since NFRs are subjective, relative, and interdependent – Introduce concept of satisficing – Provide basis for saying the softgoal can contribute positively or negatively, fully or partially, to some degree in satisfying other softgoals (i.e., achieved not absolutely but within acceptable limits). • Softgoal Interdependency Graphs (SIGs) – For modeling non-functional requirements and interdependencies between them • Introduces Catalogues of NFRs much like patterns for design are built [Sullivan07 lecture notes] Qualitative in nature, Process oriented {Chung et.al.} Non-functional Requirements in Software Engineering Lawrence Chung The NFR Framework Secure Accounts Integrity of Accounts Confidentiality of Accounts Availability of Accounts Integrity of Accounts Confidentiality of Accounts Availability of Accounts Complete Accounts Accurate Accounts Secure Accounts Sub-goals U Make >> Help >> Hurt >> Break Qualitative in nature, Process oriented NFR softgoal Sub-goals 15 Lawrence Chung NFRs: non-functional …and…functional  Know at least what you mean – decompose  Relate Functional and Non-functional sides  Be as specific about the scope/topic/parameter: from global to local security Integrity Confidentiality Availability Home networking authentication password fingerprint Password+ fingerprint Garage Door Oven Home Networking Contoller Home Security Lighting  Security Security [Home Networking] Security [Garage Door, Home Networking]  Authentication authentication [Home Networking] authentication [Garage Door, Home Networking] Lawrence Chung NFRs: non-functional …and…subjective in both definitions & solutions  Know at least what you mean – decompose  Relate Functional and Non-functional sides  Different functional operationalizations contribute differently Information security Integrity Confidentiality Availability Home networking authentication password fingerprint Password+ fingerprint Garage Door Oven Home Networking Contoller Home Security Lighting Fixed Lighting Variable Lighting Physical security Make >> Help >> Hurt >> Break “Satisficing” (cf. Nilsson’s) Lawrence Chung NFRs: graded in both definitions and solutions – and relative  Explore alternatives – some are better/worse than others security Integrity Confidentiality Availability authentication password fingerprint Password+ fingerprint Confidentiality Lawrence Chung NFRs: graded in both definitions and solutions – and relative  Explore alternatives – some are better/worse than others  Different alternatives may have different degrees of contributions security Integrity Confidentiality Availability authentication password fingerprint Password+ fingerprint Confidentiality Indivisual password Shared password ++ + ++ + Make >> Help >> Hurt >> Break “Satisficing” (cf. Nilsson’s) 16 Lawrence Chung NFRs: interacting – Conflicting: the whole is less than the sum of its parts – Synergistic: the whole is greater than the sum of its parts security Integrity Confidentiality Availability performance Time-P Space-P Responsive Home networking Home networking authentication password fingerprint Password+ fingerprint indexing Single-level indexing Multi-level indexing ease-of-use Lawrence Chung NFRs: interacting – graded/relative – Different techniques thru nfr-operationalizations have different impacts (cf. fr-operationalizations) security Integrity Confidentiality Availability performance Time-P Space-P Responsive Home networking Home networking authentication password fingerprint Password+ fingerprint indexing Single-level indexing Multi-level indexing ease-of-use Indivisual password Shared password ++ + +++ Lawrence Chung NFRs: interacting – graded and relative –Through functional choices (fr-operationalizations) Information security Integrity ConfidentialityAvailability Home networking authentication password fingerprint Password+ fingerprint Garage Door Oven Home Networking Contoller Home Security Lighting Fixed Lighting Variable Lighting Physical security ease-of-use Lawrence Chung NFRs: interacting – graded/relative – Different techniques have different impacts – Prioritize security Integrity Confidentiality Availability performance Time-P Space-P Responsive Home networking Home networking authentication password fingerprint Password+ fingerprint indexing Single-level indexing Multi-level indexing ease-of-use Indivisual password Shared password ++ + +++ ! + 17 Lawrence Chung NFRs: interacting – graded and relative – Through functional choices – Prioritize Information security Integrity ConfidentialityAvailability Home networking authentication password fingerprint Password+ fingerprint Garage Door Oven Home Networking Contoller Home Security Lighting Fixed Lighting Variable Lighting Physical security ease-of-use!! Claims Ordinary people experience difficulties with the sequencing No reported break-in incidents Due to fixed lightingEvaluate thru propagation of labels (satisficed, denied) Lawrence Chung Softgoal Interdependency Graph (SIG): Evaluation Thru Label Propagation Make >> Help >> Hurt >> Break AND OR U Lawrence Chung Softgoal Interdependency Graph (SIG): Summary of Modeling Concepts  Softgoals: NFR Softgoals, Operationalizing Softgoals, Claim Softgoals Integrity password Garage Door
Make >> Help >> Hurt >> Break No reported break-in incidents due to fixed lighting Softgoals ::= Priority Type [topic list] Label  Contributions:
“Satisficing” AND OR ! U Lawrence Chung Softgoal Interdenpency Graph (SIG): Semantics  Proposition = Softgoal U Contribution 20 Lawrence Chung NFRs – Where  Wherever better/cheaper/faster/happier matters • Requirements Engineering • System Architecting • Software Architecting • Design • Implementation • Validation & Verification • Testing • Maintenance • Software Process • Project Planning and Management • Configuration Management • Decision making Lawrence Chung NFRs – How to represent  From informal to tabular to visual (a la html->xml->oo-xml/eb-xml/…; CRC cards->classes; use cases & use case templates)  Dos • Bring in FRs • Clarify scope/topic • Identify agents, whenever useful • Discover relationships between definitions of NFRs • Discover relationships between solutions to NFRs • Refine definitions as many times as needed • Refine solutions as many times as needed • Prioritize • Discover conflicts • Safeguard against conflicts • Discover synergies • Discover operationalizations as reasons for conflicts/synergies • Determine strengths of contributions • Justify strengths of contributions • Explore alternatives • Discover solutions from requirements • Discover requirements from solutions • Consider use of multiple solutions • Consider scenarios • If necessary, quantify • Evaluate • Evaluate subjectively • Evaluate objectively • Establish traceability Claim Viewpoint Affecting NFRs/Operationalizations Sat Status Affected NFRs Priority Agent Topic Type Description Name Lawrence Chung Appendix • RUP Specification • Volere Specification • How to Augment UML softgoal satisficing Lawrence Chung NFRs: With Rational Unified Process and UML Home Appliance Control System Vision Version 1.2 Revision History AuthorDescriptionVersionDate Table of Contents 1. Introduction 5 1.1 Purpose 5 1.2 Scope 5 1.3 Definitions, Acronyms, and Abbreviations 5 1.4 References 5 2. Positioning 5 2.1 Business Opportunity 5 2.2 Problem Statement 5 2.3 Product Position Statement 6 3. Stakeholder and User Descriptions 6 3.1 Market Demographics 6 3.2 Stakeholder Summary 6 3.3 User Summary 7 3.4 User Environment 7 3.5 Stakeholder Profiles 7 3.5.1 Homeowner 7 3.5.2 Business Owner 8 3.5.3 Customer Care 8 3.6 User Profiles 9 3.7 Key Stakeholder or User Needs 9 21 Lawrence Chung NFRs: With Rational Unified Process and UML 4. Product Overview 9 4.1 Product Perspective 9 4.2 Summary of Capabilities 10 4.3 Assumptions and Dependencies 11 4.4 Cost and Pricing 11 4.5 Licensing and Installation 11 5. Product Features 11 5.1 Start system 11 5.2 Shutdown system 11 5.3 View status of system 11 5.4 Add a new group of sequences 12 5.5 Modify an existing group of sequences 12 5.6 Delete an existing group of sequences 12 5.7 Categorize a group 12 5.8 Schedule a group 12 5.9 Start a group 12 5.10 Stop a group 12 5.11 View the status of whole system 12 5.12 View the status of indoor lights 12 5.13 View the status of outdoor lights 12 5.14 View the status of entertainment equipment (radios, cd players, televisions) 12 5.15 View the status of the safety system 12 5.16 View the status of the security system 12 5.17 Make a new sequence 12 5.18 Modify an existing sequence 12 5.19 Delete an existing sequence 12 5.20 Schedule a sequence 12 5.21 Start a sequence 12 5.22 Stop a sequence turn on indoor lights (all) 12 Lawrence Chung 5.29 Schedule a sequence 13 5.30 Start a sequence 13 5.31 Stop a sequence turn on outdoor lights (all) 13 5.32 Turn off outdoor lights (all) 13 5.33 Turn on selected outdoor lights 13 5.34 Turn off selected outdoor lights 13 5.35 Make a new sequence 13 5.36 Modify an existing sequence 13 5.37 Delete an existing sequence 13 5.38 Schedule a sequence 13 5.39 Start a sequence 13 5.40 Stop a sequence 13 5.41 Turn on radios, cd players, televisions (all) 13 5.42 Turn off radio, cd player, television (all) 13 5.43 Turn on selected radio, cd player, television 13 5.44 Turn off selected radio, cd player, television 13 5.45 Automatic notification of emergency 14 5.46 Make a new sequence 14 5.47 Modify an existing sequence 14 5.48 Delete an existing sequence 14 5.49 Schedule a sequence 14 5.50 Start a sequence 14 5.51 Stop a sequence 14 5.52 Turn on security system (all features) 14 5.53 Turn off security system (all features) 14 5.54 Turn on safety system (all features)14 5.55 Turn off safety system (all features)14 5.56 Turn on selected features of security system 14 5.57 Turn off selected features of security system 14 5.58 Turn on selected features of safety system 14 5.59 Turn off selected features of safety system 14 NFRs: With Rational Unified Process and UML Lawrence Chung NFRs: With Rational Unified Process and UML 6. Constraints 14 6.1 Security 14 6.2 Usability 15 6.3 Responsiveness 15 6.4 Capacity 15 Appendix A. COTS Components 15 Lawrence Chung 6. Constraints 6.1 Security Security for the HACS includes authentication, access control, data integrity, and data privacy. Authentication of the user is by identifier and password. Homeowners and Business Owners can monitor and change the state of the system. Customer Care users can only monitor the system and manually place a medical alert 911 emergency request for an ambulance. Transmissions should be encrypted for privacy 6.2 Usability Easy to use (especially safety related features) Request for an ambulance, police or fire truck needs to be at the push of a button or voice activated 6.3 Responsiveness System responds quickly to user requests or changes in the environment. System responds within 2 seconds on average to local user requests and changes in the environment. System responds within 4 seconds on average to remote user requests and changes in the environment. 6.4 Capacity Maximum number of sequences for indoor lights is twenty (20) Maximum number of indoor lights that can be controlled is fifty (50) Maximum number of sequences for outdoor lights is twenty (20) Maximum number of outdoor lights that can be controlled is fifty (50) Maximum number of sequences for radios, CD players, televisions is twenty (20) Maximum number of radios, CD players, televisions that can be controlled is ten (10) Maximum number of sequences for safety and security equipment is twenty (20) Maximum number of sensors, security cameras, security VCRs, emergency notifications, that can be controlled is fifty NFRs: With Rational Unified Process and UML 22 Lawrence Chung NFRs: With Volere Requirements Specification Template The Atlantic Systems Guild Limited Table of Contents (http://www.volere.co.uk/template.htm) NON-FUNCTIONAL REQUIREMENTS: 10. Look and Feel 11. Usability and Humanity 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal PROJECT ISSUES: 18. Open Issues 19. Off-the-shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions PROJECT DRIVERS: 1. The Purpose of the Project 2. Client, Customer, Stakeholders 3. Users of the Product PROJECT CONSTRAINTS: 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS: 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements Lawrence Chung NFRs: With Volere Requirements Specification Template 10 Look and Feel Requirements 10a. The interface Content The section contains requirements relating to spirit of the interface. Your client may have given you particular demands such as corporate branding, style, colors to be used, degree of interaction and so on. This section captures the requirements for the interface rather than the design for the interface. Motivation To ensure that the appearance of the product conforms to the organizationÕs expectations. Examples The product shall comply with corporate branding standards. The product shall be attractive to a teenage audience. The product shall appear authoritative. Considerations Interface design may overlap the requirements gathering process. This particularly true if you are using prototyping as part of your requirements process. As prototypes develop it is important to capture the requirements that relate to the look and feel. In other words, be sure that you understand your client's intentions for the product's look and feel. Record these as requirements instead of merely having a prototype to which the client has nodded his approval. 10b. The style of the product Content A description of salient features of the product that are related to the way a potential customer will see the product. For example, if your client wants the product to appeal to the business executive, then a look and feel requirement is that the product has a conservative and professional appearance. Similarly if the product is for sale to children, then the look and feel requirement is that it be colorful and look like it's intended for children. You would also consider here the design of the package if this were to be a manufactured product. The package may have some requirements as to its size, style, and consistency with other packages put out by your organization, etc. Keep in mind the European laws on packaging. There is a requirement that the package Lawrence Chung 11 Usability and Humanity Requirements 11a. Ease of use. Content This section describes your client's aspirations for how easy it will be for the intended users of the product to operate it. The product's usability is derived from the abilities of the expected users of the product and the complexity of its functionality. The usability requirements should cover such things as: Efficiency of use - how quickly or accurately the user can use the product. Ease of remembering - how much is the casual user expected to remember about using the product Error rates - for some products it is crucial that the user commits very few, or no, errors. Overall satisfaction in using the product - this is especially important for commercial, interactive products where there is a lot of competition. Web sites are good example of this. Feedback - how much feedback does the user need in order to feel confident that the product is actually accurately doing what the user expects. The necessary degree of feedback will be higher for some products (eg: safety critical) than in others. Motivation To guide the product's designers into building a product that will meet the expectations of its eventual users. Examples The product shall be easy for 11 year-old children to use. The product shall help the user to avoid making mistakes. The product shall make the users want to use it. The product shall be used by people with no training, and possibly no understanding of English. Fit Criterion These examples may seem simplistic, but they do express the intention of the client. To completely specify what is meant by the requirement it is necessary to add a measurement of acceptance. We call this a fit criterion. The fit criterion for the above examples would be: [An agreed percentage, say 90%] of a test panel of 11 year olds shall be able to successfully complete [list of tasks] within [specified time] One month's use of the product shall result in a total error rate of less than [an agreed percentage, say 2%] NFRs: With Volere Requirements Specification Template Lawrence Chung NFRs: With Volere Requirements Specification Template 11b. Personalization and internationalization requirements Content This section describes the way in which the product can be altered or configured to take into account the user's personal preferences or choice of language. The personalization requirements should cover such things as: Languages, spelling preferences, language idioms Currencies including the symbols and decimal conventions Personal configuration options - there are a myriad of these Motivation To ensure that the product's users do not have to struggle with, or meekly accept, the cultural conventions of the builder. Examples The product shall retain the buyer's buying preferences. The product shall allow the user to select a chosen language. Considerations Consider the locations of the potential customers and users of your product. Any out of country users will welcome the opportunity to convert to their home spelling and expressions. By allowing users to customize the way in which they use the product, you are giving them the opportunity to participate more closely with your organization, as well as give them their own personal user experience. You might also consider the configurability of the product. This allows different users to have different functional variations of the product. 25 Lawrence Chung NFRs: With Volere Requirements Specification Template 17 Legal Requirements 17a. Compliance requirements Examples Personal information shall be implemented so as to comply with the data protection act. Fit Criterion Lawyers' opinion that the product does not break any laws. Considerations Consider consulting lawyers to help identify the legal requirements. Are there any copyrights/intellectual property that must be protected? Alternatively, do any competitors have copyrights that you might be in danger of infringing? 17b. Standards requirements Example The product shall comply with MilSpec standards. The product shall comply with insurance industry standards. The product shall be developed according to SSADM standard development steps. Fit Criterion The appropriate standard-keeper certifies that the standard has been adhered to. Considerations It is not always apparent that there are applicable standards because their existence is often taken for granted. Consider the following: Are there any industry bodies that have applicable standards? Has the industry a code of practice, watchdog or ombudsman? Are there any special development steps for this type of product? Lawrence Chung NFRs: With Rational Unified Process and UML UML – de facto standard for OOA; but FR-dominance! Web Presentation Pricing User Profile Data Access Supplier 1: prepare proposal 1.1: getRFP (user) 1.1.1: getCompany (user) 1.1.2: getRPF (company) 1.2: getLanguageLocale (user) 1.3: getTimeZone (user) 2: submitProposal (proposal) 2.1: submitProposal (proposal) 2.1.1: submitProposal (company, proposal) 2.1.1: getCompany (user) NFR Association Point Actor Actor-Use Case Assoication Use Case System Boundary NFR Goal (NG) System Bound. - NFR Assoc NFR Assoc Propagation Actor - NFR Assoc Propagation Actor - NFR Assoc Usecase - NFR Assoc Propagation Use Case - NFR Assoc AU-A - NFR Assoc Propagation AU-A - NFR Assoc R9 R11R10 R1 R3 R2 R4 R5 R6 R7 R8 R12 R13R14 Use cases as primary tool for FRs elicitation and modeling Use cases are realized with interaction diagram showing interaction between components or objects Package Dependency Diagram or Class diagram to describe components/objects and their relationships A Meta-model for partial FRs and NFRs Integration Bill of Material System Update Bill of Material Pricing System Service Item Planner Create Service Item Supplier Send RFP extends Submit Price Proposal Procurement Manager Approve Price Proposal UserSupplier Perform On-line Function Lawrence Chung What Are Use Cases? System = the system in question that provides the functionality represented by use cases Use CaseActor Actor-Use Case Association System Use case details, including NFRs, ar embedded textually using a template Use case = functionality (FRs) provided by the system Actor = an external entity (human or system) Actor-Use Case Association = an interface between an actor and the system Specialized Actor Generalized Actor Specialized Use Case Generalized Use Case Bill of Material System Update Bill of Material Pricing System Service Item Planner Create Service Item Supplier Send RFP extends Submit Price Proposal Procurement Manager Approve Price Proposal UserSupplier Perform On-line Function NFRs: With Rational Unified Process and UML Lawrence Chung Inadequate Handling of NFRs Supplier may not see other suppliers’ identity and submitted proposals.Special Requirements In step 3, Supplier may request to …Alternate Flows 1.Supplier selects an RFP and requests system to submit a proposal against the RFP. 2.System prompts the Supplier for proposal information. 3.Supplier provides the following proposal information… 4.… Basic Flow SupplierActors Supplier submits price proposal against a RFP (request for proposal).Description Submit Price ProposalTitle Textual description for NFRs embedded in the use case special requirements section – not 1st class citizens Problems: 1. NFRs not modeled and organized, and not visually 2. NFRs not traceable to architecture and design 3. Error prone if NFR applicable to multiple use cases NFRs: With Rational Unified Process and UML 26 Lawrence Chung Other Integration Schemes Specific to performance NFR. No organizational constructs. Informal annotation on diagrams Use cases, Sequence diagram, State chart, Activity diagram Dimitrov’s [4] Using use cases (FR constructs) to represent NFRs. Non- standard usage of unnamed entity. No organizational constructs. Unnamed use cases with stereo type name indicating the NFR, e.g., <<Security>> Text (use case template) Moreira’s [3] Using use cases (FR constructs) to represent NFRs. No organizational constructs. Use casesUse casesLee’s [2] Not using the preferred use case modeling for FR elicitation SIG, Class/ERD extensionsText (LEL)Cysnerios’s [1] DrawbacksNFR Modeling ConstructsIntegration PointMethod No single scheme providing all of:  Use case driven  Modeling constructs for representing and organizing NFRs  Preserving underlying use case principles (e.g., ovals for FRs but not for NFRs)  Generic for a wide range of NFRs NFRs: With Rational Unified Process and UML