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

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

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

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.

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.

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

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!

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 Errors Distributed Across RE Activities

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

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

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.

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

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

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)

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

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)

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

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

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

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

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)