final year project presentation slide 09-05-2006
TRANSCRIPT
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
►Table 4.2Table 4.2
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
Focus groups with users 29
Requirement specification overview 27
Added navigational prototype 27
Navigational prototype 26
Uniformity check 25
Functional prototype 24
Added Functional prototype 24
Educate developers in task domain 23
Added requirement specification overview 16
Completeness model 12
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
Focus groups with users 29
Requirement specification overview 27
Added navigational prototype 27
Navigational prototype 26
Functional prototype 24
Added Functional prototype 24
Educate developers in task domain 23
Added requirement specification overview 16
Completeness model 12
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.
►Table 4.3Table 4.3
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.