You are on page 1of 30
Preventing requirements defect to improve requirements engineering in information systems development Mohd Farid Assamani bin Mohamed
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
Introduction
► Software systems requirements engineering is the process of discovering that purpose, by identifying stakeholders and
► 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
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
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
Objectives
► To identify the commonly known requirements defects that occurs in requirements engineering. ► To identify
► 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
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
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
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
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
► Requirements engineering and management (REAM) is the process of discovering, documenting and managing systems requirements
► Requirements engineering and management
(REAM) is the process of discovering, documenting
and managing systems requirements (Carr, 2000).
Requirements
elicitation
Requirements
analysis and
negotiation
Requirements
Requirements
documentation
validation
User needs
domain
information,
existing system
information,
regulations,
standards, etc.
Requirements
document
System
Agreed
specification
requirements
(Kotonya & Sommerville, 1998)
Requirements defects ►Requirement defects may creep in at any stage of development (Lauesen & Vinter, 2001).
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,
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
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
Methodology DEFINITION PROCESS Problem Assessment Problem Definition & Description Research Questions & Objectives GATHERING & ANALYZING
List of requirements defects ►Based on four main defects categories that have been identified  Wrong
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
Wrong specification
Lack of motivati Impression requirements Spurious Wrong specification requirements Incomplete 40 requirements 30 Conflicting 33 27
Lack of motivati
Impression
requirements
Spurious
Wrong specification
requirements
Incomplete
40
requirements
30
Conflicting
33
27
20
25
18
10
6
0
Sum
Wrong use of specification
Wrong use of specification
Wrong use of specification Sum Misunderstood requirements Inconsistent requirements Broad requirements Ambiguous or vague requirements Unintended
Wrong use of specification
Sum
Misunderstood requirements
Inconsistent requirements
Broad requirements
Ambiguous or vague requirements
Unintended consequences
26
24
23
22
18
Poorly written
Mistaken requirements
Omission
18
13
2
Demand change
Demand change
Demand change 50 40 30 46 20 17 10 0 Demand change New domain Sum
Demand change
50
40
30
46
20
17
10
0
Demand change
New domain
Sum
Tacit requirements
Tacit requirements
Tacit requirement Sum Inconsistent tacit 27 Conflicting tacit 21 Wrong tacit 19 Omitted tacit 17 Forgotten
Tacit requirement
Sum
Inconsistent tacit
27
Conflicting tacit
21
Wrong tacit
19
Omitted tacit
17
Forgotten tacit
12
Other categories Others 25 20 15 21 10 10 5 2 0 Misplaced Lack of Others
Other categories
Others
25
20
15
21
10
10
5
2
0
Misplaced
Lack of
Others
concerned from
team members
Sum
List of prevention techniques ►Several prevention techniques have been identified and there are laid on four
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 Sum Scenarios 35 User data model
Techniques under wrong
specification
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 specification Sum Prevention techniques for wrong use of specification defects Scenarios
Techniques under wrong use of
specification
Sum
Prevention techniques for wrong use of specification defects
Scenarios
35
Consistency review
32
User data model
Risk analysis
Focus groups with users
Requirement specification overview
32
30
29
27
Added navigational prototype
27
Navigational prototype
Uniformity check
Functional prototype
Added Functional prototype
26
25
24
24
Educate developers in task domain
23
Added requirement specification overview
Completeness model
Stress functional prototype
Orthogonality check
16
12
10
9
Techniques under demand change Change control 20 Let product expert 13 review screens Check with organization
Techniques under demand change
Change control
20
Let product expert
13
review screens
Check with
organization style
21
guide
Check with public
16
style guide
Educate developers
24
in product area
Scenarios per market
8
segment
0
5
10
15
20
25
Sum
Techniques under tacit requirements
Techniques under tacit requirements
Prevention techniques for tacit requirement defects Sum Scenarios User data model Focus groups with users Requirement
Prevention techniques for tacit requirement
defects
Sum
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
35
32
29
27
27
26
24
24
23
16
12
Techniques under other categories 30 25 29 20 23 15 10 5 0 0 Manage Motivation
Techniques under other categories
30
25
29
20
23
15
10
5
0
0
Manage
Motivation
Others
configuration
management
Sum
Using several prevention techniques
Using several prevention techniques
40 30 33 33 20 24 18 10 0 To compare To ensure As a lesson
40
30
33
33
20
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
Sum
Criteria comparing those techniques
Criteria comparing those techniques
Criteria Sum The positive impact from technique to prevent the defects 38 Ease of use to
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 defects
Most occurred requirements defects
Requirement defects categories Defect Wrong specification Incomplete requirements (33*) Conflicting requirements (27*) Spurious requirements (25*) Wrong
Requirement defects categories
Defect
Wrong specification
Incomplete requirements (33*)
Conflicting requirements (27*)
Spurious requirements (25*)
Wrong use of specification
Misunderstood requirements (26*)
Demand change
Demand change (46*)
Tacit requirement
Inconsistent tacit (27*)
Others
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
►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
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.