Inspection of Software Requirements Document Gursimran Singh Walia North Dakota State University Training 2: Inspection using Error Abstraction and Classification Method

Error - Faults As 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 Requirements Inspection What caused that fault? Error List Re- Inspection New Fault List New Fault List 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 Error List New Fault List New Fault List

Abstracting Errors from Faults How to abstract errors from faults: – Error Abstraction and Error Classification – Error Form 5 Fault 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 Error F1 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 People Errors CommunicationParticipationDomain KnowledgeSpecific ApplicationProcess Execution Other Human Cognition Process Errors Inadequate method of achieving goal ManagementElicitationAnalysisTraceability Documentation Errors Organization No Usage of Standard Specification

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 DescriptionTime found Importance level Probability of causing failure Break Training 1: Fault List Training 1: Fault List Error #Fault #Description of ErrorTime foundBreak (time and date) Training 2: Error List Training 2: Error List

Error List : Example 13 Error #Fault #Description of Error Time found Break (time and date) 13…………… :30 AM 25, 7………………………………………10:00 AMBreak:10 AM; 20 th sep 312………………………………………1 PM Resume 12 PM; 21 st 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 Error List New Fault List New Fault 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 List New Fault List New Fault List

New Fault List 16 Error #Fault #Description of ErrorTime foundBreak (time and date) Training 2: Error List Training 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: 2 nd Oct, 9:30 AM Error # Description of Fault/Faults caused by the error Fault Class Page # Time FoundImportance Level Probability of causing failure Breaks (Time and Date) 1. 1……………….. 2……………….. II, II 3,59:45 AM2,33,1 2. ……………….. MF 29:50 AM21 3. ……………… 39:59 AM ……………… 2……………. 3………………. EF, AI, O 4,3,1 9 10:00 AM1, 0, 22, 0, 3 Break-11:00 AM, 2 nd Resumed-1:00PM, 3 rd 5. …………….. O 251:25 PM22 6. ……………. G 321:50 PM32 7. ……………… AI 122:00 PM44 8. ………………. WS 62:20 PM …………….. 2……………. MI, AI 2, 92:50 PM1, 22, 3 End time: #########

Summary 18 Fault List Error List New Fault List New Fault 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!