Non-Functional Requirements Practices and Recommendations: A Brief Synopsis Non-Functional Requirements
Why Lawrence Chung What Some Classification Schemes Department of Computer Science NFRs and RE Processes The University of Texas at Dallas Some Individual NFRs With Rational Unified Process and UML With Volere Requirements Specification Templates
Why Non-Functional Requirements (NFRs)? Why NFRs?
• Consider a brochure from an automobile manufacturer: • With automobiles: – The basic function is transportation from one location to another. – When you buy our car, you can now drive to a store… – “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 .
• Consider a brochure from a cellular phone manufacturer: • With CASE tool software: – The basic function is provision of some services – When you buy our cellular phone, you can now call your –“… 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 friend. 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 – Well, … Lawrence Chung only the look and feel of the final application,Lawrence Chung …”
1 NFRs: What are Non-Functional Requirements? IEEE definition
“non functional requirement – in software system • -ilities : understandability, usability, modifiability, inter- engineering, a software requirement that describes not operability, reliability, portability, maintainability, scalability, what the software will do, but how the software will do it, (re-)configurability, customizability, adaptability, variability, for example, software performance requirements, volatility, traceability, … software external interface requirements, design • -ities : security, simplicity, clarity, ubiquity, integrity, constraints, and software quality attributes. modularity, nomadicity, … Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.” • -ness : user-friendliness, robustness, timeliness, General Observations responsiveness, correctness, completeness, conciseness, “non functional requirement – generally informally cohesiveness, … stated, often contradictory, difficult to enforce during • …and many other things : performance, efficiency, development and evaluate for the customer prior to Lawrence Chung accuracy, precision, cost,Lawrence development Chung time, low coupling, delivery” …
NFRs: Some classification schemes - 1 NFRs: Some classification schemes - 2 [Roman, IEEE Computer 1985] Process, Product and External considerations • Interface requirements : describe how the system is to interface with its environment, users [Sommerville 1992] 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 Lawrence Chung Lawrence Chung
2 NFRs: NFRs: Some classification schemes - 3 Some classification schemes - 4 Dimensions of Quality –Components of FURP+ [Grady1992] F unctionality Feature set capabilities, security, generality
U sability Human factors aesthetics, consistency, documentation Frequency/severity of failure, R eliability recoverability, predictability, accuracy, MTBF
Performance Speed efficiency, resource usage, throughput, response time
Testability Extensibility Adaptability Maintainability S upportability Compatibility Configurability Serviceability Installability Localizability Robustness Lawrence Chung Lawrence Chung
NFRs: NFRs & RE Processes: Some classification schemes - 5 Why? Quality of product Quality of Process Software Quality Tree [Boehm 1976] Garbage in garbage out, so get the right requirements
P r o Garbage thru garbage out, c e so get the right process s s
Product
Evolution is inevitable – traceability is a virtue Lawrence Chung Lawrence Chung
3 Approaches to NFRs NFRs & RE Processes: So, where are NFRs in an RE Process?
•Product vs. Process? Before FRs? – Product-oriented Approaches After FRs? • Focus on system (or software) quality At the same time with FRs? • Aim is to have a way of measuring the product once it’s built – metrics …and what about Business objectives/goals, system architectures, system models, SS, SRS, ? – 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 But, should we perhaps better know about the various relationships between NFRS and such and such, •Quantitative vs. Qualitative? before answering these questions, – Quantitative Approaches more clearly, • Find measurable scales for the quality attributes understandably, • Calculate degree to which a design meets the quality targets concisely, – Qualitative Approaches precisely, • Study various relationships between quality goals agreeably, …? • Reason about trade-offsLawrence etc. Chung Lawrence Chung
Product-oriented approaches Product-oriented approaches
Lawrence Chung Lawrence Chung
4 NFRs: NFRs: Reliability Portability • the ability of the system to behave consistently in a user-acceptable manner when operating within the environment for which the system • The degree to which software running on one platform was intended. can easily be converted to run on another platform • theory and practice of hardware reliability are well established; some try to adopt them for software MTTR MTTF
MTBF • E.g., number of target statements (e.g., from Unix to Availability = [ MTTF /( MTTF + MTTR )] x 100% Windows) • one popular metric for hardware reliability is mean-time-to-failure (MTTF ) "Bathtub" curve characterizes MTTF : Infant Wear & tear motility • Hard to quantify, since it is hard to predict what a “next generation ” platform might be like Constant operation #offailures time • Can be enhanced by using languages, OSs and tools that are universally available and standardized. • Infant mortality: Given a large population of a particular component, many will fail soon after development due to inaccuracies in the manufacturing process; • Issues: E.g., C/C++/C#/Java Lawrence Chung Do 2 different software copies haveLawrence different Chung characteristics? Does software wear & tear by decomposition? J2EE/J2ME/.NET Does software obey physical laws?
NFRs: NFRs: Reliability Efficiency • Sometimes reliability requirements take the form: "The software shall have no more than X bugs/1K LOC" seeded • refers to the level at which a software system uses scarce computational resources, such as CPU But how do we measure bugs at delivery time? original cycles, memory, disk space, buffers and communication channels
• can be characterized along a number of dimensions: Capacity: maximum number of users/terminals/transactions ... • Bebugging Process - based on a Monte Carlo technique for statistical analysis of random events. Degradation of service : what happens when a system with capacity X widgets per time unit receives X+1 widgets? 1. before testing, a known number of bugs ( seeded bugs) are secretly inserted.? 10 - Let the system handle the load, perhaps with degraded performance 2. estimate the number of bugs in the system 6 114 original - Let the system crash 3. remove (both known and new) bugs. : seeded = : Timing constraints : Let stimulus refer to an action performed by the user/environment, and response refer to an action generated by the system. # 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 response stimulus Example: secretely seed 10 bugs an independent test team detects 120 bugs ( 6 for the seeded) 190 - 114 # of bugs in the system = 10 x 120/ 6 = 200 response stimulus # of bugs in the system after removal = 200 - 120 - 4 = 76 - 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 • But , deadly bugs vs. insignifant ones; not all bugs are equally detectable; ( Suggestion generated a dial tone" [Musa87]: Lawrence Chung - stimulus -stimulus : e.g., "the user will type her passwordLawrence within Chung 15 secs from typing her login name" "No more than X bugs/1K LOC may be detected during testing" - response -stimulus : e.g., "the user will start dialing the phone number within 1 min ute from getting the dial tone" "No more than X bugs/1K LOC may be remain after delivery,
5 NFRs: NFRs: Usability Usability • broadly – quality; fit to use narrowly - good UI • All users will be satisfied with the usability of the product. • 95% of all users will be satisfied with the usability of the product. • Usability inspection : finding usability problems in UI design, making recommendations for fixing them, • 95% of the users will be able to complete representative tasks and improving UI design. without requiring assistance (e.g., modifying exclusion date set) • 95% of the users will be able to complete representative tasks by • Heuristics: a set of criteria against which usability of UI design is evaluated the third attempt without requiring assistance
"9 usability heuristics" [Nielsen90] • • 95% of the users will be able to complete tasks X Y Z by the third • Promptness no undue delay in accepting info items and responding to attempt without requiring assistance requests • Tolerance no hang-ups against errors, delays, unexpected behavior, etc. • Guidance providing guidance for correcting errors, generating reminders, etc. • 95% of the users will be able to complete tasks X Y Z in less than • Coherence ...... 10 minutes without requiring assistance • 95% of the users will be able to complete task X in less than 10 • "10 usability heuristics" [Molich and Nielsen90] minutes without requiring assistance • Simple and natural dialogue; Speak the user ’s language • 80% of the users will be able to complete task Y in less than 10 • Minimize the user ’s memory; Consistency; Feedback minutes • Clearly makred exits; Shortcuts • 77% of the users will be able to complete task Z in less than 5 Lawrence Chung Lawrence Chung • Precise and constructive error messages; Prevent errors minutes • Help and documentation
Dependability Dependability • Dimensions of Dependability
– Availability - The ability of the system to deliver services when • Cost of failure requested – direct • Improve reliability • Loss of life / Injury – Fault avoidance – Reliability - The ability of the system to deliver services as specified • Loss of business – Fault detection and removal – – Safety - The ability of the system to operate without catastrophic – Indirect • Litigation testing and debugging failure • Good will – Fault tolerance - self checking and • Availability and Reliability – Security - The ability of the system to protect itself against accidental redundancy • Costor ofdeliberate development intrusion- Geometric rise in cost from low dependability to – Factors effecting • Environment office versus • Errors of this type are random highest university • Effects of low dependability • Perception (frequency of – Remain after testing due to occurrence) unforeseen combinations of input or – Often unused • Critical Systems • Degrees – Failure - service that is expected is use – Failure recovery costs may be high – Safety critical not delivered – Random based on user methods – Difficult to retrofit dependability – Mission critical – Error – behavior that does not • Not all inputs done the same – Loss of information – Business critical conform to the specification • Dependability a key aspect – Fault – incorrect state – un- • Learn to avoid • Repeatable improvement process helps anticipated – A system failure causes • Therefore removal of some faults – Human error – CMM -SEI • Significant economic loss will not improve perception – More later Lawrence Chung • Physical damage Lawrence Chung • Threat to or loss of human life
6 Dependability - Safety Specification
• Ability to operate normally or • Fault tree abnormally without threat to life • Safety or environment – IEC 61508 safety life cycle – Deductive – start with a hazard • Methods to lessen chance of safety failure • Classes • Concept to death – Inductive – start with failure – Primary safety critical – Hazard avoidance – Hazard analysis – Fault tree starts with the failure • Embedded as controller • Added control features (I.e. two man rule) – Safety requirements definition and works backwards to potential – Secondary – Hazard detection and removal – Planning , validation, development, causes external risk reduction • There output could effect • Scans for known causes and cause • Risk assessment indirectly other processes – Separate safety validation – (CAD) preventive action installation and commissioning – Classifications • Reasons for less than 100% – Damage limitation (control) – O&M • Intolerable certainty of fault tolerant/free • Firewalls and other protective reactions to – Decommissioning • As low as reasonably practical (ALARP) – Incomplete specification results – Hazard and Risk Analysis • Acceptable – Hardware malfunction – causing • Terms • Iterative process exceeded limits in software – Hazard Identification – For each hazard – Accident – Incorrect input » Hazard description • Probability – Hazard – Risk analysis and hazard • Severity – Damage classification • Estimated risk » Risk assessment • Risk reduction – Hazard Severity – Hazard decomposition – Hazard Probability » Analysis as to potential – Avoidance causes (fault-tree analysis) – Detection and removal – Risk Lawrence Chung – Risk reduction analysis Lawrence Chung – Damage limitation – Preliminary safety requirements
Dependability - Security Specification • Requirements specification • Lack of security comprise to – Functional for error detection and recovery availability and – Non functional for reliability and availability reliability – Shall not requirements • Types • Reliability specification – Hardware – Denial of service – Software – Corruption of programs or data – Operator – Unauthorized disclosure • Security Specification • Decrease probability of failure • Terms – For a series of dependent components Pt = sum of P1 – Similar to safety to Pn • Non-functional reliability – Exposure – But if there are n replicated (redundant) and requirements – Vulnerability – Impractical to specify independent components then the Pt=pa to the nth – ID type of failure to occur – Attack – Usually are “shall not” – Partition them into – Threats • Metrics for reliability • Cycle in General – POFD probability of failure on demand .0001 = 1 on • Transient – Controls 10000 • Permanent – Asset ID and evaluation • Systems with unpredictable demand over long • Methods time periods – emergency systems • Recoverable – Vulnerability avoidance • Degree of importance • Unrecoverable – ROCOF Rate of failure occurrence 2/1000 – Detection and neutralization – Threat analysis and risk assessment • Systems with a regular demand atm/airline • Non-corrupting – Damage limitation – Threat assignment lists all threats against reservations • Corrupting each asset – MTTF Mean time to Failure avg time between observed – Define the appropriate requirement failures 500 = avg of 1 in 500 time units (metric) – Technology analysis what is available to • Systems with long transactions (auto save) Lawrence Chung Lawrence Chung • E.g. recoverable w/intervention – counteract – AVAIL probability system is available at any given time POFOD – Security specification .999 equals in every given 1000 time units system is • If automatic the ROCOF
7 NFRs: NFRs: With Rational Unified Process and UML With Rational Unified Process and UML Home Appliance Control System Vision 6. Constraints Version 1.2 6.1 Security Security for the HACS includes authentication, access control, data integrity, and data privacy. Revision History Authentication of the user is by identifier and password. Date Version Description Author Homeowners and Business Owners can monitor and change the state of the system. Table of Contents Customer Care users can only monitor the system and manually place a medical alert 911 emergency request for an 1. Introduction 5 ambulance. 1.1 Purpose 5 Transmissions should be encrypted for privacy 1.2 Scope 5 1.3 Definitions, Acronyms, and Abbreviations 4. Product Overview 9 5 6.2 Usability 4.1 Product Perspective 9 Easy to use (especially safety related features) 1.4 References 5 4.2 Summary of Capabilities 10 2. Positioning 5 4.3 Assumptions and Dependencies Request for an ambulance, police or fire truck needs to be at the push of a button or voice activated 2.1 Business Opportunity 5 11 2.2 Problem Statement 5 4.4 Cost and Pricing 6.3 Responsiveness 2.3 Product Position Statement 11 6 4.5 Licensing and Installation 11 System responds quickly to user requests or changes in the environment. 3. Stakeholder and User Descriptions 6 5. Product Features 11 System responds within 2 seconds on average to local user requests and changes in the environment. 5.1 Start system 11 3.1 Market Demographics 6 System responds within 4 seconds on average to remote user requests and changes in the environment. 3.2 Stakeholder Summary 6 5.2 Shutdown system 11 5.3 View status of system 11 3.3 User Summary 5.4 Add a new group of sequences 6.4 Capacity 7 6. Constraints12 14 3.4 User Environment 7 Maximum number of sequences for indoor lights is twenty (20) 6.1… Security 14 3.5 Stakeholder Profiles 7 Maximum number of indoor lights that can be controlled is fifty (50) 3.5.1 Homeowner 7 6.2 Usability 15 Maximum number of sequences for outdoor lights is twenty (20) 3.5.2 Business Owner 8 6.3 Responsiveness 15 Maximum number of outdoor lights that can be controlled is fifty (50) 3.5.3 Customer Care 6.4 Capacity 15 8 Maximum number of sequences for radios, CD players, televisions is twenty (20) Appendix A. COTS Components 15 3.6 User Profiles Lawrence Chung9 Maximum number of radios, CD players, televisionsLawrence that can be Chung controlled is ten (10) 3.7 Key Stakeholder or User Needs 9 Maximum number of sequences for safety and security equipment is twenty (20) 3.8 Alternatives and Competition 9 3.8.1 House Sitter 9 Maximum number of sensors, security cameras, security VCRs, emer gency notifications, that can be controlled is fifty
NFRs: With Volere Requirements Specification Template NFRs: With Volere Requirements Specification Template 10 Look and Feel Requirements The Atlantic Systems Guild Limited 10a. The interface Content Table of Contents 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 (http://www.volere.co.uk/template.htm) captures the requirements for the interface rather than the design for the interface. Motivation PROJECT DRIVERS: NON-FUNCTIONAL REQUIREMENTS: To ensure that the appearance of the product conforms to the organizationÕs expectations. 1. The Purpose of the Project 10. Look and Feel Examples 2. Client, Customer, Stakeholders 11. Usability and Humanity The product shall comply with corporate branding standards. 3. Users of the Product 12. Performance The product shall be attractive to a teenage audience. 13. Operational PROJECT CONSTRAINTS: 14. Maintainability and Support The product shall appear authoritative. 4. Mandated Constraints 15. Security Considerations 5. Naming Conventions and Definitions 16. Cultural and Political Interface design may overlap the requirements gathering process. This particularly true if you are using 6. Relevant Facts and Assumptions 17. Legal 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 FUNCTIONAL REQUIREMENTS: PROJECT ISSUES: 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. 7. The Scope of the Work 18. Open Issues 8. The Scope of the Product 19. Off-the-shelf Solutions 10b. The style of the product 9. Functional and Data Requirements 20. New Problems Content 21. Tasks A description of salient features of the product that are related to the way a potential customer will see the 22. Cutover product. For example, if your client wants the product to appeal to the business executive, then a look and feel 23. Risks 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. 24. Costs … 25. User Documentation and Training Motivation Lawrence Chung26. Waiting Room Lawrence Chung Given the state of today's market and people's expectations, … Once the functional requirements are satisfied, it 27. Ideas for Solutions is often the appearance of products that determines whether they are successful or not. … Considerations
8 NFRs: With Volere Requirements Specification Template 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 . Non-Functional Requirements 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 Practices and Recommendations: 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. A Brief Synopsis 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 Why To guide the product's designers into building a product that will meet the expectations of its eventual users. What Examples The product shall be easy for 11 year-old children to use. Some Classification Schemes The product shall help the user to avoid making mistakes. The product shall make the users want to use it. NFRs and RE Processes The product shall be used by people with no training, and possibly no understanding of English. Some Individual NFRs Fit Criterion These examples may seem simplistic, but they do express the intention of the client. To completely specify what is With Rational Unified Process and UML 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: With Volere Requirements Specification Templates [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] Lawrence Chung One month's use of the product shall result in a total error rate of less than [an agreed percentage, say 2%] An anonymous survey shall show that [an agreed percentage, say 75%] of the users are regularly using the product after [an agreed time] familiarization period.
NFRs: functional vs. non-functional: a mathematical perspective
• (mathematical) function:
f1: I -> O f2: I 1 X I 2 -> O Non-Functional Requirements e.g.: sum: R X R -> R What - Essential Concepts • non-functional: – How fast can it be done? – How precise is the answer? – How easy is it to figure out how to use it? nd – How robust is it concerning the 2 input of f 2? – Who can use it? – Can it be changed easily? – How much would it cost to design and implement it?
softgoal satisficing Lawrence Chung
9 NFRs: NFRs: functional vs. non-functional: a mathematical perspective subjective, graded, interacting
• (mathematical) function: • Subjective vs. objective: subjective objective f(x, y) = f (f (x), f (y)) 1 2 3 • Graded: worse better • non-functional: expensive cheaper nf(x, y) = nf1(nf2(x), nf3(y)) slower faster nf(x, y) = nf1(nf2(n(x)), nf3(n(y))) • Interacting: – Conflicting: the whole is less than the sum of its parts Global nature – Synergistic: the whole is more than the sum of its parts
Lawrence Chung Lawrence Chung
NFRs: NFRs: subjective in both definitions & solutions subjective in both definitions & solutions Consider “security” – problem is subjective Classification 1 [Roman, IEEE Computer 1985] • Protection of data alone, fine with Chris • Protection of data, and data availability, fine with Pat Classification 2 - Process, Product and External considerations [Sommerville 1992] • Protection of data, and data availability, and data accuracy, fine with Alex • Protection of data, and data availability, and data accuracy, and filtering of Classification 5 - Software Quality Tree viruses, fine with Neo [Boehm 1976] • 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- Lawrence Chung presence of two people, fine withLawrence Gail Chung
10 NFRs: NFRs: graded in both definitions and solutions – and subjective – and also relative in priorities relative
security performance reliability very bad bad good very good usability security safety reliability worse better
reliability security expensive cheaper slower faster
Protection of data alone good A password authentication alone bad
Protection of data alone << Protection of data, and data availa bility A password authentication << A password, together with a fingerprint verification
Lawrence Chung Lawrence Chung
NFRs: interacting
– Conflicting: the whole is less than the sum of its parts Non-Functional Requirements
A password, with a fingerprint verification rechecked every hour, fine for security What - Essential Concepts Simplicity is the key for ease-of-use non-functional, – Synergistic: the whole is more than the sum of its parts subjective, graded, interacting A password, with a fingerprint verification rechecked every hour , fine for security Restricted access is good for data accuracy – and relative - in both definitions & solutions Lawrence Chung
11 NFRs: functional vs. non-functional: a mathematical perspective
• (mathematical) function: f : I -> O 1 f(x, y) = f 1(f 2(x), f 3(y)) f : I X I -> O 2 1 2 nf(x , y) = nf1(nf2(x), nf3(y)) e.g.: sum: R X R -> R nf(x , y) = nf1( nf2( n(x)), nf3( n(y))) Non-Functional Requirements • non-functional:
How 1 - Essential Tasks – How fast can it be done? Fast, Fast(f), Fast(f 2) – 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(f 2), Easy-to- learn(x)
– How robust is the input? Robust, Robust(I 1) , Robust(I 2) – Who can use it? Security, Security(f), Security(I), Security(O), Security (f 2), Accessibility, Accessibility(f), Accessibility(O) – Can it be changed easily? Changeability, Changeability(f), Changeability(f ) softgoal satisficing 2 – How much would it cost?Lawrence Chung
Cost, Design -cost(f), Implementation -cost(f), Testing -cost(f 2)
The NFR Framework The NFR Framework Qualitative in nature, Process oriented {Chung et.al.} Non-functional Requirements in Softwa[Sullivan07re Engineering lecture notes]
• Based on traditional framework for problem solving in AI [Nilsson] – Establish the goals Secure Accounts NFR softgoal – 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 Sub-goals • OR goal is satisfied when any of the sub goals are met – Continue until you cannot decompose further Availability of Accounts Secure Accounts • Softgoal : no clear-cut definition and or criteria as to whether it is satisfied or Integrity of Accounts Confidentiality of not , since NFRs are subjective, relative, and interdependent Accounts – Introduce concept of satisficing Availability of – Provide basis for saying the softgoal can contribute positively or negatively, Accounts fully or partially , to some degree in satisfying other softgoals (i.e., achieved not Integrity of absolutely but within acceptable limits). Accounts Confidentiality of • Softgoal Interdependency Graphs (SIGs) Accounts – For modeling non-functional requirements and interdependencies between them Sub-goals Make >> Help >> Hurt >> Break
• Introduces Catalogues of NFRs much like patterns for design are built Complete Accurate Accounts Accounts
Qualitative in nature,Lawrence Process Chung oriented Lawrence Chung U
12 The NFR Framework The NFR Framework Softgoal Interdependency Graph (SIG) Softgoal Interdependency Graph (SIG): Three types of refinements
Make >> Help >> Hurt >> Break Operationalize
U
Lawrence Chung Lawrence Chung
The NFR Framework NFRs: [J. Mylopoulos, L. Chung, E. Yu, " From object-oriented to goal-oriented requirements analysis ", CACM , pp31-37.ACM Press] Example: A small portion of a hospital model for requirements analysis subjective in both definitions & solutions Softgoal Interdependency Graph (SIG) Object Model
Know at least what you mean - decompose
security performance
From Softgoals to Use Cases Integrity Confidentiality Availability Time-P Space-P Responsive
Lawrence Chung Lawrence Chung
13 NFRs: NFRs: subjective in both definitions & solutions subjective in both definitions & solutions
Know at least what you mean as precisely as possible Know at least what you mean as precisely as possible - as many decompositions - as many decompositions as needed as needed
security performance authentication indexing
Integrity Confidentiality Availability Time-P Space-P Responsive password fingerprint Password+ Single-level Multi-level fingerprint indexing indexing
Accuracy Completeness Response-T Throughput Single Multiple Keyword-based Category-based password passwords indexing indexing
+Coverage -Coverage Lawrence Chung Single password Several Lawrence Chung multiple checks different passwords
NFRs: NFRs: subjective in both definitions & solutions non-functional …and…functional Know at least what you mean as precisely as possible - as many decompositions as needed Know at least what you mean – decompose security performance Relate Functional and Non -functional sides
Integrity Confidentiality Availability Time-P Space-P Responsive Home Home security performance Accuracy Completeness Response-T Throughput networking networking
+Coverage -Coverage Operationalize Integrity Confidentiality Availability Time-P Space-P Responsive authentication indexing authentication indexing password fingerprint Password+ fingerprint Single-level Multi-level indexing indexing password Single Multiple fingerprint Password+ Single-level Multi-level password passwords Keyword-based Category-based fingerprint indexing indexing indexing indexing Single password Several Lawrence Chung Lawrence Chung multiple checks different passwords
14 NFRs: NFRs: non-functional …and…subjective non-functional …and…functional in both definitions & solutions Know at least what you mean – decompose Know at least what you mean – decompose Relate Functional and Non-functional sides Relate Functional and Non-functional sides Be as specific about the scope/topic/parameter: from global to local Different functional operationalizationscontribute differently
security Home Information Home networking security networking Physical security
Integrity Confidentiality Availability Garage Home Home Integrity Confidentiality Availability Garage Home Home Door Networking Security Door Networking Security Contoller Contoller authentication authentication Oven Lighting Oven Lighting password fingerprint Password+ password fingerprint Password+ fingerprint fingerprint Fixed Variable Security Security [Home Networking] Security [Garage Door, Home Networking] Lighting Lighting Authentication authentication [Home Networking] authentication [Garage Door, Home Make >> Help >> Hurt >> Break Lawrence Chung Lawrence Chung Networking] “Satisficing ” (cf. Nilsson ’s)
NFRs: NFRs: graded in both definitions and solutions – and graded in both definitions and solutions – and relative relative Explore alternatives – some are better/worse than others Explore alternatives – some are better/worse than others Different alternatives may have different degrees of contributions Make >> Help >> Hurt >> Break “Satisficing ” (cf. Nilsson ’s) security security
+ ++
Confidentiality Integrity Confidentiality Availability Confidentiality Integrity Confidentiality Availability
authentication authentication
password fingerprint Password+ password fingerprint fingerprint Password+ fingerprint ++ +
Indivisual Shared Lawrence Chung Lawrence Chung password password
15 NFRs: NFRs: interacting interacting – graded/relative
– Different techniques thru nfr-operationalizations have – Conflicting: the whole is less than the sum of its different impacts (cf. fr-operationalizations) parts Home – Synergistic: the whole is greater than the sum of its security Home performance ease-of-use networking security Home performance Home networking parts ease-of-use networking networking Integrity Confidentiality Availability Time-P Space-P Responsive
Integrity Confidentiality Availability Time-P Space-P Responsive authentication indexing
password Single-level Multi-level authentication indexing fingerprint Password+ fingerprint indexing indexing + ++ + ++ password fingerprint Password+ Single-level Multi-level Indivisual Shared fingerprint indexing indexing password password Lawrence Chung Lawrence Chung
NFRs: NFRs: interacting – graded and relative interacting – graded/relative
– Through functional choices ( fr-operationalizations ) – Different techniques have different impacts – Prioritize ease-of-use Home Information security Home performance Home networking ease-of-use security ! networking networking Physical security Integrity Confidentiality Availability Time-P Space-P Responsive Integrity Garage Home Confidentiality Availability Home + Door Networking Security Contoller authentication indexing authentication Oven Lighting password fingerprint Password+ Single-level Multi-level indexing indexing password fingerprint Password+ fingerprint ++ + fingerprint + ++ Indivisual Shared Fixed Variable password Lighting Lighting password Lawrence Chung Lawrence Chung
16 NFRs: interacting – graded and relative Softgoal Interdependency Graph (SIG): – Through functional choices Evaluation Thru Label Propagation – Prioritize !! ease-of-use Information Home security networking Physical security
Integrity Confidentiality Availability Garage Home Home Door Networking Security UUU Contoller authentication Oven Lighting password fingerprint Password+ fingerprint
Ordinary people Fixed Variable Claims experience difficulties No reported Lighting Lighting Make >> Help >> Hurt >> Break AND with the sequencing break-in incidents Evaluate Due to fixed lighting Lawrence Chung Lawrence Chung thru propagation of labels (satisficed, denied) OR
Softgoal Interdependency Graph (SIG): Softgoal Interdenpency Graph (SIG): Semantics Summary of Modeling Concepts Softgoals: NFR Softgoals, Operationalizing Softgoals, Claim Softgoals Proposition = Softgoal U Contribution
Integrity No reported password break-in incidents due to fixed lighting Softgoals ::= Priority Type [topic list] Label ! Garage Door U Contributions:
AND Make >> Help >> Hurt >> Break
OR
“Satisficing ”
Lawrence Chung Lawrence Chung
17 Softgoal Interdenpency Graph (SIG): Semantics Softgoal Interdenpency Graph (SIG): Process of Construction An iterative, interleaving process!!!
MAKE BREAK MAKE BREAK Post NFR Softgoals:
HURT Refine NFR Softgoals as many times until the meaning is clear HELP Refine the type HURT HELP Refine the topic list HURT If satisficed( HELP (G 0, G 1)) then there exist propositions G2, …, G n such that HURT Refine the priority
HELP Operationalize NFR Softgoals Refine Operationalizing Softgoals as many times until all the parts and HURT relationships are designed (N.B: recall “one person ’s floor is another person ’s ceiling ”) Refine the type Refine the topic list Und (G , G ) = MAKE (G , G ) HELP(G , G ) HURT (G , G ) BREAK (G ,G ) 0 1 0 1 0 1 0 1 0 1 Refine the priority
Lawrence Chung Provide justifications in termsLawrence of Claim Chung Softgoals, for any kind of softgoals Evaluate the degree to which each softgoal is satisficed.
NFRs – Dos & Don’ts Dos • Relate to FRs • Clarify scope/topic Don ’ts • Identify agents, whenever useful • Absolute security, absolute reliabilty, absolute • Discover relationships between definitions safety, …. of NFRs • One definition fits all • Discover relationships between solutions • One solution solves all problems to NFRs • The contribution is such and such, since I say so • Refine definitions as many times as needed • Refine the definition only once Non-Functional Requirements • Refine solutions as many times as needed • They are falling down from the sky • Prioritize • Dissociate from FRs How 2 – Dos and Don’ts • Discover conflicts • May be more important than FRs, • Safeguard against conflicts but should consume less resources • Discover synergies • You name it; our system does it • Discover operationalizations as reasons • No quantification, no existence for conflicts/synergies • Everybody needs the same • Determine strengths of contributions • Be only pessimistic • Justify strengths of contributions • Asking why “+” reveals ignorance • Explore alternatives • Discover solutions from requirements • Beg the question • Discover requirements from solutions • Evaluate & only evaluate • Consider use of multiple solutions • Brainwash nothing but objectivity • Consider scenarios • If necessary, quantify softgoal satisficing • Evaluate, …subjectively, …objectively Lawrence Chung • Establish traceability
18 Conflict resolution 1 Conflict resolution 2
– If the receiver opens email w. zip file and the file is an attack, – Delete email w. any zip file attachment a security breach -> misunderstanding betw. sender and receiver – Delete email any w. zip file attachment <- move email w. any zip file attachment into a junk file folder -> misunderstanding betw. sender and receiver -> If the receiver does not check the junk file folder, still <- move email w. any zip file attachment into a junk file folder misunderstanding -> If the receiver does not check the junk file folder, still <- at the time the file is moved, notify this to the receiver misunderstanding -> if the receiver still does not check the junk file folder or <- at the time the file is moved, notify this to the receiver checks it late, still misunderstanding -> if the receiver still does not check the junk file folder or <- at the time the file is moved, notify the sender checks it late, still misunderstanding too <- at the time the file is moved, notify the sender -> If the receiver checks the junk file folder and opens it and the file is too an attack, -> If the receiver checks the junk file folder and opens it and the file is still a security breach an attack, still a security breach Delete email w. any zip file attachment and block any future email from the same sender Delete email w. any zip file attachment and block any future email from the same sender If the email is from a sender who is not in the list of allowed Lawrence Chung senders, delete it Lawrence Chung Leave the email but delete the attachment only
Conflict resolution 3 Conflict resolution 4
– Security[PC] -> S[email] -> S[sender] ^ S[recipient] ^ S[body] ^ S[attachment] – Security[PC] -> S[email] -> S[sender] ^ S[recipient] ^ S[body] ^ S[attachment] – Denied (S[attachment]) -> denied (S[email]) -> denied (S[PC]) – Denied (S[attachment]) -> denied (S[email]) -> denied (S[PC]) – Zip(attachment] ^ attack(attachment) ^ open(attachment) -> denied (S[attachment]) – Zip(attachment] ^ attack(attachment) ^ open(attachment) -> denied (S[attachment]) /* If the receiver opens email w. zip file and the file is an attack, a security breach */ /* If the receiver opens email w. zip file and the file is an attack, a security breach */ ~ Zip(attachment] v ~attack(attachment) v ~open(attachment) -> ~ denied (S[attachment]) helps ~ Zip(attachment] v ~attack(attachment) v ~open(attachment) -> ~ denied (S[attachment]) helps ~denied(S[email]) ~denied(S[email]) – Delete email w. any zip file attachment – Delete email w. any zip file attachment, at the time of reception -> misunderstanding betw. sender and receiver -> misunderstanding betw. sender and receiver <- move email w. any zip file attachment into a junk file folder <- move email w. any zip file attachment into a junk file folder -> If the receiver does not check the junk file folder, still mis understanding -> If the receiver does not check the junk file folder, still mis understanding <- at the time the file is moved, notify this to the receiver <- at the time the file is moved, notify this to the receiver -> if the receiver still does not check the junk file folder or -> if the receiver still does not check the junk file folder or checks it late, still misunderstanding checks it late, still misunderstanding <- at the time the file is moved, notify the sender <- at the time the file is moved, notify the sender too too -> If the receiver checks the junk file folder and opens it and the file is -> If the receiver checks the junk file folder and opens it and the file is an attack, still a security breach an attack, still a security breach Leave the email, but delete the attachment only Leave the email, but delete the attachment only Leave the email, but delete the attachment only if it is an attack Leave the email, but delete the attachment only if it is an attack: Lawrence Chung Lawrence Chung Leave the email but change the name of the attachment to “…renameToZip” detectable[attack(attachment)] If the email is from a sender who is not in the list of allowed senders, delete it Leave the email but change the name of the attachment to “…renameToZip ”
19 NFRs – Where 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 Wherever better/cheaper/faster/happier • Clarify scope/topic Name matters • Identify agents, whenever useful • Discover relationships between definitions of NFRs Description • Discover relationships between solutions to NFRs • Requirements Engineering • Refine definitions as many times as needed Type • Refine solutions as many times as needed Topic • System Architecting • Prioritize • Software Architecting • Discover conflicts Agent • Design • Safeguard against conflicts • Discover synergies Viewpoint • Implementation • Discover operationalizations as reasons for conflicts/synergies • Validation & Verification • Determine strengths of contributions Priority • Justify strengths of contributions • Testing • Explore alternatives Affected NFRs • Maintenance • Discover solutions from requirements • Discover requirements from solutions Affecting NFRs/Operationalizations • Software Process • Consider use of multiple solutions • Project Planning and Management • Consider scenarios Claim • If necessary, quantify Sat Status • Configuration Management • Evaluate • Decision making • Evaluate subjectively Lawrence Chung • Evaluate objectively Lawrence Chung • Establish traceability
NFRs: With Rational Unified Process and UML
Home Appliance Control System Vision Version 1.2
Appendix Revision History • RUP Specification Date Version Description Author Table of Contents 1. Introduction 5 • Volere Specification 1.1 Purpose 5 1.2 Scope 5 1.3 Definitions, Acronyms, and Abbreviations • How to Augment UML 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 softgoal satisficing 3.5.3 Customer Care Lawrence Chung 8 Lawrence Chung 3.6 User Profiles 9 3.7 Key Stakeholder or User Needs 9
20 NFRs: NFRs: With Rational Unified Process and UML With Rational Unified Process and UML 4. Product Overview 9 4.1 Product Perspective 9 5.29 Schedule a sequence 13 4.2 Summary of Capabilities 10 5.30 Start a sequence 13 4.3 Assumptions and Dependencies 11 5.31 Stop a sequence turn on outdoor lights (all) 13 4.4 Cost and Pricing 5.32 Turn off outdoor lights (all) 13 11 5.33 Turn on selected outdoor lights 13 4.5 Licensing and Installation 11 5.34 Turn off selected outdoor lights 13 5. Product Features 11 5.35 Make a new sequence 13 5.1 Start system 11 5.36 Modify an existing sequence 13 5.2 Shutdown system 11 5.37 Delete an existing sequence 13 5.3 View status of system 11 5.38 Schedule a sequence 13 5.4 Add a new group of sequences 12 5.39 Start a sequence 13 5.5 Modify an existing group of sequences 12 5.40 Stop a sequence 13 5.6 Delete an existing group of sequences 12 5.41 Turn on radios, cd players, televisions (all) 13 5.7 Categorize a group 12 5.42 Turn off radio, cd player, television (all) 13 5.8 Schedule a group 12 5.43 Turn on selected radio, cd player, television 13 5.9 Start a group 12 5.44 Turn off selected radio, cd player, television 13 5.10 Stop a group 12 5.45 Automatic notification of emergency 14 5.11 View the status of whole system 5.46 Make a new sequence 14 12 5.12 View the status of indoor lights 5.47 Modify an existing sequence 14 12 5.48 Delete an existing sequence 14 5.13 View the status of outdoor lights 5.49 Schedule a sequence 14 12 5.50 Start a sequence 14 5.14 View the status of entertainment equipment (radios, cd players, televisions) 5.51 Stop a sequence 14 12 5.15 View the status of the safety system 12 5.52 Turn on security system (all features) 14 5.16 View the status of the security system 12 5.53 Turn off security system (all features) 14 5.17 Make a new sequence 12 5.54 Turn on safety system (all features)14 5.18 Modify an existing sequence 12 5.55 Turn off safety system (all features)14 5.19 Delete an existing sequence 12 5.56 Turn on selected features of security system 14 5.20 Schedule a sequence Lawrence Chung 12 5.57 Turn off selected features of security systemLawrence 14 Chung 5.21 Start a sequence 5.58 Turn on selected features of safety system 14 12 5.59 Turn off selected features of safety system 14 5.22 Stop a sequence turn on indoor lights (all) 12
NFRs: NFRs: With Rational Unified Process and UML With Rational Unified Process and UML
6. Constraints 6.1 Security 6. Constraints 14 Security for the HACS includes authentication, access control, data integrity, and data privacy. 6.1 Security 14 Authentication of the user is by identifier and password. 6.2 Usability 15 Homeowners and Business Owners can monitor and change the state of the system. 6.3 Responsiveness 15 Customer Care users can only monitor the system and manually place a medical alert 911 emergency request for an 6.4 Capacity 15 ambulance. Appendix A. COTS Components 15 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) Lawrence Chung Maximum number of radios, CD players, televisionsLawrence that can be Chung controlled is ten (10) Maximum number of sequences for safety and security equipment is twenty (20) Maximum number of sensors, security cameras, security VCRs, emer gency notifications, that can be controlled is fifty
21 NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template The Atlantic Systems Guild Limited 10 Look and Feel Requirements Table of Contents 10a. The interface (http://www.volere.co.uk/template.htm) 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 PROJECT DRIVERS: NON-FUNCTIONAL REQUIREMENTS: captures the requirements for the interface rather than the design for the interface. 1. The Purpose of the Project 10. Look and Feel Motivation 2. Client, Customer, Stakeholders 11. Usability and Humanity To ensure that the appearance of the product conforms to the organizationÕs expectations. 3. Users of the Product 12. Performance Examples 13. Operational The product shall comply with corporate branding standards. PROJECT CONSTRAINTS: 14. Maintainability and Support 4. Mandated Constraints 15. Security The product shall be attractive to a teenage audience. 5. Naming Conventions and Definitions 16. Cultural and Political The product shall appear authoritative. 6. Relevant Facts and Assumptions 17. Legal Considerations Interface design may overlap the requirements gathering process. This particularly true if you are using FUNCTIONAL REQUIREMENTS: PROJECT ISSUES: prototyping as part of your requirements process. As prototypes develop it is important to capture the 7. The Scope of the Work 18. Open Issues requirements that relate to the look and feel. In other words, be sure that you understand your client's 8. The Scope of the Product 19. Off-the-shelf Solutions intentions for the product's look and feel. Record these as requirements instead of merely having a prototype 9. Functional and Data Requirements 20. New Problems to which the client has nodded his approval. 21. Tasks 10b. The style of the product 22. Cutover Content 23. Risks A description of salient features of the product that are related to the way a potential customer will see the 24. Costs product. For example, if your client wants the product to appeal to the business executive, then a look and feel 25. User Documentation and Training requirement is that the product has a conservative and professional appearance. Similarly if the product is for Lawrence26. Chung Waiting Room sale to children, then the look and feel requiremenLawrencet is Chungthat it be colorful and look like it's intended for children. 27. Ideas for Solutions 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 packag ing. There is a requirement that the package
NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template
11 Usability and Humanity Requirements 11b. Personalization and internationalization requirements 11a. Ease of use. Content Content This section describes the way in which the product can be altered or configured to take into account the user's 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 personal preferences or choice of language. The personalization requirements should cover such things as: is derived from the abilities of the expected users of the product and the complexity of its functionality . Languages, spelling preferences, language idioms The usability requirements should cover such things as: Currencies including the symbols and decimal conventions Efficiency of use - how quickly or accurately the user can use the product. Personal configuration options - there are a myriad of these Ease of remembering - how much is the casual user expected to remember about using the product Motivation Error rates - for some products it is crucial that the user commits very few, or no, errors. To ensure that the product's users do not have to struggle with, or meekly accept, the cultural conventions of the Overall satisfaction in using the product - this is especially important for commercial, interactive products where there builder. is a lot of competition. Web sites are good example of this. Examples Feedback - how much feedback does the user need in order to feel confident that the product is actually accurately The product shall retain the buyer's buying preferences. doing what the user expects. The necessary degree of feedback will be higher for some products (eg: safety The product shall allow the user to select a chosen language. critical) than in others. Considerations Motivation Consider the locations of the potential customers and users of your product. Any out of country users will To guide the product's designers into building a product that will meet the expectations of its eventual users. welcome the opportunity to convert to their home spelling and expressions. Examples By allowing users to customize the way in which they use the product, you are giving them the opportunity to The product shall be easy for 11 year-old children to use. participate more closely with your organization, as well as give them their own personal user experience. The product shall help the user to avoid making mistakes. You might also consider the configurability of the product. This allows different users to have different functional The product shall make the users want to use it. variations of the product. 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: Lawrence Chung Lawrence Chung [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 rat e of less than [an agreed percentage, say 2%]
22 NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template 11c. Ease of learning. 11d. Understandability and Politeness requirements. Content This section is concerned with discovering requirements related to concepts and metaphors that are familiar to the A statement of how easy it should be to learn to use the product. This will range from zero time for products intended for placement in the public domain (for example a parking meter or a web site) to a considerable time intended end-users. for complex, highly technical products. (We know of one product where it was necessary for graduate Content engineers to spend 18 months in training before being qualified to use the product.) This specifies the requirement for the product to be understood by its users. While usability refers to ease of use, Motivation efficiency etc., understanding determines whether the users instinctively know what the product will do for To quantify the amount of time that your client feels is allowable before a user can successfully use the product. them. In other words, the product fits into their view of the world. You can think of this as the product being This requirement will guide designers in how users will learn the product. For example, the designers may polite to its users and not expecting them to know or learn things that have nothing to do with their business build elaborate interactive help facilities into the product, or the product may be packaged with a tutorial. problem. Alternatively the product may have to be constructed so that all of its functionality is apparent upon first Motivation encountering it. Examples To avoid forcing the user to learn terms and concepts that are part of the productÕs internal construction and are not relevant to the usersÕ world. To make the product more comprehensible and thus more likely to be The product shall be easy for an engineer to learn. adopted by its intended users. A clerk shall be able to be productive within a short time. Examples The product shall be able to be used by members of the public who will receive no training The product shall use symbols and words that are naturally understandable by the user community. before using it. The product shall hide the details of its construction from the user. The product shall be used by engineers who will attend 5 weeks of training before using the Considerations product. Refer back to Section 3, the Users of the Product, and consider the world from the point of view of each of the Fit Criterion different types of users. Fit criterion for the above example requirements are: 11e. Accessibility requirements. An engineer shall produce a [specified result] within [specified time] of beginning to use the product, without needing to use the manual. Content After receiving [number of hours] training a clerk shall be able to produce [quantity of specified outputs] per [unit The requirements for how easy it should be for people with common disabilities to access the product. These of time]. disabilities might be to do with sight, physical disablement, hearing, cognitive, or others. [Agreed percentage] of a test panel shall successfully complete [specified task] within [specified time limit]. Motivation The engineers shall achieve [agreed percentage] pass rate from the final examination of the training. In many countries it is required that some products are made available to the disabled. In any event, it seems self- Considerations Lawrence Chung defeating to exclude this sizable communityLawrence of potential Chung customers. Refer back to Section 3, the Users of the System, to ensure that you have considered the ease of learning Examples requirements from the perspective of all the different types of users. The product shall be usable by partially -sighted users.
NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template 12 Performance Requirements 12d. Reliability and Availability requirements 12a. Speed and latency requirements Examples The product shall be available for use 24 hours per day, 365 days per year. Examples The product shall be available for use between the hours of 8:00am and 5:30pm. Any interface between a user and the automated system shall have a maximum response The escalator shall run from 6am until the last flight arrives at 10pm. time of 2 seconds The product shall achieve 99% up time. The response shall be fast enough to avoid interrupting the user's flow of thought 12e. Robustness or Fault Tolerance requirements The product shall poll the sensor every 10 seconds Examples The product shall continue to operate in local mode whenever it loses its link to the central server. The product shall download the new status parameters within 5 minutes of a change The product shall provide 10 minutes of emergency operation shou ld it become disconnected from Fit Criterion - Unit of measurement, Required range of values the electricity source. 12b. Safety critical requirements 12f. Capacity requirements Examples Examples The product shall not emit noxious gases that damage people's health. The product shall cater for 300 simultaneous users within the period from 9:00am to 11:am. Maximum loading at other periods will be 150. The heat exchanger shall be shielded from human contact. During a launch period the product shall cater for up to 20 people to be in the inner chamber. Fit Criterion - Description of the perceived risk, Factors that could cause the damage Fit Criterion - quantified, and thus can be tested. Unit for measuring the factors that could cause the damage "The product shall be certified to comply with the Health Department's standard E110-98. This is to 12g. Scalability requirements be certified by qualified testing engineers." Examples The product shall be capable of processing the existing 100,000 customers. This number is expected "No member of a test panel of [specified size] shall be able to touch the heat exchanger. The heat to grow to 500,000 within three years. exchanger must also comply with safety standard [specify which one].". The product shall be able to process 50,000 transactions an hour within two years of its launch. 12c. Precision or accuracy requirements Examples 12h. Longevity requirements Examples All monetary amounts shall be accurate to 2 decimal places. The product shall be expected to operate within the maximum main tenance budget for a minimum of Accuracy of road temperature readings shall be within + or - 2 degrees centigrade. 5 years. Fit Criterion - Unit of measure plus degreeLawrence of preci sionChung Lawrence Chung
23 NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template 13 Operational Requirements 14 Maintainability and Support Requirements 13a. Expected physical environment 14a. Maintenance Requirements Examples Examples The product shall be used by a worker, standing up, outside in cold, rainy conditions. New MIS reports must be available within one working week of the date the requirements are The product shall be used in noisy conditions with a lot of dust. agreed 13b. Expected technological environment A new weather station must be able to be added to the system overnight 14b. Are there special conditions that apply to the maintenance of this 13c. Partner applications product? Examples Examples We must be able to interface with any html browser. The maintenance releases will be offered to end-users once a year. The new version of the spreadsheet must be able to access data from the previous 2 versions. Every registered user will have access to our help site via the Internet. 13d. Productization Requirements Fit Criterion Examples Description of type of maintenance + amount of effort budgeted The product shall be distributed as a ZIP file. 14c. Supportability Requirements The product shall be able to be installed by an untrained user without recourse to separately-printed instructions. 14d. Adaptability requirements Examples The product is expected to run under Windows 95 and Unix The product might eventually be sold to the Japanese market Fit Criterion Specification of system software on which the product must operate. Specification of future environments in which the product is expected to operate. 14e. Installation requirements Example The product shall be able to be installed in the specified environment within 2 working days.
Lawrence Chung Lawrence Chung
NFRs: NFRs: With Volere Requirements Specification Template With Volere Requirements Specification Template 15 Security Requirements 16 Cultural and Political Requirements 15a. Access requirements 16a. Cultural requirements Examples Examples Only direct managers can see the personnel records of their staff. The product shall not be offensive to religious or ethnic groups. Only holders of current security clearance can enter the building. The product shall be able to distinguish between French, Italian and British road numbering systems. Fit Criterion 16b. Political requirements System function name or system data name Examples User role/s and/or names of people who have clearance The product shall be installed using component X. 15b. Integrity requirements The product shall make all functionality available to the managing director. Examples The product shall be developed using XYZ standards. The product shall prevent its data from incorrect data being introduced. Considerations The product shall protect itself from intentional abuse. Did you intend to develop the product on a Macintosh, when the office manager has laid down a edict that only Windows machines are 15c. Privacy requirements permitted? Is a director also on the board of a company that manufactures products similar to the one that you intend to build? Examples Whether you agree with these political requirements has little bearing on the outcome. The reality is that the system has to comply with The product shall make its user aware of its information practices before collection data from them. political requirements even if you can find a better/more efficient/more economical solution. The product shall notify customers of changes to its information policy. A few probing questions here may save some heartache later. The political requirements might be purely concerned with the politics inside your organization. However there are situations when you need to consider the politics inside your customersÕ 15d. Audit requirements 15e. Immunity requirements organizations or the national politics of the country. Content The requirements for what the product has to do to protect itself from infection by unauthorized or undesirable software programs, such as viruses, worms, Trojan horses and others. Motivation To build a product that is as secure as possible from malicious interference. Considerations Each day brings more malevolence from the unknown, outside world. People buying software, or any other kind of product, expect that it can protect itself from outside interference, Lawrence Chung Lawrence Chung
24 NFRs: NFRs: With Volere Requirements Specification Template With Rational Unified Process and UML 17 Legal Requirements UML – de facto standard for OOA; but FR-dominance! NFR Association Point
17a. Compliance requirements R1 R3 R2 R4 Pricing System Examples Actor Actor-Use Case Assoication Use Case System Boundary Personal information shall be implemented so as to comply with the data protection act. R5 R6 R7 R8 Fit Criterion Update Bill of Material NFR Goal (NG) Lawyers' opinion that the product does not break any laws. Bill of Material System
Considerations extends Actor - NFR Assoc AU-A - NFR Assoc Use Case - NFR Assoc System Bound. - NFR Assoc
Consider consulting lawyers to help identify the legal requirements. Send RFP R14 R13 R12 Are there any copyrights/intellectual property that must be protected? Alternatively, do any competitors have copyrights that you might be Service Item Planner Create Service Item Actor - NFR Assoc Propagation AU-A - NFR Assoc Propagation Usecase - NFR Assoc Propagation in danger of infringing? 17b. Standards requirements Submit Price Proposal Supplier R9 R10 R11 Supplier User NFR Assoc Propagation Example Perform On-line Function The product shall comply with MilSpec standards. A Meta-model for partial FRs and NFRs Integration Approve Price Proposal The product shall comply with insurance industry standards. Procurement Manager Web Pricing User Profile Data Access The product shall be developed according to SSADM standard development steps. Presentation Fit Criterion
The appropriate standard-keeper certifies that the standard has been adhered to. Supplier Considerations Use cases as primary tool for FRs 1: prepare proposal It is not always apparent that there are applicable standards because their existence is often taken for granted. Consider the following: elicitation and modeling 1.1: getRFP (user) Are there any industry bodies that have applicable standards? 1.1.1: getCompany (user) Has the industry a code of practice, watchdog or ombudsman? 1.1.2: getRPF (company) Are there any special development steps for this type of product? Package Dependency Diagram or Class 1.2: getLanguageLocale (user) diagram to describe components/objects 1.3: getTimeZone (user) and their relationships 2: submitProposal (proposal) 2.1: submitProposal (proposal) 2.1.1: getCompany (user) Use cases are realized with interaction 2.1.1: submitProposal (company, proposal) diagram showing interaction between Lawrence Chung Lawrence Chung components or objects
NFRs: NFRs: With Rational Unified Process and UML With Rational Unified Process and UML Inadequate Handling of NFRs What Are Use Cases? Pricing System System Title Submit Price Proposal Description Supplier submits price proposal against a RFP (request for proposal). Actor Use Case Update Bill of Material Actors Supplier Bill of Material System Specialized Use Case Basic Flow Generalized Actor extends 1.Supplier selects an RFP and requests system to submit a proposal against the Send RFP RFP. 2.System prompts the Supplier for proposal information. Service Item Planner Create Service Item Specialized Actor 3.Supplier provides the following proposal information… 4.… Submit Price Proposal Supplier Alternate Flows In step 3, Supplier may request to … Supplier User Perform On-line Function Generalized Use Case Special Supplier may not see other suppliers’ identity and submitted proposals. Requirements Approve Price Proposal Actor-Use Case Procurement Manager Association Problems: System = the system in question that provides the functionality represented by use cases 1. NFRs not modeled and organized, Textual description for and not visually Actor = an external entity (human or system) NFRs embedded in the use Use case = functionality (FRs) provided by the system 2. NFRs not traceable to architecture case special requirements and design Actor-Use Case Association = an interface between an actor and the system st section – not 1 class 3. Error prone if NFR applicable to Use case details, including NFRs,Lawrence are embedded Chung textually using a template citizens Lawrencemultiple Chung use cases
25 NFRs: With Rational Unified Process and UML Other Integration Schemes
Method Integration Point NFR Modeling Constructs Drawbacks Cysnerios’s [1] Text (LEL) SIG, Class/ERD extensions Not using the preferred use case modeling for FR elicitation Lee’s [2] Use cases Use cases Using use cases (FR constructs) to represent NFRs. No organizational constructs. Moreira’s [3] Text (use case Unnamed use cases with Using use cases (FR constructs) template) stereo type name to represent NFRs. Non- indicating the NFR, standard usage of unnamed e.g., <
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 Lawrence Chung
26