Human Errors and the Error Abstraction Process

1. Training Human Errors and the Error Abstraction Process Gursimran Walia, Associate Professor of Computer Science Gursimran.Walia@ndsu.edu Vaibhav Anu, Graduate Research Assistant Vaibhav.Anu@ndsu.edu North Dakota State University

2. Outline of Training • Human Errors • RE Activities • Tracing back Requirements Faults to Human Errors • Task Description September 29, 2009

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

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

5. Intention: Drive to grocery store Plan (set of actions): 1. Start the Car 2. Put transmission in reverse 3. Back down the driveway 4. Navigate the route to store Human Errors Human errors occur when someone is trying to do the right thing, but actually does the wrong thing and doesn’t achieve the intended outcome Inattention Slips Execution Errors Taking Action Memory Failures Lapses Processing & Decision Making Planning Errors Lack of Knowledge Mistakes Sensing & Perception Human Information- Processing stages Cognitive Failure Mechanisms Human Errors

6. Mapping Everyday Failures to Human Errors Failure: Pours orange juice in cereal instead of milk Start by answering the following questions: 1. What was the situation/scenario? 2. Did the situation require problem-solving (i.e., plan-development) or did it require the practitioner to perform routine actions (i.e., follow steps of a plan) Does the situation require plan-development? Plan: 1. Pour milk in cereal 2. Eat Cereal 3. Drink Orange Juice Did the error occur while the practitioner was following the steps of a plan? Slip Yes Did the practitioner execute a step incorrectly (i.e., performed an action incorrectly) due to carelessness? No Failure: Drives off with hose in fuel tank Does the situation require plan-development? Yes No Plan: 1. Put pump attached to the hose in the fuel tank 2. Fill tank 3. Stop pump 4. Remove pump from fuel tank. Slip Mistake Lapse Lapse

7. Mapping Everyday Failures to Human Errors Start by answering the following questions: 1. What was the situation/scenario? 2. Did the situation require problem-solving (i.e., plan-development) or did it require the practitioner to perform routine actions (i.e., follow steps of a plan) Failure: A physician misdiagnosing a patient when faced with an unfamiliar clinical situation Did the error occur while the practitioner was following the steps of a plan? What is the situation? Does the practitioner (physician in this case) need to develop a plan? Yes Did the practitioner execute a step incorrectly (i.e., performed an action incorrectly) due to carelessness? Mistake No No Slip Mistake Lapse

8. Task Description What caused that fault? Report human errors for each fault Faults in RIM SRS

9. Abstracting Human Errors form Requirement Faults (HEAA)

10. Abstracting Human Errors from Requirements faults STEP 1: Choose one of the following options to decide where the fault originated: Option (a) – Requirement Analysis.Option (b) – Requirement Elicitation. Option (c) – Requirement Specification.Option (d) – Requirement Management # 1- p3; line89 : "To create unique" - this line is ambiguous. It might be ID# or Order#. Step 2: Consider the scenario & pick the human error type. Specification Slip Step 3: Pick the appropriate Human Error Slips: Clerical Error: Carelessness while documenting specifications from elicited requirements. Lack of consistency In Requirement Specifications: Lack of logical coherence in the requirement specification documentation, which makes it difficult to be interpreted correctly Mistakes: Environment error: misunderstanding or misuse of the requirement specification tools available for use in the project Syntactic error: Misunderstanding of grammatical rules of natural language (English) orgrammatical rules of a formal requirement specification language. Clerical Error SCENARIO: The Requirements Author was inattentive while writing specification. He/she did not write the word 'ID', which makes the sentence open to interpretation (and ambiguous)

11. Abstracting Human Errors from requirements faults STEP 1: Choose one of the following options to decide where the fault originated: Option (a) – Requirement Analysis.Option (b) – Requirement Elicitation. Option (c) – Requirement Specification.Option (d) – Requirement Management #5 - Alarm for payment is “sent to whom” is omitted. To which actor is the alarm message sent? Step 2: Consider the scenario & pick the human error type. Analysis Step 3: Pick the appropriate Human Error Slips: Clerical Error: Carelessness while analyzing elicited requirements Mistakes: Application error: analyst's misunderstanding or lack of knowledge of a part of (or the whole) system or problem Environment error: misunderstanding or misuse of the requirement analysis tools available for use in the project Wrong assumptions made by requirement analyst about user/stakeholder needs or opinions or any incorrect assumptions by RE analysts Low understanding of each other’s roles: RE analyst does not understand the roles of all end users, stakeholders and other RE analysts. Mistaken belief of RE analysts that it is impossible to specify non-functional requirements in a verifiable form Problem-Solution errors: Lack of knowledge of the requirement analysis process and general requirement engineering know-how Mistake Application Error Requirement analyzed without complete information. The analyst should have gone back and checked with the stakeholder.

12. Abstracting Human Errors from Requirements faults STEP 1: Choose one of the following options to decide where the fault originated: Option (a) – Requirement Analysis.Option (b) – Requirement Elicitation. Option (c) – Requirement Specification.Option (d) – Requirement Management #12- p8; line314 : There should be at least 1 alternative scenario. For example, If credit card information is incorrect, then what happens? Step 2: Consider the scenario & pick the human error type. Analysis Mistake Step 3: Pick the appropriate Human Error Slips: Clerical Error: Carelessness while analyzing elicited requirements Mistakes: Application error: analyst's misunderstanding or lack of knowledge of a part of (or the whole) system or problem Environment error: misunderstanding or misuse of the requirement analysis tools available for use in the project Wrong assumptions made by requirement analyst about user/stakeholder needs or opinions or any incorrect assumptions by RE analysts Low understanding of each other’s roles: RE analyst does not understand the roles of all end users, stakeholders and other RE analysts. Mistaken belief of RE analysts that it is impossible to specify non-functional requirements in a verifiable form Problem-Solution errors: Lack of knowledge of the requirement analysis process and general requirement engineering know-how Problem-solution error or Application error SCENARIO: Problem-solution: Lack of knowledge (or experience) about use case modeling. Application: Analyst was not aware of all the possible scenarios (due to inadequate knowledge about the domain)

13. Error Abstraction Exercise 1 Handouts – Error Report Forms (Subset of RIM Faults) September 29, 2009