Using Human Errors to Inspect SRS

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

2. Outline • 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: “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 Management Elicitation Analysis Verification Specification Requirements Engineering Activities Requirements Engineering

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 EXECUTION PLANNING EXECUTION Mistakes happen as a result of inadequate planning, mostly from a lack of knowledge. 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. 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. What caused that fault? New Fault List Error Report Form PGCS Requirements Inspection 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

16. An Error Abstraction Example 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

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 Report Form New Fault List

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

21. Error Report Form : Example

22. Exercise Tasks 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 September 29, 2009

25. New Fault List Form Error Report Form New Fault List Form