Inspection of Software Requirements Document

Gursimran Singh WaliaGursimran.Walia@ndsu.edu

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!

Gursimran.walia@ndsu.edu