Final Year Project Presentation Slide 09-05-2006

Preventing requirements Preventing requirements defect defect

to improve to improve requirements engineering requirements engineering

in in information systems information systems

developmentdevelopmentMohd Farid Assamani bin Mohamed ZainonMohd Farid Assamani bin Mohamed Zainon

20046334192004633419

Supervised by: Supervised by: Pn. Wan Noor Amalina binti Wan HaririPn. Wan Noor Amalina binti Wan Hariri

Presented at: Final Year Project PresentationPresented at: Final Year Project PresentationDate: 10 May 2006Date: 10 May 2006

IntroductionIntroduction

► Software systems requirements engineering is Software systems requirements engineering is the process of discovering that purpose, by the process of discovering that purpose, by identifying stakeholders and their needs, and identifying stakeholders and their needs, and documenting these in a form that is amenable documenting these in a form that is amenable to analysis, communication, and subsequent to analysis, communication, and subsequent implementation.implementation. ( (Nuseibeh and Easterbrook, Nuseibeh and Easterbrook, 2001) 2001)

► We will facing several defects during the We will facing several defects during the progressprogress

► We need to discover what techniques that can We need to discover what techniques that can be used to prevent those defects.be used to prevent those defects.

Problem StatementProblem Statement

► Only 9% of projects are on time and under Only 9% of projects are on time and under budget, and only about 16% deliver what budget, and only about 16% deliver what was promisedwas promised ( (Carr, 2000)Carr, 2000)..

► We need to know and understand those We need to know and understand those defects.defects.

► When we classified the defects, we tried to When we classified the defects, we tried to imagine what could have prevented each imagine what could have prevented each defects (Vinter, Lauesen & Pries-Heje, 1998).defects (Vinter, Lauesen & Pries-Heje, 1998).

► We make the comparison from various We make the comparison from various techniques that have been identified. techniques that have been identified.

► Proposing the effective prevention Proposing the effective prevention techniques that can be implemented.techniques that can be implemented.

Research QuestionsResearch Questions

►What are the defects that have been What are the defects that have been identify in requirements engineering identify in requirements engineering based on defect categories?based on defect categories?

►What are the techniques that can be What are the techniques that can be used to prevent the defects?used to prevent the defects?

►Which are the effective techniques Which are the effective techniques that can be used based on defect that can be used based on defect categories?categories?

ObjectivesObjectives

► To identify the commonly known requirements To identify the commonly known requirements defects that occurs in requirements defects that occurs in requirements engineering. engineering.

► To identify the commonly used techniques that To identify the commonly used techniques that can be implemented to prevent the defects.can be implemented to prevent the defects.

► To compare the effective techniques from To compare the effective techniques from several techniques those have been identified.several techniques those have been identified.

► To propose the effective techniques that can To propose the effective techniques that can be implemented based on defect categories.be implemented based on defect categories.

ScopeScope

►Focus on IT company in private sector Focus on IT company in private sector and IT department from government and IT department from government sector. It will be persistent at Shah sector. It will be persistent at Shah Alam, Subang Jaya and Technology Alam, Subang Jaya and Technology Park Malaysia (TPM) at Bukit Jalil. Park Malaysia (TPM) at Bukit Jalil.

►Also focusing on preventing the Also focusing on preventing the requirements defects in requirements requirements defects in requirements engineering. engineering.

Significance of the researchSignificance of the research

► It can assist the IT projects team It can assist the IT projects team identified the defects that will occur or identified the defects that will occur or had occurred earlier.had occurred earlier.

►This research can be implemented and This research can be implemented and added as extra learning in added as extra learning in requirements analysis courses. requirements analysis courses.

Limitations of the researchLimitations of the research

► This research will identify the commonly This research will identify the commonly known requirements defects that laid on known requirements defects that laid on four main defects categories.four main defects categories.

► It is also covered on commonly used It is also covered on commonly used prevention techniques that have been prevention techniques that have been implemented to prevent the defects. implemented to prevent the defects.

► Time constraint is considered a limitation in Time constraint is considered a limitation in this research.this research.

► This research also does not show how the This research also does not show how the prevention techniques have been applied to prevention techniques have been applied to prevent the defects. prevent the defects.

RequirementsRequirements

►They are descriptions of how the They are descriptions of how the system should behave, or of a system system should behave, or of a system property or attribute (Sommerville & property or attribute (Sommerville & Sawyer, 1997). Sawyer, 1997).

►A requirement is a narration of the A requirement is a narration of the system vision along with a set of system vision along with a set of functional and non-functional functional and non-functional requirements (Booch, 2002). requirements (Booch, 2002).

Requirements engineeringRequirements engineering

► Requirements engineering and management Requirements engineering and management (REAM) is the process of discovering, (REAM) is the process of discovering, documenting and managing systems documenting and managing systems requirements (Carr, 2000).requirements (Carr, 2000).

(Kotonya & Sommerville, 1998) (Kotonya & Sommerville, 1998)

Requirements elicitation

System specification

Requirements document

Requirements validation

Requirements documentation

Requirements analysis and negotiation

User needs domain

information, existing system

information, regulations,

standards, etc.

Agreed requirements

Requirements defectsRequirements defects

