3-How to Write Good Requirements 2.pdf

SWE 216: Software Requirements Engineering Lecture 3 How to Write Good Requirements  Course Topics Why Requirements Engineering? Introduction to Requirements How to write good requirements RE in Software Development Life Cycles System Vision, Context, and RE Framewor...

SWE 216: Software Requirements Engineering Lecture 3 How to Write Good Requirements  Course Topics Why Requirements Engineering? Introduction to Requirements How to write good requirements RE in Software Development Life Cycles System Vision, Context, and RE Framework Requirements Discovery Fundamentals of Goal Orientation Fundamentals of Scenarios Agile Estimation and Feature Prioritization Requirements Conflicts and Negotiation Requirements Validation Fundamentals of Requirements Management Prototyping Usability requirements 3 Lecture Objectives ✓ Learn how to write good requirements ✓ Learn about writing requirements pitfalls ✓ Learn about quality measurements 4 Anatomy of a Good Requirement Defines the system under discussion Verb with correct identifier (shall or may) The Online Banking System shall allow the Internet user to access her current account balance in less than 5 seconds. Defines a positive end result Quality criteria ✓ The challenge is to seek out the system under discussion, end result, and success measure in every requirement 5 Standard for Writing a Requirement Each requirement must first form a complete sentence Not a bullet list of buzzwords, list of acronyms, or sound bites on a slide Each requirement contains a subject and a predicate Subject: a user type (watch out!) or the system under discussion Predicate: a condition, action, or intended result Verb in predicate: “shall” / “will” / “must” to show mandatory nature; “may” / “should” to show optionality The whole requirement provides the specifics of a desired end goal or result Contains a success criterion or other measurable indication of the quality 6 Standard for Writing a Requirement Several standards define precisely how to use keywords (verbs and adjectives) in their documents. Example: IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels ▪ MUST, REQUIRED or SHALL: mean that the definition is an absolute requirement of the spec. ▪ MUST NOT or SHALL NOT: absolute prohibition ▪ SHOULD or RECOMMENDED: think twice about not doing it! ▪ SHOULD NOT or NOT RECOMMENDED: think twice about doing it! ▪ MAY or OPTIONAL: truly optional 7 Standard for Writing a Requirement Look for the following characteristics in each requirement ▪ Feasible (not wishful thinking) ▪ Needed (provides the specifics of a desired end goal or result) ▪ Testable (contains a success criterion/other measurable indication of quality) ▪ Clear, unambiguous, precise, one thought ▪ Prioritized ▪ ID Note: several characteristics are mandatory (feasible, needed, testable) whereas others improve communication 8 Writing Pitfalls to Avoid Never describe prematurely how the system is going to achieve something (over-specification), always describe what the system is supposed to do ○ Refrain from designing the system prematurely Danger signs: using names of components, materials, software objects, fields & records in the user or system requirements ○ Designing the system too early may possibly increase system costs ○ Do no mix different kinds of requirements (e.g., requirements for users, system, and how the system should be designed, tested, or installed) 9 Writing Pitfalls to Avoid ○ Do not mix different requirements levels (e.g., the system and subsystems) Danger signs: high level requirements mixed in with database design, software terms, or very technical terms ○ Beware: may depend on the level of abstraction… Your what is my how! 10 Writing Pitfalls to Avoid ▷ “What versus how” test The system shall use Microsoft Outlook to send an X email to the customer with the purchase confirmation. The system shall inform the customer that the purchase is confirmed. 11 Writing Pitfalls to Avoid Avoid ambiguity ○ Write as clearly and explicitly as possible ○ Ambiguities can be caused by: The word or to create a compound requirement Poor definition (giving only examples or special cases) The words etc., …and so on (imprecise definition) Example: “With your meal you have a choice of soup or salad and rice” Do not use vague indefinable terms ○ Many words used informally to indicate quality are too vague to be verified ○ Danger signs: user-friendly, highly versatile, flexible, to the maximum extent, approximately, as much as possible, minimal impact The EasyEntry System shall be easy to use and require X a minimum of training except for the professional mode. 12 Writing Pitfalls to Avoid Do not make multiple requirements ○ Keep each requirement as a single sentence ○ Conjunctions (words that join sentences together) are danger signs: and, or, with, also Do not ramble (talk too much) ○ Long sentences with arcane (mysterious) language ○ References to unreachable documents The Easy Entry Navigator module shall consist of order X entry and communications, order processing, result processing, and reporting. The Order Entry module shall be integrated with the Organization Intranet System and results are stored in the group’s electronic customer record. 13 Writing Pitfalls to Avoid Do not speculate ○ There is no room for “wish lists” – general terms about things that somebody probably wants ○ Danger signs: vague subject type and generalization words such as usually, generally, often, normally, typically Do not express suggestions or possibilities ○ Suggestions that are not explicitly stated as requirements are invariably ignored by developers ○ Danger signs: may, might, should, ought, could, perhaps, probably Avoid wishful thinking ○ Wishful thinking means asking for the impossible (e.g., 100% reliable, safe, handle all failures, fully upgradeable, run on all platforms) The Easy Entry System may be fully adaptable to all X situations and often require no reconfiguration by the user. 14 Typical Mistakes Noise = the presence of text that Wishful thinking = text that defines a carries no relevant information to any feature that cannot possibly be validated feature of the problem Silence = a feature that is not covered Jigsaw puzzles = e.g., distributing requirements across a document and by any text then cross-referencing Over-specification = text that Inconsistent terminology = inventing describes a feature of the solution, and then changing terminology rather than the problem Contradiction = text that defines a Putting the onus on the development staff = i.e., making the reader work hard single feature in several incompatible to decipher the intent ways Ambiguity = text that can be Writing for the hostile reader (fewer of these exist than friendly ones) interpreted in >=2 different ways Forward reference = text that refers to a feature yet to be defined Source: Steve Easterbrook, U. of Toronto  Patterns for Functional Requirements: 15 Easy Approach to Requirements Syntax (EARS) A Ubiquitous requirement is continually active and takes the form The shall A State-driven requirement is active while some precondition remains true and takes the form WHILE the shall An Event-driven requirement is activated when a triggering event is detected at the system boundary and takes the form WHEN the shall An Option requirement is used for systems that include a particular feature and take the form WHERE the shall An Unwanted Behavior requirement defines the required system response to an unwanted external event and takes the form IF THEN the shall 16 Rate these Requirements The Order Entry system provides for quick, user- X friendly and efficient entry and processing of all orders. Invoices, acknowledgments, and shipping notices shall be automatically faxed during the night, so customers X can get them first thing in the morning. Changing report layouts, invoices, labels, and form letters shall be accomplished. X The system shall be upgraded in one whack. X The system has a goal that as much of the IS data as X possible be pulled directly from the T&M estimate. 17 Quality Measurements Non-functional requirements need to be measurable Avoid subjective characterization: good, optimal, better... Values are not just randomly specified Must have a rationale (e.g., why 25% less time instead of 20%, 30%?) Stakeholder must understand goals and trade-offs Precise numbers are unlikely to be known at the beginning of the requirement process Do not slow down your initial elicitation process Ensure that quality attributes are identified Negotiate precise values later during the process Make the desirable direction of values known Very few requirements actually need one specific value. The game’s frame rate shall be higher or equal to 60 fps 18 Performance Measures Lots of measures Response time, number of events processed/denied in some interval of time, throughput, capacity, usage ratio, jitter, loss of information, latency... Usually with probabilities, confidence interval Examples In case of peak load, the system shall have a minimal transaction rate of 100 payments per second. In standard workload, the CPU usage shall be less than 50%. Production of a simple report shall take less than 20 seconds for 95% of the cases. Scrolling one page up or down in a 200 page document shall take at most 250 milliseconds. 19 Performance Measures: Patterns (1) In case of peak load, the system shall have a minimal transaction rate of 100 payments per second. 20 Performance Measures: Patterns (2) 21 Reliability Measures Measure of the degree to which the system performs during a request Ability to perform a required function under stated conditions for a specified period of time Very important for critical, continuous, or scientific systems Can be measured using Defect rate Degree of precision for computations Examples Function X’s precision of calculations shall be at least 1/106. The system defect rate shall be less than 1 failure per 1000 hours of operation. 22 Availability Measures (1) Definition: Proportion of time that the system is up and running correctly Probability that the system is there when needed! Can be calculated based on Mean-Time to Failure (MTTF) and Mean-Time to Repair (MTTR) MTTF : Average duration between operation start and failure MTTR : Average duration needed to resume operation after a failure Availability = MTTF/(MTTF+MTTR) May lead to architectural requirements Redundant components (lower MTBF) Modifiability/Substitutability of components (lower MTTR) Special types of components (e.g., self-diagnostic) 23 Availability Measures (2) Examples The system shall meet or exceed 99.99% uptime over a year. The system shall not be unavailable more than 1 hour per 1000 hours of operation. (This is a MTBF requirement) Less than 20 seconds shall be needed to restart the system after a failure 95% of the time. (This is a MTTR requirement) Availability Downtime ○ 90% 36.5 days/year ○ 99% 3.65 days/year ○ 99.9% 8.76 hours/year ○ 99.99% 52 minutes/year ○ 99.999% 5 minutes/year ○ 99.9999% 31 seconds/year 24 Security Measures (1) There are at least two measures: 1. The ability to resist unauthorized attempts at usage 2. Continue providing service to legitimate users while under denial of service attack (resistance to denial of service attacks) Measurement methods: Success rate in authentication Resistance to known attacks (to be enumerated) Time/efforts/resources needed to find a key (probability of finding the key) Probability/time/resources to detect an attack Percentage of useful services still available during an attack Percentage of successful attacks Lifespan of a password, of a session Encryption level 25 Security Measures (2) May lead to architectural requirements Authentication, authorization, audit Detection mechanisms Firewall, encrypted communication channels Examples of requirements The application shall identify all of its client applications before allowing them to use its capabilities. At least 99% of known intrusions shall be detected within 10 seconds. 26 Privacy Measures It is insufficient to cite appropriate laws… “The system shall comply with The Personal Information Protection and Documents Act (PIPEDA)” does not help much (too coarse-grained)! Consider the relevant parts of laws, as well as other sources and standards. For example: US Fair Information Practice Principles (FIPPs) guidelines (source: http://player.slideplayer.com/18/6144807/#) 27 Usability Measures (1) In general, concerns ease of use and of training end users. The following more specific measures can be identified: Learnability: proportion of functionalities or tasks mastered after a given training time Efficiency Acceptable response time Number of tasks performed or problems resolved in a given time Number of mouse clicks needed to get to information or functionality Memorability: number (or ratio) of learned tasks that can still be performed after not using the system for a given time period Error avoidance Number of error per time period and user class Number of calls to user support 28 Usability Measures (2) Error handling: mean time to recover from an error and be able to continue the task User satisfaction Satisfaction ratio per user class Usage ratio Examples The system should enable at least 80% of users to book a guest within 5 minutes after a 2-hour introduction to the system. The system shall enable novice users to perform tasks X and Y in less than 15 minutes. The system shall enable expert users to perform tasks X and Y in less than 2 minutes. The satisfaction level of the system shall be “very good” or better for at least 80% of customers polled after a 3 months usage period. 29 Maintainability Measures Measures ability to make changes quickly and cost effectively Extension with new functionality Deleting unwanted capabilities Adaptation to new operating environments (portability) Restructuring (rationalizing, modularizing, optimizing, creating reusable components) Examples Every program module must be assessed for maintainability according to procedure XYZ. At least 70% of the program modules assessed according to procedure XZY must obtain “highly maintainable” 0% of the program modules assessed according to procedure XZY must obtain “poor”. The cyclomatic complexity of the system code must not exceed 7. No method in any class may exceed 200 lines of code.