1. Inspecting Software Requirement Document
Training
Inspecting Software Requirement Document

2. Outline Details of Assignment
Basic concepts and benefits of inspections
Error vs. fault
Inspecting SRS for errors and faults: Human errors
Details of Assignment
SRS and inspection technique distributed
Abstracting errors and inspection for faults
Human error taxonomy
Error and Fault Forms

3. Requirements Engineering Activities
Elicitation
Analysis
Verification
Requirements Management
Specification

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

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

6. Software Defects
In a generic sense, defects arise when the development work being done doesn’t match the software specifications already developed or would cause problems downstream.
Previous
Development
Phase
Current
Next
1. Information transformed correctly. 1
2. Information lost during transformation. 2
5. Multiple inconsistent transformations occurred for same info. 5 ?
3. Information transformed incorrectly. 3
6. Multiple inconsistent transformations possible for same info. ? 6
4. Extraneous information introduced. 4

7. Software Defect Types

8. Defect detection Question: How does one detect fault?
Answer: 1 By reading the document
2 By understanding what the document describes 3 By realizing that there is a problem in the requirements

9. Requirement defects for Gas Station Control System – Example 1
Functional Requirement # 3
If the customer has selected to pay at the time of purchase, he or she can choose to pay by cash or credit card. If the customer selects cash, the gas pump interface instructs the customer to see the cashier. If the customer selects credit card, the gas pump interface instructs the customer to swipe his or her credit card through the credit card reader. If an invalid or no selection is made, the GSCS will use the credit card payment option, which is the default.
Is this the correct response?
Information was translated incorrectly
In the example, domain knowledge should indicate that defaulting to credit card payment is an incorrect response. (What kind of transaction ever happens this way?)
Because we know that this functionality should not be implemented the way it is described, we have a defect.

10. Requirement defects for Gas Station Control System – Example 2
Functional Requirement 2
After the purchase of gasoline, the gas pump reports the dollar amount of the purchase to the GSCS. The maximum value of a purchase is $ The GSCS then causes the gas pump interface to query the customer as to payment type.
Functional Requirement 4
If payment is to be made by credit card, then the card reader sends the account number to the GSCS. If the GSCS receives an invalid card number, than a message is sent to the gas pump interface asking the customer to swipe the card through the card reader again. After the account number is obtained, the account number and purchase price are sent to the credit card system, and the GSCS and gas pump interface are reset to their initial state. The purchase price sent can be up to $10000. ?
Information was described inconsistently
Because we don’t know from domain knowledge which of the two descriptions is correct, we have found a defect.

11. Discussion
Do you think you understand how to look for the various defect types in this document?
What kinds of difficulties did you have?
If you hadn’t seen the “answers” would you have been able to find the defects listed?
Any one thinks (focusing on faults) is hard or ineffective?

12. To err is human…

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

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

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

16. Human Error Taxonomy

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

18. Error Abstraction
Error abstraction process helps to abstract “errors” from the faults. It includes:
Abstracting the underlying reasons for the occurrence of the fault and Write down the errors (Mapping errors to faults)
Analyze the given fault:
Which RE activity?
Was it a mistake (planning failure) or slip (attention failure) or lapse (memory failure)?
Refer the human error taxonomy to find the most appropriate human error class.
Briefly explain the human error.
Use Human Error taxonomy to document more errors that may have happened during the development. Your error list should be a comprehensive list of the errors committed during the development

19. An Error Abstraction Example – Grocery Store Register
Consider the requirement:
“The software shall calculate the area of a triangle as the base multiplied by the height”
Error #
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
…………
This requirement is incorrect as the area of a triangle is calculated as one-half of the base multiplied by the height.
Incorrect
Information (IF)
 1. RE activity in which the human error occurred (pick one):
Elicitation
Analysis
Specification
Verification
Management
2. Did the error occur due to (pick one):
Lack of knowledge (Mistake)
Carelessness (Slip)
Forgetting a task (Lapse)
3. Classify the error into a human error class (from HET):
4. Briefly explain the human error (what was the defect in the thought process):

20. An Error Abstraction Example – Grocery Store Register
Consider the requirement:
“The software shall calculate the area of a triangle as the base multiplied by the height”
Error #
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
…………
This requirement is incorrect as the area of a triangle is calculated as one-half of the base multiplied by the height.
Incorrect
Information (IF)
 1. RE activity in which the human error occurred (pick one):
Elicitation
Analysis
Specification
Verification
Management
2. Did the error occur due to (pick one):
Lack of knowledge (Mistake)
Carelessness (Slip)
Forgetting a task (Lapse)
3. Classify the error into a human error class (from HET):
Application Error
4. Briefly explain the human error (what was the defect in the thought process):
The requirement analyst’s lack of knowledge of the problem domain (geometry in this case) leads him/her into incorrectly analyzing the user need (which was to calculate the area of the triangle).

21. Exercise Tasks Abstract and Classify Errors Fill an Error Report Form
List of 10 Faults
Abstract and Classify Errors
Fill an Error Report Form
Inspect SRS using errors to find the rest of the faults.
Fill a Fault Report 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)
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Time Found
Break (Time and date)

22. Error Report Form
Use “Error Report Form” to log errors corresponding to each fault (from the given list of 10 faults) and additional errors from Human Error Taxonomy.
List of 10 faults
Error
Report Form

23. Error Report Form Error # Line #; Req # in SRS Fault Description
Fault classification
Description of Error
Break (Time and date) 1
170; FR 7
……………………………………
…………………………………..
……………………….
Omission (O)
1. RE activity in which the human error occurred (pick one):
Elicitation
Analysis
Specification
Verification
Management
2. Did the error occur due to (pick one):
Lack of knowledge (Mistake)
Carelessness (Slip)
Forgetting a task (Lapse)
3. Classify the error into a human error class (from HET):
4. Briefly explain the human error (what was the defect in the thought process): 2
220; FR 17
Wrong Section (WS)

24. Error Report Form : Example
Line #; Req # in SRS
Fault Description
Fault classification
Description of Error
Break (Time and date) 1
170; FR 7
……………………………………
…………………………………..
……………………….
Omission (O)
1. RE activity in which the human error occurred (pick one):
Elicitation
Analysis
Specification
Verification
Management
2. Did the error occur due to (pick one):
Lack of knowledge (Mistake)
Carelessness (Slip)
Forgetting a task (Lapse)
3. The most appropriate human error class (from HET):
……………………………………………
4. Briefly explain the human error (what was the defect in the thought process): 2
220; FR 17
Wrong Section (WS)
………………………………………….
………………………………………………………………………
Break: 10 AM, 14th Oct
Resume: 6 PM, 15th Oct

25. Exercise Tasks Abstract and Classify Errors Fill an Error Report Form
List of 10 Faults
Abstract and Classify Errors
Fill an Error Report Form
Inspect SRS using errors to find the rest of the faults.
Fill a Fault Report form
Error Report Form
New
Fault List

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

27. 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)
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Time found
Break (Time and date)

28. New Fault List Form : Example
Error # (from Error Report form in Task 1)
Description of fault (s) caused by the error
Line # in SRS
Fault Class
Time Found
Break (Time and date) 1
…………………………………………………. 35
216 II WS
9:30 AM, 2nd Oct 2
……………………………………………………………………………………………………….
134 O
10:30 AM, 2nd Oct
Break-11:00 AM, 2nd Oct
Resumed-1:00PM, 3rd Oct 3
……………………………………………………………….
220
117
321 E IF A
1:30 PM, 3rd Oct