Inspecting Software Requirement Document Training Inspecting Software Requirement Document

Outline Details of Assignment 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

Requirements Engineering Activities Elicitation Analysis Verification Requirements Management Specification

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!

What is an Inspection? Definition: Inspections “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)

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. Previous Development Phase Current Next 1. Information transformed correctly. 1 2. Information lost during transformation. 2 5. Multiple inconsistent transformations occurred for same info. 5 ? 3. Information transformed incorrectly. 3 6. Multiple inconsistent transformations possible for same info. ? 6 4. Extraneous information introduced. 4

Software Defect Types

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

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.

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.

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?

To err is human…

To err is software engineer(still human)…

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

Human Errors Human Errors Slips Lapses Mistakes EXECUTION EXECUTION PLANNING 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. Mistakes happen as a result of inadequate planning, mostly from a lack of knowledge. 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

Human Error Taxonomy

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

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

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” Error # Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) 1 ………… This requirement is incorrect as the area of a triangle is calculated as one-half of the base multiplied by the height.   Incorrect Information (IF)  1. RE activity in which the human error occurred (pick one): Elicitation Analysis Specification Verification Management 2. Did the error occur due to (pick one): Lack of knowledge (Mistake) Carelessness (Slip) Forgetting a task (Lapse) 3. Classify the error into a human error class (from HET): 4. Briefly explain the human error (what was the defect in the thought process):

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” Error # Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) 1 ………… This requirement is incorrect as the area of a triangle is calculated as one-half of the base multiplied by the height.   Incorrect Information (IF)  1. RE activity in which the human error occurred (pick one): Elicitation Analysis Specification Verification Management 2. Did the error occur due to (pick one): Lack of knowledge (Mistake) Carelessness (Slip) Forgetting a task (Lapse) 3. Classify the error into a human error class (from HET): Application Error 4. Briefly explain the human error (what was the defect in the thought process): The requirement analyst’s lack of knowledge of the problem domain (geometry in this case) leads him/her into incorrectly analyzing the user need (which was to calculate the area of the triangle).

Exercise Tasks Abstract and Classify Errors Fill an Error Report Form 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 # Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) Error Report Form New Fault List Error # (from Error Report form in Task 1) Description of fault (s) caused by the error Line # in SRS Fault Class Time Found Break (Time and date)

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

Error Report Form Error # Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) 1 170; FR 7 …………………………………… ………………………………….. ………………………. Omission (O) 1. RE activity in which the human error occurred (pick one): Elicitation Analysis Specification Verification Management 2. Did the error occur due to (pick one): Lack of knowledge (Mistake) Carelessness (Slip) Forgetting a task (Lapse) 3. Classify the error into a human error class (from HET): 4. Briefly explain the human error (what was the defect in the thought process): 2 220; FR 17 Wrong Section (WS)

Error Report Form : Example Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) 1 170; FR 7 …………………………………… ………………………………….. ………………………. Omission (O) 1. RE activity in which the human error occurred (pick one): Elicitation Analysis Specification Verification Management 2. Did the error occur due to (pick one): Lack of knowledge (Mistake) Carelessness (Slip) Forgetting a task (Lapse) 3. The most appropriate human error class (from HET): …………………………………………… 4. Briefly explain the human error (what was the defect in the thought process): ...................................................................... 2 220; FR 17 Wrong Section (WS) …………………………………………. ……………………………………………………………………… Break: 10 AM, 14th Oct Resume: 6 PM, 15th Oct

Exercise Tasks Abstract and Classify Errors Fill an Error Report Form 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

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

New Fault List Form Error # Line #; Req # in SRS Fault Description Error Report Form Error # Line #; Req # in SRS Fault Description Fault classification Description of Error Break (Time and date) 1 2 New Fault List Form Error # (from Error Report form in Task 1) Description of fault (s) caused by the error Line # in SRS Fault Class Time found Break (Time and date)

New Fault List Form : Example Error # (from Error Report form in Task 1) Description of fault (s) caused by the error Line # in SRS Fault Class Time Found Break (Time and date) 1 …………………………………………………. 35 216 II WS 9:30 AM, 2nd Oct 2 ………………………………………………………………………………………………………. 134 O 10:30 AM, 2nd Oct Break-11:00 AM, 2nd Oct Resumed-1:00PM, 3rd Oct 3 3. ………………………………………………………………. 220 117 321 E IF A 1:30 PM, 3rd Oct