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

2. 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

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

4. 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.)

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

6. 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

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

8. Report human errors for each fault
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.
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)

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.
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.

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.
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)

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