13-Lecture XIII

(1)

COMSATS Institute of Information Technology, Attock

1 _{Farhan Aadil}

Farhan Aadil

Assistant Professor

COMSATS Institute of Information Technology

Lecture 13

Requirement Errors

(2)

2 _{Farhan Aadil}

Quiz 4

(3)

3 _{Farhan Aadil}

3

Today’s Topics

• Requirements errors

(4)

4 _{Farhan Aadil}

4

(5)

5 _{Farhan Aadil}

5

Requirements Error/Defect

(6)

6 _{Farhan Aadil}

6

Requirements Errors - 1

• Errors and omissions find their way in different requirements documents

(7)

7 _{Farhan Aadil}

7

Requirements Errors - 2

• It is difficult to detect requirements errors once they flow downstream

(8)

8 _{Farhan Aadil}

8

Types of Requirements Errors

• Errors of omission

• Errors of clarity and ambiguity

(9)

9 _{Farhan Aadil}

9

Errors of Omission

• Errors of omission are most common among requirements errors

(10)

10 _{Farhan Aadil}

10

Errors of Clarity and Ambiguity

• Second most common errors are those of clarity and ambiguity

• Primarily, because natural languages (like English) are used to state requirements, while such languages are themselves ambiguous

(11)

11 _{Farhan Aadil}

11

Performance Errors

• Performance, that is errors of speed and capacity, are also found in requirements

(12)

12 _{Farhan Aadil}

12

Negative Impact of Requirements Errors - 1

• The resulting software may not satisfy user’s real needs • Multiple interpretations of requirements may cause

(13)

13 _{Farhan Aadil}

13

Negative Impact of Requirements Errors - 2

• Negative impact on humans

– Unsatisfied customers and developers

(14)

14 _{Farhan Aadil}

14

Addressing Requirements Errors

(15)

15 _{Farhan Aadil}

15

Prevention vs. Removal

• For requirements errors, prevention is usually more effective than removal

• Joint application development (JAD), quality function

deployment (QFD), and prototyping are more effective in defect prevention

(16)

16 _{Farhan Aadil}

16

Defect Prevention - 1

• Don’t let defects/errors become part of the requirements document or requirements model in the first place

• How is it possible?

(17)

17 _{Farhan Aadil}

17

Defect Prevention - 2

• Training in different requirements engineering activities (elicitation, analysis and negotiation, specification, and validation) is also very important for defect prevention

(18)

18 _{Farhan Aadil}

18

Defect Prevention - 3

(19)

19 _{Farhan Aadil}

19

Defect Prevention - 4

• An overall commitment to quality and emphasis on using documented processes is also a very important

(20)

20 _{Farhan Aadil}

20

(21)

21 _{Farhan Aadil}

21

Inspections - 1

• Inspections, by all accounts, do a better job of error removal than any competing technology, and they do it at a lower cost

(22)

22 _{Farhan Aadil}

22

Inspections - 2

• Inspections are conducted by a group of people working on the project, with the objective to remove defects or errors

(23)

23 _{Farhan Aadil}

23

Inspections - 3

• Requirements errors detected during this inspections save lot of money and time as requirements errors do not flow into the design and development phases of software

(24)

24 _{Farhan Aadil}

24

Inspections - 4

• A complete description of inspections must address five dimensions:

(25)

25 _{Farhan Aadil}

25

Defect Detection Without Inspections

Requirements Design Coding Documentation Testing Maintenance

Requirements Design Coding Documentation Testing Maintenance

Defect Origins

(26)

26 _{Farhan Aadil}

26

Defect Detection With Inspections

Requirements Design Coding Documentation Testing Maintenance

Requirements Design Coding Documentation Testing Maintenance

Defect Origins

(27)

27 _{Farhan Aadil}

27

Observations

• Requirements engineers are trained to write requirements documents, but have no training on reading/reviewing

requirements documents

(28)

28 _{Farhan Aadil}

28

Techniques for Reading Requirements

Documents

• Ad hoc review • Checklist review

• Defect-based reading

(29)

29 _{Farhan Aadil}

29

Ad hoc Review

(30)

30 _{Farhan Aadil}

30

Checklist Review

(31)

31 _{Farhan Aadil}

31

Defect-based Reading

• Provides a set of systematic procedures that reviewers can follow, which are tailored to the formal software cost

(32)

32 _{Farhan Aadil}

32

Perspective-Based Reading (PBR)

