1. Using Human Errors to Inspect SRS
Training
Using Human Errors to Inspect SRS
Gursimran Walia, Associate Professor of Computer Science
North Dakota State University

2. Outline Details of Exercise Why focus on errors? Error vs. fault
Inspecting SRS for errors and faults: Human errors
Details of Exercise
SRS and Human Error Taxonomy
Abstracting errors and inspection for faults
Error Drill-down questionnaire distributed
Error and Fault Forms

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

4. Software Defect Types

5. Fault Checklist Based Inspections
Inspectors answer questions while reading the document
These questions concern quality aspects of the SRS document.
Fault checklist fails to target the problems of the requirements development process.
If one can get hold of the process problems (underlying causes of faults), one can find other related faults.

6. Where do these Process Problems Happen?
Humans involved in the process might have flawed thought process, which leads them to commit mistakes.
So, the underlying causes of faults are flaws in the thought process of the humans involved in requirements development process.
Added another layer to Fault Checklist based inspections – use of human error theories to find more faults.

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

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

9. Requirements Engineering Activities
Elicitation
Analysis
Verification
Requirements Management
Specification

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

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

12. Human Errors Distributed Across RE Activities

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

14. Error Abstraction
Error abstraction process (abstracting the underlying reasons for the occurrence of the fault and writing down the errors )
Analyze the given fault using the Error Abstraction Drill Down Questionnaire
Document more issues/problems/faults that you see in the SRS as you analyze faults and abstract errors for them.
your error list should be a comprehensive list of the errors committed during the development

15. An Error Abstraction Example
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
123,168,272; FR7
Use of terms: “monthly ticket”, “reserved ticket”, and “access card” for the same entity.
Ambiguous Information (A)
1. RE activity in which the human error occurred (pick one):
Analysis Elicitation Specification Management
2. Please write the task/problem statement you created to describe the task that was being performed when this fault happened:
3. The human error(s) you picked (from the box):
4. Briefly explain the human error(s) you picked. Your explanation of the human error should be in context of the fault.

16. An Error Abstraction Example
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
123,168,272; FR7
Use of terms: “monthly ticket”, “reserved ticket”, and “access card” for the same entity.
Ambiguous Information (A)
1. RE activity in which the human error occurred (pick one):
Analysis Elicitation Specification Management
2. Please write the task/problem statement you created to describe the task that was being performed when this fault happened:
3. The human error(s) you picked (from the box):
4. Briefly explain the human error(s) you picked. Your explanation of the human error should be in context of the fault.
Requirement gathering person was collecting requirements about the reserved parking spaces from the stakeholder(s)
Clerical Error
During the interview, stakeholder (or maybe there were multiple stakeholders) used multiple terms and even the requirement gathering person did not correct the stakeholder(s).
So, this happened due to the carelessness of requirement gathering person while elicitation of the requirements.
Exercise Form Handouts

17. Task 1 Part b: Finding Additional Human Errors
Task 1 has 2 activities that you carry out in parallel:
Abstracting errors from 6 given faults.
As you are abstracting human errors from the given faults, if you find any other issues or problem areas in the SRS document.
Make a note of the Line# and Req# where you think this issue/problem/fault is and write a brief description. Then, abstract the human error from this issue/problem/fault as you have done for the given 6 faults
Error #
Line #; Req # in SRS
Description of the issue/problem/fault
Description of Error
Break (Time and date) 7
1. RE activity in which the human error occurred (pick one):
Analysis Elicitation Specification Management
2. Please write the task/problem statement you created to describe the task that was being performed when this fault happened:
3. The human error(s) you picked (from the box):
4. Briefly explain the human error(s) you picked. Your explanation of the human error should be in context of the fault. 8

18. Exercise Tasks and Exercise Forms
List of 6 Faults
Abstract and Classify Errors
Fill ‘Error Report Form’
Inspect SRS using errors to find the rest of the faults.
Fill ‘New Fault-List 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)
“Human Error+Fault” Statement you created to find new faults
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Break (Time and date)

19. Task 1: Error Report Form
Use “Error Report Form” to log human errors corresponding to each fault (from the given list of 6 faults) and additional errors from Human Error Taxonomy.
List of 6 faults
Error
Report Form

20. Task 1: Error Report Form
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
123,168,272; FR7
Use of terms: “monthly ticket”, “reserved ticket”, and “access card” for the same entity.
Ambiguous Information (A)
1. RE activity in which the human error occurred (pick one):
Analysis Elicitation Specification Management
2. Please write the task/problem statement you created to describe the task that was being performed when this fault happened:
3. The human error(s) you picked (from the box):
4. Briefly explain the human error(s) you picked. Your explanation of the human error should be in context of the fault.  
272; FR7
Missing test. r>.4k
Omission (O)

21. Error Report Form : Example
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
123,168,272; FR7
Use of terms: “monthly ticket”, “reserved ticket”, and “access card” for the same entity.
Ambiguous Information (A)
1. RE activity in which the human error occurred (pick one):
Analysis Elicitation Specification Management
2. Please write the task/problem statement you created to describe the task that was being performed when this fault happened:
Requirement gathering person was collecting requirements about the reserved parking spaces from the stakeholder(s)
3. The human error(s) you picked (from the box):
 Clerical Error
4. Briefly explain the human error(s) you picked. Your explanation of the human error should be in context of the fault.
During the interview, stakeholder (or maybe there were multiple stakeholders) used multiple terms and even the requirement gathering person did not correct the stakeholder(s).
So, this happened due to the carelessness of requirement gathering person while elicitation of the requirements.
272; FR7
Missing test. r>.4k
Omission (O)
Analysis Elicitation Specification Management
……………………………………………………………………………………………….
 ………………………………
………………………………………………………………………………………………………………………………
…………………………………

22. Exercise Tasks Abstract and Classify Errors Fill ‘Error Report Form’
List of 6 Faults
Abstract and Classify Errors
Fill ‘Error Report Form’
Inspect SRS using errors to find the rest of the faults.
Fill ‘New Fault-List Form’
Error Report Form
New
Fault List

23. Task 2: 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

24. Task 2: New Fault-List Form
Remember the following fault that we abstracted human error for:
Use of terms: “monthly ticket”, “reserved ticket”, and “access card” for the same entity.
We found the requirement gathering person guilty of carelessness and it resulted in usage of multiple terms for the same entity in the SRS
Create an investigative statement using this information
Error # (from Error Report form in Task 1)
“Human Error+Fault” Statement you created to find new faults
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Break (Time and date) 1
Did carelessness on part of the requirement gathering person (or analyst, or requirements author) person cause other instances of usage of multiple terms for the same entity?
1…………..
2……………………..
3…………………………………
1………….
2………
3………….
1……….
2……………
3…… 2
…………………………………..
………………………………..
1…………………..
2………………………….
© 2009 North Dakota State University
September 29, 2009

25. 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)
“Human Error+Fault” Statement you created to find new faults
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Break (Time and date)