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

– Human error taxonomy

– 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 human…

11

To err is software engineer(still human)…

12

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

13

Human Errors

Human Errors

Slips Lapses Mistakes

14

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, but not

what they meant to do

When a person does

something they intended

to do, but should have

done something else

Human Error Taxonomy

15

Slips

Clerical errors

Lack of consistency in the requirement specification

LapsesLoss of information from

stakeholders

Accidentally overlooking requirements

MistakesApplication errors

Environment errors

Information management errors

Wrong assumptions

Poor understanding of one another’s role

Mistaken belief that it is impossible to specify NFR’s in a verifiable form

Not having a clear distinction between client and users

Lack of awareness of sources of requirements

Problem-solution errors

Inadequate requirement process

Syntactic errors

16

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 Human 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)17

An Error Abstraction Example

Consider the requirement:• F1: The requirement says “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? The requirement gathering person did not ask the right questions to the stakeholders because the RE planning was not robust. Which RE activity? ManagementWhich RE practitioner? This is a management mistake.Human Error (from HET): Inadequate Requirement Process

18

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

19

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 Human Error Taxonomy.

20

List of 10

faultsError

List

Error Report Form / Error List

21

Fault # Line# Requirement # Fault Class Description

Error

#

Fault #

Human Error (HET)

Description of Error

Time found

Break (time and date)

Error List : Example

22

Error

#

Fault #

Human Error (HET)

Description of Error

Time found

Break (time

and date)

1 1 Slips –clerical error

……………...........................................

9:30 AM

2 3 Lapses –accidently overlooking requirements

………………………………………

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

3 4 Mistakes –application error

………………………………………

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.

Human Error associated to the corresponding

Fault#. The Human Error Taxonomy (HET)

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

23

List of

10

Faults

Error

List

New

Fault List

Inspecting SRS: Use error information to find more faults

• Use the error information from the "Error List" and your knowledge of Human 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

24

Error ListNew

Fault List

New Fault List

25

Error

#

Fault # Human Error (HET)

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)

Provides a measure of whether

the fault will be easy to find and

fix if failure occurs

Provides a measure of whether

or not the fault will cause failure

if it goes undetected

New Fault List :

Example

26

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.