Inspecting Software Requirement

Document

1

Gursimran Walia, Associate Professor of Computer Science

North Dakota State University

Gursimran.Walia@ndsu.edu

Training

Outline

• Basic concepts and benefits of inspections

• Inspection technique for defect detection: Human errors

• Details of Assignment– SRS and inspection technique distributed

– Abstracting errors and inspection for faults

– Requirements error taxonomy (RET)

– Error and Fault Forms

– Timeline

2

RE Process and Practitioners

3

Elicitation

• Requirement Gathering People

• Stakeholders (End users, customers)

Analysis

• Requirement Analysts

Specification

• Requirement Authors

Verification

• Inspectors

Management

• Project Manager

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

PreviousDevelopment

Phase

Current

Phase

Next

Phase

• 1. Information transformed correctly.

1

• 2. Information lost during transformation.

2

• 3. Information transformed incorrectly.

3

• 4. Extraneous information introduced.

4

• 5. Multiple inconsistent transformations occurred for same info.

5

?

• 6. Multiple inconsistent transformations possible for same info.

?6

5

Software Defect Types

6

Defect detection

7

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

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.

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

Is this the correct response?

8

• 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 $999.99. 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.

9

Requirement defects for Gas Station Control System –

Example 2

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?

10

To err is software engineer (still human)…

11

Requirement Errors

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

Requirement Error Taxonomy

People Errors

Communication

Participation

Domain Knowledge

Specific Application

Process Execution

Other Human Cognition

Process Errors

Inadequate method of achieving goal

Management

Elicitation

Analysis

Traceability

Documentation Errors

Organization

No Usage of Standard

Specification

14

10

real

faults

PGCS

Requirements

review

What

caused

that fault?

Error

List

New

Fault

List

Error Abstraction

• Error abstraction process helps to abstract “errors” from the faults. It includes doing:

– Abstracting the underlying reasons for the occurrence of the fault

• Analyze the given fault:

– What went wrong?

– Which RE activity?

– Which RE practitioner?

• Try to find the origination of the fault in some human RE practitioner's thought process.

• Use Error taxonomy to document more errors that may have happened during the development. Your error list should be comprehensive of the errors committed during the development

– Write down the errors (Mapping errors to faults)

15

An Error Abstraction ExampleConsider the requirement:

F1: The requirements say “The system keeps a rental transaction record for each customer giving out information and currently rented tapes for each customer.”

• Fault: an explanation of exactly what information is given out for each customer has been omitted.

• What went Wrong: Requirement gathering person did not ask the right questions to the stakeholder.

• Error: Requirement Elicitation Error.

16

Exercise Tasks

• 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

17

List of

10

Faults

Error

List

New

Fault List

Error Report Form/Error List

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

18

List of 10

faultsError

List

Error Report Form / Error List

19

Fault # Line# Requirement # Fault Class Description

Error # Fault # Requirement Error (RET)

Description of Error

Time found

Break (time and date)

Error List (Error Report Form) : Example

20

Error# Fault # Requirement Error (RET)

Description of Error

Time found

Break (time and

date)1 1 Communication ……………..............

............................

.

9:30 AM

2 2 Organization ………………………………………

10:00 AM Break:10 AM; 20th sep

3 3 Elicitation ………………………………………

1 PM Resume

12 PM; 21st sep

Serial identification

(e.g. 1, 2, 3, …)

Identification number of the fault from the

Fault form from whom the particular error

was abstracted. This attribute helps to

maintain mapping between the faults and

the error responsible for that fault. For

additional errors found by referencing error

taxonomy, leave the field empty.

Requirement Error associated to the corresponding

Fault#. The Requirement Error Taxonomy (RET)

provides a list of human errors that can occur in

requirement development.

A brief but clear description of the

error (the description should be

clear enough for a developer to

understand the misunderstanding

without having to talk to you)

The time when the error was found.

Log of all the times when you

took break during the

process of abstracting errors

as well as times when you

resumed your work.

Exercise Tasks

• 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

List of

10

Faults

Error

List

New

Fault

List

Inspecting SRS: Use error information to find more faults

• Use the error information in "Error List" and your knowledge of requirement errors to 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

22

Error ListNew

Fault List

New Fault ListError# Fault # Requirement

Error (RET)Description of Error

Time found Break (time and date)

Error# (from the error-list)

Description of Fault/Faults caused by the error

Line# Fault Class

Time Found

Importance Level

Probability of causing failure

Breaks (Time and Date)

Error number as in

the "Error List".

A brief but clear

description of the fault(s)

(the description should be

clear enough for a

developer to understand

and fix the problem

without having to talk to

you). Also a single human

error may or may not lead

to single or multiple faults

and so, each fault should

be described separately.

Line

number in

the SRS

where fault

was found

(e.g. 1, 2,

3, …)

The time

when the

fault was

found.

The importance of a the fault classified as:

0: Not important, designer should easily see the problem

1: Problem, if a failure occurs it should be easy to find and fix (e.g. change to 1 module)

2: Important, if a failure occurs, it could be hard to find and fix (e.g. change to few modules)

3: Very important, if a failure occurs, it could be hard to find and fix (e.g. change to several modules)

4: If a failure occurs, it could cause a redesign

The probability that the fault will cause system failure classified as:

0: Will not cause fault or failure, regardless whether it is caught by

designer

1: Will not cause fault or failure, will be caught by designer

2: Could cause a failure but will most likely be caught by designer

3: Will cause a failure

The time when you took break and

when you resumed back your review.

New Fault List :

Example

24

Name: Start time & date: 2nd Oct, 9:30 AM

Error#

(from the error-list )

Description of Fault/Faults caused by the error

Line # Fault Class

Time Found

Importance Level

Probability of causing failure

Breaks (Time and Date)

1 1………………..

2………………..35 II, II 9:45 AM 2,3 3,1

2 ……………….. 234 MF 9:50 AM 2 1

3 ……………… 309 9:59 AM 0 1

4 1………………

2…………….

3……………….

43 EF, AI, O

10:00 AM

1, 0, 2 2, 0, 3 Break-11:00 AM, 2nd

Resumed-1:00PM, 3rd

5 …………….. 25 O 1:25 PM 2 2

6 ……………. 321 G 1:50 PM 3 2

7 ……………… 125 AI 2:00 PM 4 4

8 ………………. 62 WS 2:20 PM 0 0

…… 1……………..

2…………….2, 9 MI, AI 2:50 PM 1, 2 2, 3

End time: #########

Error number as in

the "Error List".

A brief but clear description of the

fault(s) (the description should be clear

enough for a developer to understand

and fix the problem without having to

talk to you). Also a single human error

may or may not lead to single or multiple

faults and so, each fault should be

described separately.

Line

number in

the SRS

where fault

was found

(e.g. 1, 2,

3, …)

The time

when the

fault was

found.

The importance of a the fault classified as:

0: Not important, designer should easily see the problem

1: Problem, if a failure occurs it should be easy to find and fix (e.g. change to 1 module)

2: Important, if a failure occurs, it could be hard to find and fix (e.g. change to few modules)

3: Very important, if a failure occurs, it could be hard to find and fix (e.g. change to several modules)

4: If a failure occurs, it could cause a redesign

The probability that the fault will cause system failure classified as:

0: Will not cause fault or failure, regardless whether it is caught by

designer

1: Will not cause fault or failure, will be caught by designer

2: Could cause a failure but will most likely be caught by designer

3: Will cause a failure

The time when

you took break

and when you

resumed back

your review.