►Requirement defects may creep in at Requirement defects may creep in at any stage of development (Lauesen & any stage of development (Lauesen & Vinter, 2001). Vinter, 2001).

►Something that can harm the Something that can harm the requirements and does not match the requirements and does not match the surroundings.surroundings.

Prevention techniquesPrevention techniques

►The earlier they are detected, the The earlier they are detected, the easier they are to repair (Lauesen & easier they are to repair (Lauesen & Vinter, 2001). Vinter, 2001).

►Any techniques that can help to Any techniques that can help to prevent the defects from harming the prevent the defects from harming the requirements engineering process. requirements engineering process.

Methodology Methodology

MODELING PROCESS

PRESENTATION PROCESS

Information Description

Effective Techniques Elaboration

Information Presentation

Information Construction

Information Modelling

DEFINITION PROCESS

GATHERING & ANALYZING PROCESS

Problem Assessment Problem Definition & Description

Research Questions & Objectives

Information Gathering Information Collection

Data Analysis Surveying & Informal Interviews

List of requirements defectsList of requirements defects

►Based on four main defects categories Based on four main defects categories that have been identifiedthat have been identified Wrong specificationWrong specification Wrong use of specificationWrong use of specification Demand changeDemand change Tacit requirementsTacit requirements

►Table 4.1Table 4.1

Wrong specificationWrong specification

0

10

20

30

40S

um

2533

27

18

6

Wrong specification

Wrong use of specificationWrong use of specification

Wrong use of specification Sum

Misunderstood requirements 26

Inconsistent requirements 24

Broad requirements 23

Ambiguous or vague requirements 22

Unintended consequences 18

Poorly written 18

Mistaken requirements 13

Omission 2

Demand changeDemand change

Demand change New domain

0

10

20

30

40

50S

um 46

17

Demand change

Tacit requirementsTacit requirements

Tacit requirement Sum

Inconsistent tacit27

Conflicting tacit21

Wrong tacit19

Omitted tacit17

Forgotten tacit12

Other categoriesOther categories

Misplaced Lack of concerned from team members

Others

0

5

10

15

20

25

Su

m

10

21

2

Others

List of prevention techniquesList of prevention techniques

►Several prevention techniques have Several prevention techniques have been identified and there are laid on been identified and there are laid on four main defect categoriesfour main defect categories


Techniques under wrong Techniques under wrong specificationspecification

Prevention techniques for wrong specification defects

Sum

Scenarios 35

User data model 32

Focus groups with users 29

Requirement specification overview 27

Navigational prototype 26

Functional prototype 24

Educate developers in task domain 23

Completeness model 12

Techniques under wrong use of Techniques under wrong use of specificationspecification

Prevention techniques for wrong use of specification defects Sum

Scenarios 35

Consistency review 32

User data model 32

Risk analysis 30



Added navigational prototype 27


Uniformity check 25


Added Functional prototype 24


Added requirement specification overview 16


Stress functional prototype 10

Orthogonality check 9

Techniques under demand Techniques under demand changechange

Scenarios per market segment

Educate developers in product area

Check with public style guide

Check with organization style

guide

Let product expert review screens

Change control

0 5 10 15 20 25

Sum

24

8

16

21

13

20

Techniques under tacit Techniques under tacit requirementsrequirements

Prevention techniques for tacit requirement defects

Sum

Scenarios 35

User data model 32



Added navigational prototype 27



Added Functional prototype 24


Added requirement specification overview 16


Techniques under other Techniques under other categoriescategories

Manage configuration management

Motivation Others

0

5

10

15

20

25

30

Su

m

23

29

0

Using several prevention Using several prevention techniquestechniques

To compare which

technique(s) is/are

suitable for the defect

To ensure the defect is

really prevented

As a lesson learned and guidelines for system

development

To learn several

prevention techniques that can be

used

0

10

20

30

40

Su

m 3333

18

24

Criteria comparing those Criteria comparing those techniquestechniques

Criteria Sum

The positive impact from technique to prevent the defects 38

Ease of use to implement the technique 27

Short time needed when using those technique 26

A technique that can prevent several defects 25

Frequently used of the technique 16

Team members are understand about the prevention technique 13

Low budget to be implemented 10

Most occurred requirements Most occurred requirements defectsdefects

Requirement defects categories Defect

Wrong specification Incomplete requirements (33*)

Conflicting requirements (27*)Spurious requirements (25*)

Wrong use of specificationMisunderstood requirements

(26*)

Demand change Demand change (46*)

Tacit requirement Inconsistent tacit (27*)

OthersUsers did not understand

what they want

Proposing prevention Proposing prevention techniques techniques

►There have several effective There have several effective techniques that have been identified techniques that have been identified based on defects categories.based on defects categories.


ConclusionConclusion

►Even though, requirements Even though, requirements engineering is a very critical process, engineering is a very critical process, but there are still have techniques that but there are still have techniques that can help if the defects are occurred.can help if the defects are occurred.

►System analyst needs to understand System analyst needs to understand those defects and techniques. those defects and techniques.

Final Year Project Presentation Slide 09-05-2006

Documents

Transcript of Final Year Project Presentation Slide 09-05-2006