Requirements Errors 1-Software Requirement-Lecture Slides, Slides of Software Project Management

This course includes types of requirements, modeling of non functional, static and dynamic modelling, requirement elicitation and use case modeling. This lecture includes: Errors, Omission, Commission, Clarity, Ambiguity, Speed, Capacity, Implicit

Typology: Slides

2011/2012

Uploaded on 08/07/2012

angana
angana 🇮🇳

4.4

(52)

158 documents

1 / 22

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Requirements Errors
Lecture # 14
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16

Partial preview of the text

Download Requirements Errors 1-Software Requirement-Lecture Slides and more Slides Software Project Management in PDF only on Docsity!

1

Requirements Errors

Lecture # 14

2

Today’s Topics

  • Requirements errors• Addressing requirements errors

4

Requirements Error/Defect

  • A deficiency in the requirements

quality that can hamper softwaredevelopment

5

Requirements Errors - 1

  • Errors and omissions find their way in

different requirements documents

  • If not removed, requirements errors

usually flow downstream into design,code, and user manuals

7

Software Development Process

softwarerequirements

preliminarydesign

detaileddesign

coding

unittesting

integrationtesting

systemtesting

deliveryproductiondeployment maintenanceand enhancement

softwaresystem testplanning integration

testplanning unit testplanning

1

2

3

4

5

6

7

8 9

(^101112)

MIL-STD-2167A

8

Types of Requirements Errors

  • Errors of omission• Errors of commission• Errors of clarity and ambiguity• Errors of speed and capacity

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 staterequirements, while such languages arethemselves ambiguous

  • For example: object

11

Errors of Commission

  • Errors of commission can also find

their way into the requirementsdocuments

13

Negative Impact of Requirements

Errors - 1

  • The resulting software may not satisfy

user’s real needs

  • Multiple interpretations of

requirements may cause disagreementsbetween customers and developers,wasting time and money, and perhapsresulting in lawsuits

14

Negative Impact of Requirements

Errors - 2

  • Negative impact on humans
    • Unsatisfied customers and developers– Lack of interest in automation of

processes

  • Blame game

16

Prevention vs. Removal

  • For requirements errors, prevention is

usually more effective than removal

  • Joint application development (JAD),

quality function deployment (QFD), andprototyping are more effective in defectprevention

  • Requirements inspections and prototyping

play an important role in defect removal

17

Defect Prevention - 1

  • Don’t let defects/errors become part of

the requirements document orrequirements model in the first place

  • How is it possible?• Understanding application domain and

business area is the first step in defectprevention

19

Defect Prevention - 3

  • Willing and active participation of

stakeholders in different activities ofrequirements engineering. That is whyJAD is very useful in defect preventionas far as requirements errors areconcerned

20

Defect Prevention - 4

  • An overall commitment to quality and

emphasis on using documentedprocesses is also a very important

  • An overall commitment to process

improvement