• Researchers at Experimental Software Engineering Group at the University of Maryland, College Park, have created

Perspective-Based Reading (PBR) to provide a set of

(33)

33 _{Farhan Aadil}

33

Different Perspectives - 1

• PBR operates under the premise that different information in the requirements is more or less important for the different uses of the document

(34)

34 _{Farhan Aadil}

34

Different Perspectives - 2

• PBR provides a set of individual reviews, each from a

particular requirements user’s point of view, that collectively cover the document’s relevant aspects

(35)

35 _{Farhan Aadil}

35

Steps in PBR

• Selecting a set of perspectives for reviewing the requirements document

• Creating or tailoring procedures for each perspective usable for building a model of the relevant requirements information

• Augmenting each procedure with questions for finding defects while creating the model

(36)

36 _{Farhan Aadil}

36

Two Questions

• What information in these documents should they check?

(37)

37 _{Farhan Aadil}

37

Benefits of Different

Perspectives - 1

• Systematic

– Explicitly identifying the different uses for the

requirements gives reviewers a definite procedure for verifying whether those uses are achievable

• Focused

(38)

38 _{Farhan Aadil}

38

Benefits of Different

Perspectives - 2

• Goal-oriented and customizable

– Reviewers can tailor perspectives based on the current goals of the organization

• Transferable via training

– PBR works from a definite procedure, and not the

(39)

39 _{Farhan Aadil}

39

Identifying Defects

• A series of questions are used to identify different types of requirements defects

• Requirements that do not provide enough information to answer the questions usually do not provide enough

(40)

40 _{Farhan Aadil}

40

Requirements Defects that PBR Helps

Detect

• Missing information • Ambiguous information • Inconsistent information • Incorrect fact

(41)

41 _{Farhan Aadil}

41

Missing Information - 1

• Any significant requirement related to functionality,

performance, design constraints, attributes, or external interface not included

(42)

42 _{Farhan Aadil}

42

Missing Information - 2

• Sections of the requirements document

(43)

43 _{Farhan Aadil}

43

Ambiguous Information

(44)

44 _{Farhan Aadil}

44

Inconsistent Information

(45)

45 _{Farhan Aadil}

45

Incorrect Facts

(46)

46 _{Farhan Aadil}

46

Extraneous Information

(47)

47 _{Farhan Aadil}

47

Miscellaneous Defects

(48)

48 _{Farhan Aadil}

48

Benefits of PBR’s Detailed Questions

• Allow controlled improvement

– Reviewers can reword, add, or delete specific questions

• Allow training

– Reviewers can train to better understand the parts of a

(49)

49 _{Farhan Aadil}

49

PBR General Questions - 1

• Does the requirement make sense from what you know

about the application or from what is specified in the general description?

• Do you have all the information necessary to identify the inputs to the requirement? Based on the general

(50)

50 _{Farhan Aadil}

50

PBR General Questions - 2

• Have any of the necessary inputs been omitted?

• Are any inputs specified that are not needed for this requirement?

(51)

51 _{Farhan Aadil}

51

Results of PBR Experiments - 1

• PBR provides a framework that represents an improved approach for conducting requirements reviews

(52)

52 _{Farhan Aadil}

52

Results of PBR Experiments - 2

• PBR seems best suited for reviewers with a certain range of experience (not too little; not too much)

(53)

53 _{Farhan Aadil}

53

• Relatively novice reviewers can use PBR techniques to apply their expertise in other development tasks to defect detection

(54)

54 _{Farhan Aadil}

54

Results of PBR Experiments - 4

• It creates high-level representations of the software system, usable as a basis of work products in later stages of the

development

(55)

55 _{Farhan Aadil}

55

• PBR facilitates controlled improvements, providing a definite procedure, alterable according to projects metrics and

(56)

56 _{Farhan Aadil}

56

Summary

• Introduced the concept of requirements errors and types of requirements errors

• Discussed the impact of requirements errors • Discussed error prevention in requirements

(57)

57 _{Farhan Aadil}

57

References

• ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998

• Software Quality: Analysis and Guidelines for Success by Capers Jones

• ‘How Perspective-Based Reading Can Improve

(58)

58 _{Farhan Aadil}

58

References - 2

• Software Engineering: A Practitioner’s Approach by Roger S. Pressman

• A Handbook of Software Quality Assurance edited by G. Gordon Schulmeyer and James L. McManus

• Customer-Oriented Software Quality Assurance by Frank P. Ginac