Upload
owen-may
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Inspection of Software Requirements Document
Gursimran Singh [email protected]
North Dakota State University
Training 2: Inspection using Error Abstraction and Classification Method
Error - FaultsAs per IEEE standard terminology:• Fault is a concrete manifestation of an error in a
software artifact
• Error is a defect in the human thought process made while trying to understand given information, solve problems, or to use methods and tools. In the context of software requirements specifications, an error is a basic misconception of the actual needs of a user or customer.
2
3
Fault List
Fault List
Requirements
Inspection
What caused
that fault?
Error List
Error List
Re-Inspection
NewFault List
NewFault List
Training 1:Training 1:
Outline
• How to abstract errors from faults:– Error Abstraction and Error Classification– Error Form
• Re-inspecting SRS using errors to find more faults– New Fault Form
4
Fault List
Fault List
Error List
Error List
NewFault List
NewFault List
Abstracting Errors from Faults
• How to abstract errors from faults:– Error Abstraction and Error Classification– Error Form
5
Fault List
Fault List
Error List
Error List
Error Abstraction• Error abstraction process helps to abstract
errors/mistakes from the faults. It includes doing:– Analysis of the fault lists
• Why each fault (in your fault report form) represents a defect in the SRS?
– Grouping of the related faults• Group faults based on their categories or nature (e.g., G, MF,
MP, MI, ME, AI, II, IF, WS)
– Eliciting the underlying reasons for the occurrence of the faults
• Find pattern in the grouped faults and think of some believed reasoning for these faults to have occurred
– Write down the errors (Mapping errors to faults)
6
Example:Consider these faults:• F1: The requirements say “The system keeps a rental
transaction record for each customer giving out information and currently rented tapes for each customer.” However, an explanation of exactly what information is given out for each customer has been omitted.
• F9: The requirements say that when a tape is rented, the “rental transaction file is updated.” However, what it means to update the rental transaction file is not specified. The information to be stored here is not discussed.
7
Error Abstraction• F1 and F9 – Missing Information (MI) class.
The missing information about “ How the information in the database is to be updated?”
• Error can be that, “how the rentals are to be logged is not completely understood”
• Remember:– It is not always the case that you will find an error
responsible for multiple fault (as in above example) ; Error can be responsible for single faults, and
– Patterns can also be found between errors in different classes
8
ErrorF1
F9
Error Abstraction• Abstracting errors from faults is a very creative
process.• To support the error abstraction process, you
can use the Requirement Error Taxonomy that describes the different types of errors that can occur during the development of requirement document.
9
Requirement Error Taxonomy
10
Error Report Form
• Use “Error Report Form” to log errors corresponding to each fault (from your fault list during the first inspection).
11
Fault List
Fault List
Error List
Error List
Error Report Form / Error List
12
Fault # Page #
Requirement #
Fault Class
Description Time found
Importance level
Probability of causing failure
Break
Training 1:
Fault ListTraining 1:
Fault List
Error # Fault # Description of Error Time found Break (time and date)
Training 2:
Error ListTraining 2:
Error List
Error List : Example
13
Error # Fault # Description of Error
Time found
Break (time and date)
1 3 ……………...........................................
9:30 AM
2 5, 7 ……………………………………… 10:00 AM Break:10 AM; 20th sep
3 12 ……………………………………… 1 PM Resume
12 PM; 21st sep
Outline
• How to abstract errors from faults:– Error Abstraction and Error Classification– Error Form
• Re-inspecting SRS using errors to find more faults– New Fault Form
14
Fault List
Fault List
Error List
Error List
NewFault List
NewFault List
Re-inspecting SRS: Use error information to find more faults
• Use the error information from the "Error List" to re inspect the SRS document:– For each error in the “Error List ”, 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
15
Error ListError List NewFault List
NewFault List
New Fault List
16
Error # Fault # Description of Error Time found Break (time and date)
Training 2:
Error ListTraining 2:
Error List
Error # (from the error-list)
Description of Fault/Faults caused by the error
Fault Class
Page # Time Found
Importance Level
Probability of causing failure
Breaks (Time and Date)
New Fault List : Example
17
Name: Start time & date: 2nd Oct, 9:30 AM
Error #
Description of Fault/Faults caused by the error
Fault Class
Page #
Time Found Importance Level
Probability of causing failure
Breaks (Time and Date)
1. 1………………..2………………..
II, II 3,5 9:45 AM 2,3 3,1
2. ……………….. MF 2 9:50 AM 2 1
3. ……………… 3 9:59 AM 0 1
4. 1………………2…………….3……………….
EF, AI, O
4,3,19
10:00 AM 1, 0, 2 2, 0, 3 Break-11:00 AM, 2nd Resumed-1:00PM, 3rd
5. …………….. O 25 1:25 PM 2 2
6. ……………. G 32 1:50 PM 3 2
7. ……………… AI 12 2:00 PM 4 4
8. ………………. WS 6 2:20 PM 0 0
9. 1……………..2…………….
MI, AI 2, 9 2:50 PM 1, 2 2, 3
End time: #########
Summary
18
Fault List
Fault List
Error List
Error List
NewFault List
NewFault List
Fault # Page #
Requirement #
Fault Class
Description ……… Break
Error # Fault # Description of Error
Time found
Break (time and date)
Error # (from the error-list)
Description of Fault/Faults caused by the error
Fault Class
Page # Time Found
Importance Level
Probability of causing failure
Breaks (Time and Date)
Timeline • Today
– Training 2• How to log errors and new faults during second inspection
• Output– Individual “Error List” and “New Fault List” from
second inspection
19
Thank you!