Inspecting Software Requirement Document

1. Training Inspecting Software Requirement Document

2. Outline • Basic concepts and benefits of inspections • Error vs. fault • Inspecting SRS for errors and faults: Human errors • Details of Assignment • SRS and inspection technique distributed • Abstracting errors and inspection for faults • Human error taxonomy • Error and Fault Forms

3. Requirements Management Elicitation Analysis Verification Specification Requirements Engineering Activities Requirements Engineering

4. About these RE Activities… • Requirements elicitation • Requirements discovered through consultation with stakeholders • Requirements analysis and negotiation • Requirements are analyzed and conflicts resolved through negotiation • Requirements specification • A precise requirements document is produced • Requirements verification • The requirements document is checked for consistency and completeness • Requirements management • Needs and contexts evolve, and so do requirements!

5. What is an Inspection? • Definition: “Inspection is a static analysis method to verify quality properties of software products” • Inspections • An effective verification process • Detect defects • The main goal of an inspection is to find and fix defects (not defect prevention)

6. Previous Current Next Development Phase Phase Phase 1 2 ? 3 5 6 ? 4 • 1. Information transformed correctly. • 2. Information lost during transformation. • 3. Information transformed incorrectly. • 4. Extraneous information introduced. • 5. Multiple inconsistent transformations occurred for same info. • 6. Multiple inconsistent transformations possible for same info. Software Defects • In a generic sense, defects arise when the development work being done doesn’t match the software specifications already developed or would cause problems downstream.

7. Software Defect Types

8. Defect detection Question: How does one detect fault? Answer: 1 By reading the document 2 By understanding what the document describes 3 By realizing that there is a problem in the requirements

9. Requirement defects for Gas Station Control System – Example 1 • Functional Requirement # 3 • If the customer has selected to pay at the time of purchase, he or she can choose to pay by cash or credit card. If the customer selects cash, the gas pump interface instructs the customer to see the cashier. If the customer selects credit card, the gas pump interface instructs the customer to swipe his or her credit card through the credit card reader. If an invalid or no selection is made, the GSCS will use the credit card payment option, which is the default. Is this the correct response? • Information was translated incorrectly • In the example, domain knowledge should indicate that defaulting to credit card payment is an incorrect response. (What kind of transaction ever happens this way?) • Because we know that this functionality should not be implemented the way it is described, we have a defect.

10. Requirement defects for Gas Station Control System – Example 2 • Functional Requirement 2 • After the purchase of gasoline, the gas pump reports the dollar amount of the purchase to the GSCS. The maximum value of a purchase is $999.99. The GSCS then causes the gas pump interface to query the customer as to payment type. • Functional Requirement 4 • If payment is to be made by credit card, then the card reader sends the account number to the GSCS. If the GSCS receives an invalid card number, than a message is sent to the gas pump interface asking the customer to swipe the card through the card reader again. After the account number is obtained, the account number and purchase price are sent to the credit card system, and the GSCS and gas pump interface are reset to their initial state. The purchase price sent can be up to $10000. ? • Information was described inconsistently • Because we don’t know from domain knowledge which of the two descriptions is correct, we have found a defect.

11. Discussion • Do you think you understand how to look for the various defect types in this document? • What kinds of difficulties did you have? • If you hadn’t seen the “answers” would you have been able to find the defects listed? • Any one thinks (focusing on faults) is hard or ineffective?

12. To err is human…

13. To err is software engineer(still human)…

14. Human Error vs Fault • Human error is a flaw in the human thought process made while trying to understand given information, solve problems, or to use methods and tools. • Fault is a concrete manifestation of an error in a software artifact

15. Human Errors EXECUTION PLANNING EXECUTION Mistakes happen as a result of inadequate planning, mostly from a lack of knowledge. Occurs when we intend to perform one action, but instead do another, due to lack of attention. Lapses are defined as forgetting one or more steps in a process. When a person does something they intended to do, but should have done something else When a person does something, but not what they meant to do

16. Human Error Taxonomy

17. What caused that fault? New Fault List Error Report Form PGCS Requirements Inspection 10 real faults review

18. Error Abstraction • Error abstraction process helps to abstract “errors” from the faults. It includes: • Abstracting the underlying reasons for the occurrence of the fault and Write down the errors (Mapping errors to faults) • Analyze the given fault: • Which RE activity? • Was it a mistake (planning failure) or slip (attention failure) or lapse (memory failure)? • Refer the human error taxonomy to find the most appropriate human error class. • Briefly explain the human error. • Use Human Error taxonomy to document more errors that may have happened during the development. Your error list should be a comprehensive list of the errors committed during the development

19. An Error Abstraction Example – Grocery Store Register Consider the requirement: • “The software shall calculate the area of a triangle as the base multiplied by the height”

20. An Error Abstraction Example – Grocery Store Register Consider the requirement: • “The software shall calculate the area of a triangle as the base multiplied by the height”

21. Exercise Tasks List of 10 Faults • Abstract and Classify Errors • Fill an Error Report Form • Inspect SRS using errors to find the rest of the faults. • Fill a Fault Report form Error Report Form New Fault List

22. Error Report Form • Use “Error Report Form” to log errors corresponding to each fault (from the given list of 10 faults) and additional errors from Human Error Taxonomy. List of 10 faults Error Report Form

23. Error Report Form

24. Error Report Form : Example

25. Exercise Tasks List of 10 Faults • Abstract and Classify Errors • Fill an Error Report Form • Inspect SRS using errors to find the rest of the faults. • Fill a Fault Report form Error Report Form New Fault List

26. Inspecting SRS: Use error information to find more faults • Use the error information from the "Error Report" and your knowledge of Human errors to inspect the SRS document: • For each error in the “Error Report Form”, inspect the SRS for fault(s) caused by it • For each new fault found, complete a row in the "New Fault List" • An error can cause one or more faults New Fault List Form Error Report Form

27. New Fault List Form Error Report Form New Fault List Form

28. New Fault List Form : Example