Human Errors and the Error Abstraction Process 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

Outline of Training Human Errors RE Activities Tracing back Requirements Faults to Human Errors Task Description Need to be redone © 2009 North Dakota State University September 29, 2009

To err is software engineer(still human)…

Requirements Engineering Activities Elicitation Analysis Verification Requirements Management Specification Elicitation: Gathering requirements involves obtaining all relevant information that will help in understanding the customer's requirements. Customer's requirements can be classified as business, functional, interface, operating environment, performance, standards, and special requirements. Analysis: The goal of analysis is to identify the requirements in a complete, accurate, consistent and unambiguous fashion from the information collected. Analysis accomplishes this by constructing models of the system. The models concentrate on describing what a system does rather than how it does it. Specification: This task involves documenting the objectives and scope of the system and consolidating the process model, data model, and data dictionary etc. into a document Management: Requirements management is the process of tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. Change management, prioritization, maintaining traceability, and logistics (user meetings, req. gathering sessions, etc.)

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 Taking Action Execution Errors Slips Memory Failures Lapses Processing & Decision Making Planning Errors Lack of Knowledge Mistakes Sensing & Perception Human Information- Processing stages Cognitive Failure Mechanisms Human Errors

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: Pours orange juice in cereal instead of milk 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 Lapse Mistake Lapse

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 Lapse Mistake

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

Abstracting Human Errors form Requirement Faults (HEAA)

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. Line# Fault description Human Error Description 3;89 "To create unique" - this line is ambiguous. It might be ID# or Order#. 1. Requirement activity that you selected: 2. Human error type 3. Human error : 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) or grammatical rules of a formal requirement specification language. Elicitation: Gathering requirements involves obtaining all relevant information that will help in understanding the customer's requirements. Customer's requirements can be classified as business, functional, interface, operating environment, performance, standards, and special requirements. Analysis: The goal of analysis is to identify the requirements in a complete, accurate, consistent and unambiguous fashion from the information collected. Analysis accomplishes this by constructing models of the system. The models concentrate on describing what a system does rather than how it does it. Specification: This task involves documenting the objectives and scope of the system and consolidating the process model, data model, and data dictionary etc. into a document Management: Requirements management is the process of tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. Change management, prioritization, maintaining traceability, and logistics (user meetings, req. gathering sessions, etc.) 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)

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. Line# Fault description Human Error Description 7; 261 Alarm for payment is “sent to whom” is omitted. To which actor is the alarm message sent? 1. Requirement activity that you selected: 2. Human error type 2. Human error: 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 Elicitation: Gathering requirements involves obtaining all relevant information that will help in understanding the customer's requirements. Customer's requirements can be classified as business, functional, interface, operating environment, performance, standards, and special requirements. Analysis: The goal of analysis is to identify the requirements in a complete, accurate, consistent and unambiguous fashion from the information collected. Analysis accomplishes this by constructing models of the system. The models concentrate on describing what a system does rather than how it does it. Specification: This task involves documenting the objectives and scope of the system and consolidating the process model, data model, and data dictionary etc. into a document Management: Requirements management is the process of tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. Change management, prioritization, maintaining traceability, and logistics (user meetings, req. gathering sessions, etc.) Requirement analyzed without complete information. The analyst should have gone back and checked with the stakeholder.

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. Line# Fault description Human Error Description 3;89 There should be at least 1 alternative scenario. For example, If credit card information is incorrect, then what happens? 1. Requirement activity that you selected: 2. Human error type 3. Human error : 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 Elicitation: Gathering requirements involves obtaining all relevant information that will help in understanding the customer's requirements. Customer's requirements can be classified as business, functional, interface, operating environment, performance, standards, and special requirements. Analysis: The goal of analysis is to identify the requirements in a complete, accurate, consistent and unambiguous fashion from the information collected. Analysis accomplishes this by constructing models of the system. The models concentrate on describing what a system does rather than how it does it. Specification: This task involves documenting the objectives and scope of the system and consolidating the process model, data model, and data dictionary etc. into a document Management: Requirements management is the process of tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. Change management, prioritization, maintaining traceability, and logistics (user meetings, req. gathering sessions, etc.) 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)

Error Abstraction Exercise 1 Handouts – Error Report Forms (Subset of RIM Faults) © 2009 North Dakota State University September 29, 2009