Preventing requirements defect to improve requirements engineering in information systems development

Mohd Farid Assamani bin Mohamed Zainon

2004633419

Supervised by: Pn. Wan Noor Amalina binti Wan Hariri Presented at: Final Year Project Presentation Date: 10 May 2006

Introduction
Software

systems requirements engineering is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. (Nuseibeh and Easterbrook, 2001) We will facing several defects during the progress We need to discover what techniques that can be used to prevent those defects.

Problem Statement
Only

9% of projects are on time and under budget, and only about 16% deliver what was promised (Carr, 2000). We need to know and understand those defects. When we classified the defects, we tried to imagine what could have prevented each defects (Vinter, Lauesen & Pries-Heje, 1998). We make the comparison from various techniques that have been identified. Proposing the effective prevention techniques that can be implemented.

Research Questions
What

are the defects that have been identify in requirements engineering based on defect categories? What are the techniques that can be used to prevent the defects? Which are the effective techniques that can be used based on defect categories?

Objectives
To

identify the commonly known requirements defects that occurs in requirements engineering. To identify the commonly used techniques that can be implemented to prevent the defects. To compare the effective techniques from several techniques those have been identified. To propose the effective techniques that can be implemented based on defect categories.

Scope
Focus

on IT company in private sector and IT department from government sector. It will be persistent at Shah Alam, Subang Jaya and Technology Park Malaysia (TPM) at Bukit Jalil. Also focusing on preventing the requirements defects in requirements engineering.

Significance of the research

It

can assist the IT projects team identified the defects that will occur or had occurred earlier. This research can be implemented and added as extra learning in requirements analysis courses.

Limitations of the research

This

research will identify the commonly known requirements defects that laid on four main defects categories. It is also covered on commonly used prevention techniques that have been implemented to prevent the defects. Time constraint is considered a limitation in this research. This research also does not show how the prevention techniques have been applied to prevent the defects.

Requirements
They

are descriptions of how the system should behave, or of a system property or attribute (Sommerville & Sawyer, 1997). A requirement is a narration of the system vision along with a set of functional and non-functional requirements (Booch, 2002).

Requirements engineering
Requirements

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

Requirements elicitation

User needs domain information, existing system information, regulations, standards, etc.

Requirements document System specification

Agreed requirements

(Kotonya & Sommerville, 1998)

Requirements defects
Requirement

defects may creep in at any stage of development (Lauesen & Vinter, 2001). Something that can harm the requirements and does not match the surroundings.

Prevention techniques
The

earlier they are detected, the easier they are to repair (Lauesen & Vinter, 2001). Any techniques that can help to prevent the defects from harming the requirements engineering process.

Methodology
DEFINITION PROCESS
Problem Assessment

Problem Definition & Description

Research Questions & Objectives

GATHERING & ANALYZING PROCESS

Information Gathering Information Collection

Data Analysis

Surveying & Informal Interviews

MODELING PROCESS
Information Modelling

Information Description Information Construction

PRESENTATION PROCESS Information Presentation

Effective Techniques Elaboration

List of requirements defects

Based

on four main defects categories that have been identified

Wrong specification Wrong use of specification Demand change Tacit requirements

Table

4.1

Wrong specification

ck La on si es pr m ire qu re m ire qu re e In et pl m co m ire qu re fli on C g in ct t en s t en s

of

ot m

at iv

n io

Wrong specification

18

6
Im us io ur Sp

25

t en

27
10 30

33

40

Sum

20

Wrong use of specification

Wrong use of specification Misunderstood requirements Inconsistent requirements Broad requirements Ambiguous or vague requirements Unintended consequences Poorly written Mistaken requirements Omission Sum 26 24 23 22 18 18 13 2

Demand change
Demand change
50 40

Sum

30 20 10 0

46 17

Demand change

New domain

Tacit requirements
Tacit requirement Inconsistent tacit 27 Conflicting tacit Sum

21
Wrong tacit 19 Omitted tacit 17 Forgotten tacit 12

Other categories
Others
25

20

Sum

15

21

10

10

0 Misplaced Lack of concerned from team members Others

List of prevention techniques

Several

prevention techniques have been identified and there are laid on four main defect categories Table 4.2

Techniques under wrong specification

Prevention techniques for wrong specification defects Scenarios User data model Focus groups with users Requirement specification overview Navigational prototype Functional prototype Educate developers in task domain Completeness model Sum 35 32 29 27 26 24 23

12

Techniques under wrong use of specification

Prevention techniques for wrong use of specification defects Scenarios Sum 35

Consistency review
User data model Risk analysis Focus groups with users Requirement specification overview

32
32 30 29 27

Added navigational prototype

Navigational prototype Uniformity check Functional prototype Added Functional prototype

27
26 25 24 24

Educate developers in task domain

Added requirement specification overview Completeness model Stress functional prototype Orthogonality check

23
16 12 10 9

Techniques under demand change

Change control

20

Let product expert review screens Check with organization style guide Check with public style guide

13

21

16

Educate developers in product area

24

Scenarios per market segment

10

15

20

25

Sum

Techniques under tacit requirements

Prevention techniques for tacit requirement defects Scenarios User data model Focus groups with users Requirement specification overview Added navigational prototype Navigational prototype Functional prototype Added Functional prototype Educate developers in task domain Added requirement specification overview Completeness model Sum 35 32 29 27 27 26 24 24

23
16 12

Techniques under other categories

30 25

20

29

Sum

15

23

10

0
0 Manage configuration management Motivation Others

Using several prevention techniques

40

30

Sum

20

33

33 24 18

10

0 To compare To ensure As a lesson To learn which the defect is learned and several technique(s) really guidelines prevention is/are prevented for system techniques suitable for development that can be the defect used

Criteria comparing those techniques

Criteria The positive impact from technique to prevent the defects Ease of use to implement the technique Short time needed when using those technique A technique that can prevent several defects Frequently used of the technique Team members are understand about the prevention technique Low budget to be implemented Sum 38 27 26 25 16 13 10

Most occurred requirements defects

Requirement defects categories
Wrong specification

Defect
Incomplete requirements (33*) Conflicting requirements (27*) Spurious requirements (25*)

Wrong use of specification

Misunderstood requirements (26*) Demand change Tacit requirement Others Demand change (46*) Inconsistent tacit (27*) Users did not understand what they want

Proposing prevention techniques

There

have several effective techniques that have been identified based on defects categories. Table 4.3

Conclusion
Even

though, requirements engineering is a very critical process, but there are still have techniques that can help if the defects are occurred. System analyst needs to understand those defects and techniques.