AN INVESTIGATION OF SOFTWARE REQUIREMENTS MANAGEMENTPRACTICES
IN
NIGERIAN SOFTWARE DEVELOPMENT INDUSTRIES
BY
ABE, JESULAYOMI OLAOLUWA
08CG07721
A PROJECT SUBMITTED TO THE DEPARTMENT OF COMPUTER AND INFORMATIONSCIENCES, COLLEGE OF SCIENCE AND TECHNOLOGY, COVENANT UNIVERSITY,
OTA, OGUN STATE
IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR AWARD OF A BACHELORSCIENCE (B.Sc.) HONOURS DEGREE IN COMPUTER SCIENCE
CERTIFICATION
It is hereby certified that this project, written by ABE,
Jesulayomi Olaoluwa (08CG07721) was supervised by me and
submitted to the Department of Computer and Information Sciences,
College Of Science and Technology, Covenant University, Ota.
Signed,
_________________
__________________
DR OLAWANDE DARAMOLA Date
(Project Supervisor)
__________________
__________________
DR NICHOLAS A. OMOREGBE Date
(Head of Department)
i
DEDICATION
This project is dedicated to God Almighty who has made it
possible for me to bring this project to completion and for
seeing me through a most rewarding academic experience in
Covenant University. I would also like to acknowledge Mr and Mrs
Kayode Abe, my ever loving parents who have been a continuous
source of moral and financial support; your prayers have helped
me in this journey. God bless you.
ii
ACKNOWLEDGEMENT
My thanks and appreciation to Dr Olawande Daramola for
persevering with me as my supervisor throughout the time it took
me to complete this survey and write the project. The inspiration
for continuity came from the unexplainable patience he exuded
throughout the entire phase of this project.
I am grateful to many persons who shared their memories and
experiences, especially from the department of Computer and
Information Sciences, Mr. Emebor Onyeka, Mrs. Oni Aderonke, Mr.
Wole Adewumi have generously given their time and expertise to
better the outcome of this project. I thank them for their
contribution and their good-natured support.
I must acknowledge as well the many friends and course mates,
Dipeolu Funmilola, Anene Onyeka, Gabriel Justina, Nwawe Ifeoma,
Abe Jesutomilayo, Abe Jesulademi who assisted, advised, and
morally supported the survey and writing efforts throughout the
entire phase of this project. Especially, I need to express my
gratitude and deep appreciation to Olatunde Tokun whose
friendship, knowledge, and wisdom has supported and enlightened
me to do better. They have consistently helped me keep
perspective on what is important in life.
I would specially like to acknowledge all respondents from
Terragon Nigeria Limited, University of Lagos, C2G Consulting andiii
lastly Interswitch Nigeria for their immense contribution to the
completion of this survey. God bless you all.
ABSTRACT
The motivation for this particular study is that this kind of
investigation has not been conducted in this part of the World.
The study is intended to perform an examination of the state of
the practices of selected software engineering firms in Nigeria
and to take a look at the extent to which requirements management
practices have been adopted by the software industries in
Nigeria. The study will be conducted on randomly selected
software industries and structured questionnaires will be used as
a tool for data collection. The study would illuminate on the
state of the requirements management practices in Nigerian
software industries based on the assessment of the responses
gathered. In conclusion, the study has been able to prove that
iv
there is a measure of practice of the requirements engineering
activities among the Nigerian software industries which
ascertains the general awareness of the need to build towards a
country that aims at enhancing locally manufactured software
quality and performance through the adoption of quality
requirements engineering practices as well as proper application
of the software management requirement practices in this part of
the World.
Keywords: Requirements Engineering, Requirements management
practices.
Context: Software engineering, Survey research.
v
TABLE OF CONTENTSCERTIFICATION........................................................iDEDICATION..........................................................iiACKNOWLEDGEMENT....................................................iiiABSTRACT............................................................ivTABLE OF CONTENTS....................................................vLIST OF FIGURES....................................................viiLIST OF TABLES....................................................viiiCHAPTER ONE..........................................................1INTRODUCTION.........................................................11.1 Background information.........................................11.2 Statement of problem...........................................21.3 Aims...........................................................21.4 Objectives.....................................................31.5 Methodology....................................................31.6 Significance of study..........................................31.7 Limitations....................................................41.8 Arrangement of thesis and survey outline.......................4
CHAPTER TWO..........................................................5REVIEW OF RELEVANT LITERATURE........................................52.1 An Introduction................................................52.1.1 History of Requirements Engineering........................5
2.2 An overview of requirements engineering........................62.2.1 Context of Requirements Engineering.........................72.2.2 Role Of RE in Software Systems.............................82.2.3 Role of Stakeholders In RE..................................9
2.3 Core activities of Requirement Engineering.....................92.3.2 Requirements Analysis.....................................112.3.3 Requirements Prioritization...............................122.3.4 Requirements Validation...................................132.3.5 Requirements Management...................................14
vi
2.4 Challenges of Requirements Engineering........................142.4.0 Technological Crisis.......................................152.4.1 Economic Crisis............................................152.4.2 External Events............................................162.4.3 Requirements Engineering Process...........................162.4.4 Organizational Issues......................................162.4.5 Stakeholders Conflict......................................172.4.6 Time......................................................17
2.5 Empirical studies on requirements engineering practices.......172.5.1 Findings of Related Studies...............................20
2.6 Empirical studies on software Engineering.....................22CHAPTER 3...........................................................243.1 Research Methodology..........................................243.2 Survey questions..............................................243.3 Questionnaire Construction....................................253.4 Data Collection...............................................263.5 Data Analysis.................................................263.6 Survey Hypotheses.............................................26
CHAPTER 4...........................................................27RESULTS AND DISCUSSIONS.............................................274.1 Belief and level of Engagement in Requirement engineering practices..........................................................274.1.1 Requirements Elicitation..................................274.1.2 Requirements Analysis.....................................284.1.3 Requirements Management...................................294.1.4 Requirements Validation...................................304.1.5 Requirements Prioritization...............................314.1.6 Requirements Evolution....................................324.1.7 Requirements Description..................................334.1.8 Functional and Non-Functional Requirements................34
4.2 Practice of Requirements engineering activities...............394.2.1 Requirements Elicitation..................................39
vii
4.2.2 Requirements Analysis.....................................404.2.3 Requirements Management...................................414.2.4 Requirements Validation...................................424.2.5 Requirements Prioritization...............................434.2.6 Requirements Evolution....................................444.2.7 Requirements Description..................................45
4.3 Hypothesis Testing............................................46CHAPTER FIVE........................................................49DISCUSSION AND CONCLUSION...........................................495.1 Introduction..................................................495.2 Discussion....................................................495.3 Conclusion....................................................49
REFERENCES..........................................................50APPENDIX............................................................52
LIST OF FIGURESFigure 1: Kano’s Model of Customer Requirements.....................16Figure 2: Research Methodology......................................28Figure 5: Requirements Elicitation..................................32Figure 6: Requirements Analysis.....................................33Figure 7: Requirements Management...................................34Figure 8: Requirements Validation...................................35Figure 9: Requirements Prioritization...............................36Figure 10: Requirements Evolution...................................37Figure 11: Requirements Description.................................38Figure 12: Functional and Non-functional Requirements...............39Figure 13: Requirements Elicitation.................................44Figure 14: Requirements analysis....................................45Figure 15: Requirements Management..................................46Figure 16: Requirements Validation..................................47Figure 17: Requirements Prioritization..............................48Figure 18: Requirements Evolution...................................49Figure 19: Requirements Description.................................50
viii
LIST OF TABLESTable 1: Review of Existing Literature..............................23Table 2: Identifying Requirements Engineering Best Practices For VSSES....................................................................25Table 3: Requirements Elicitation...................................31Table 4: Requirements Analysis......................................32Table 5: Requirements Management....................................33Table 6: Requirements Validation....................................34Table 7: Requirements Prioritization................................35Table 8: Requirements Evolution.....................................36Table 9: Requirements Description...................................37Table 10: Functional and Non-functional Requirements................38Table 11: Descriptive Statistics of level of belief in Requirements Engineering Activities..............................................40Table 12: Requirements Elicitation..................................43Table 13: Requirement analysis......................................44Table 14: Requirements Management...................................45Table 15: Requirements Validation...................................46Table 16: Requirements Prioritization...............................47Table 17: Requirements Evolution....................................48Table 18: Requirements Description..................................49Table 19: One-Sample Statistics.....................................51Table 20: One-Sample Test...........................................51Table 21: One-Sample Statistics.....................................52Table 22: One-Sample Test Statistics................................52
ix
CHAPTER ONE
INTRODUCTION
1.1 Background information
Requirements engineering is being widely recognized as the
first phase of software engineering process, is considered
the key task of software development (Wahono, 2003).
Requirements engineering (RE) is concerned with the
identi cation of the goals to be achieved by the envisionedfi
system, the operationalization of such goals into services
and constraints, and the assignment of responsibilities for
the resulting requirements to agents such as humans,
devices, and software (Lamsweerde).
The requirements engineering (RE) process is described as a
succession of actions, during which the requirements for a new
software system is elicited, analyzed, validated and documented
into a formal, complete and agreed requirements speci cation.fi
(Matuleviˇcius, 2005). There are various practices and ,
activities but the RE process is still perceived as
underdeveloped. Introduction of new RE methods leads to the RE
process improvements. However, there is a need to bridge the gap
between academic and industrial practice exists in the sense that
these RE methods and practices may be known by all but the
applicability of the knowledge in building software in these
software industries is questionable. An investigative study is
1
the first step to find the extent to which the industry actually
carry out software development using RE practices, and to gather
the knowledge about the improvement possibilities for the RE
process where the need arises. This paper surveys the state of
the RE practice in Nigerian software development industries.
Requirements engineering from a goal based perspective has
been defined by requirement engineers to increase the
interest rate of end users who, without their participation
requirements engineering is impossible because it has been
observed that ninety nine percent of these users are unaware
of the intricacies that surround requirements engineering
(Sen & Hamachandran, 2010).
The development of software systems cannot be complete
without adequate and precise run-through of the
requirements, which are necessary for a successful software
deliverable. The development of requirements is seen as an
engineering process because of the development,
manufacturing and expertise that is taken into cognisance
when working with user requirements.
Nigeria is still being tagged as a third world or a
developing country despite the advent of information
technology which only goes to show that there is still a
level we are yet to attain as it regards being recognized
globally as a country willing to embrace the technological
phase of development. The increasing adoption of ICT enabled
2
tools and technologies in Nigeria further enhance the value
of software. Software is required for the effective use of
ICT – in PCs, handhelds, mobile phones, the Internet, GSM,
wireless telephony, network devices, telecom equipment, etc.
Nigeria’s software industry needs to grow and be involved to
make the required impact in Nigeria.
1.2 Statement of problem
The software industry has struggled to build quality
software unsuccessfully and this is evident in the
deployment of major software projects because software
projects turn out disappointedly because of unconscious
response to requirements management approaches. There
is need to bridge the gap between increasing
distribution of software projects in the industry and
the challenge of optimizing the allocation and
integration of inputs necessary to meet defined project
objectives.
Therefore this study reports a survey on the RE
practices in the Nigerian software industries.
3
1.3 Aims
The sole aim of this study is to identify the state of
practices of software requirements management in
Nigerian software development industries.
1.4 Objectives
The approach intended to achieve the above aims
include;
1. Review the relevant literature for best practices.
2. Interview software engineers and developers to
determine how they carry out their processes.
3. Identify how RE processes are adopted in Nigerian
software industries to proffer corrective measures
and point out lapses.
4. Perform system analysis of the results of these
interviews to identify best practices and unfulfilled
needs.
1.5 Methodology
1. Review of Related Literature
4
2. Generation of survey questions
3. Construction of questionnaire
4. Data Collection
5. Data Analysis
6. Evaluation of Results
1.6 Significance of study
A study of this nature can only be plausible if we are
able to bring to light the issues revolving around the
instability of the Nigerian software industry and also to
resolve the possible challenges that are associated with
lack of concrete requirement management practices which
lead to shallow software deliverable(s).
1.7 Limitations
The scope of this study is limited to small and medium
scale industries in Nigeria.
1.8 Arrangement of thesis and survey outline
5
The rest of this paper is organized as follows: Chapter
2 contains the review of related literature. In chapter
3, the design methodology approach used for this study
is fully stated. Chapter 4 produces the results
obtained from the study while Chapter 5 presents the
conclusion from the findings.
6
CHAPTER TWO
REVIEW OF RELEVANT LITERATURE
2.1 An Introduction
In this chapter, a review of previous related works and some
background of the context of requirements engineering and
management practices will be conducted as well as examining
software engineering to which requirements engineering
serves as the back bone.
Requirements Management is the process of documenting,
analyzing, tracing, prioritizing, and agreeing on
requirements and then controlling change and communicating
to relevant stakeholders (Requirements Management).
Requirements engineering (RE) on the other hand 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 (Requirements Engineering)
2.1.1 History of Requirements Engineering
7
The need for the creation, understanding and agreement of
requirements was not examined in the nineties, especially in
the 1970 when there was no word to categorically imply or
indicate “requirements engineering” and as such all that was
required of the engineers then was to produce specifications
in whatever manner of representation was deemed imperative
which included text, tables or drawings. Still in the 1970’s
customer were being documented in a customer requirements
specification, further down to 1980, the word customer was
perceived as limiting due to the unfortunate fact of it
being understood solely to mean any person who makes payment
for the system. Hence, the word “user” was developed to
counter “customer”.
Transitioning into the 1990’s also saw the word user being
perceived as limiting due to the false impression that only
the end-users were being considered, disregarding the
requirements for things such as test, maintenance and sales.
Therefore the 1990 birthed the word stakeholder.
Stakeholders include customers or clients (who pay for the
system), developers (who design, construct and maintain the
system), and users (who interact with the system to get
their work done) (Nuseibeh & Easterbook).
8
During the same time, the necessary processes to guarantee
the quality of requirements specification were now known to
be more than just plain “engineering” and were now being
referred to as requirements management. Around the time
millennium hit, requirements management was being denoted as
requirements engineering. Soon enough the two terms though
alike began to get different meanings and as such all the
meanings were correct but it only pointed to the fact that a
simple misunderstanding of the concepts could lead to
communication problems just as it is being faced in the
modern time.
2.2 An overview of requirements engineering
The importance of requirements for any software project
cannot be over-emphasized, because they define what will be
built or developed. Many problems found during design,
testing, or operations of a system are the result of
incorrect, incomplete, or missing requirements. Therefore,
verification of requirements is an important function of
the requirements engineer (Nuseibeh & Easterbook). The
Standish Group study noted that three most commonly
mentioned factors that caused projects to be challenged
(Leffingwell & Widrig, 2000) include;
9
1. Lack of user input: 13 percent of all projects.
2. Incomplete requirements and specifications:12 percent
of projects
3. Changing requirements and specifications: 12 percent
of all projects.
“Requirements are a specification of what should be
implemented. They are descriptions of how the system should
behave, or of a system property or attribute. They may be a
constraint on the development process of the system”.(Sommerville & Sawyer, Requirements Engineering: A GoodPractice Guide, 1997)
This definition points out that many different kinds of
information fall in the domain of software requirements. A
project needs to address three levels of requirements, which
come from different sources at different project stages:
Business requirements describe why the product is
being built and identify the benefits both
customers and the business will reap.
User requirements, captured in the form of use
cases, describe the tasks or business processes a
user will be able to perform with the product.
Functional requirements describe the specific
system behaviours that must be implemented. The
functional requirements are the traditional
10
"shall" statements found in a software
requirements specification (SRS).
2.2.1 Context of Requirements Engineering
RE is often regarded as a front-end activity in the software
systems development process. There is truism in the fact
that RE is the backbone of the software development process,
although it is usually also the case that requirements
evolve during development after a system has been in
operation for some time. Therefore, RE plays an important
role in the management of change in software development
(Antoniou, 1998). Nevertheless, the bulk of the effort of RE
does occur early in the lifetime of a project, motivated by
the evidence that requirements errors, such as misunderstood
or omitted requirements, are more expensive to fix later in
project lifecycles. (Rajilch & Bennett, 2000).
Before a project can be started, some preparation is needed.
Finkelstein (1996) categorizes such preparation as context
and groundwork. It has been noted in past times that RE
methods took on RE as though it was for a specific user, who
could sign off a requirements specification. However, RE is
actually performed in a variety of contexts, including
market-driven product development and development for a
specific customer with the eventual intention of developing
a broader market. The type of product will also affect the
11
choice of method: RE for information systems is very
different from RE for embedded control systems, which is
different again from RE for generic services such as
networking and operating systems.
RE plays an important role in assessing a project’s
feasibility and associated risks. It is often possible to
estimate project costs, schedules and technical feasibility
from precise specifications of requirements.
2.2.2 Role Of RE in Software Systems
A clear definition of RE is given below:
“Requirements engineering is the branch of software
engineering concerned with the real-world goals for,
functions of, and constraints on software systems. It is
also concerned with the relationship of these factors to
precise specifications of software behavior, and to their
evolution over time and across software families.” (Zave,
1997)
This definition first and foremost illuminates on the
importance of “real-world goals” that motivate the
development of a software system. These represent the ‘why’
as well as the ‘what’ of a system. Second, it refers to
“precise specifications”. These provide the basis for
analyzing requirements, validating that they are indeed what
stakeholders want, defining what designers have to build,
12
and verifying that they have done so correctly upon
delivery.
Finally, the definition refers to specifications’
“evolution over time and across software families”, placing
emphasis on the reality of a changing world and the need to
reuse partial specifications, as engineers often do in other
branches of engineering. (Nuseibeh & Easterbook).
Normal definitions of engineering culled from refer to the
creation of cost-effective solutions to practical problems
by applying scientific knowledge (Shaw, 1990).
2.2.3 Role of Stakeholders In RE
Identification of stakeholders which may be individuals or
organisations that stand to gain or lose from the success or
failure of a system is very critical.
For interactive systems, users play an important role in the
elicitation process, as usability can only be defined in
terms of the target user population. Users themselves are
not homogeneous, and part of the elicitation process is to
identify the needs of different user classes, such as novice
users, expert users, occasional users, disabled users etc.
(Nuseibeh & Easterbook)
13
2.3 Core activities of Requirement Engineering
For the purpose of this survey study, a number of generic
activities common to all RE processes, highlighted by
Sommerville (2004) have been noted and they include;
Requirements elicitation, Requirements analysis,
Requirements validation and Requirements management but for
the purpose of this study, requirements prioritization will
be included.
2.3.1 Requirements Elicitation
Probably the most difficult task in requirements engineering
is information gathering. (Finkelstein)
Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and other
stakeholders. The practice is also sometimes referred to
as requirements gathering. (Requirement Elicitation:Wikipedia, 2013)
Requirements Elicitation is most often considered the first
step in the requirements gathering as it relates to the
14
requirements engineering process. The term elicitation has
preference over “capture” or “gather” to avoid the
indication that requirements are to be collected by just
asking the right questions.
Researchers are of the opinion that elicitation is often
perceived as a simple matter of interviewing users or merely
analysis documents which is not particularly an easy task
due to the tendency of requirements being inexplicitly
stated by stakeholders to requirements engineers.
Complications of Requirements elicitation has been
identified by Leffingwell (2000) along three endemic
syndromes as stated below:
1. The “yes but” syndrome stems from human nature and the
users’ inability to experience the software as they
might a physical device.
2. Searching for requirements is like searching for
“undiscovered ruin”; the more you find, the more you
know remain.
3. The “user and the developer” syndrome reflect the
profound differences between the two, making
communication difficult.
15
The third point stated above fortifies the notion that
requirements engineering is primarily a communication,
not technical, activity. Communication problems can
begin early on if project participants have different
ideas of exactly what "requirements" is (Sommerville &Sawyer, Requirements Engineering: A Good PracticeGuide, 1997).
Although requirements elicitation have developed over
years and many argues about the complexity and
difficulty of eliciting requirements, the situations
and context to which elicitation is used is variable
and never the same (C.Coulin, 2004)]. Each project has
its own characteristics and properties. Stakeholders
vary and the degree of communication with analysts,
their experience and maturity plays a significant role
in successful elicitation of requirements. Moreover,
technological advances and solutions are evolving
making the elicitation process vary by technology used
and the degree to which the analyst aware of these
advances.
2.3.2 Requirements Analysis
Requirements analysis in systems engineering and software
engineering, encompasses those tasks that go into
determining the needs or conditions to meet for a new or
16
altered product, taking account of the possibly
conflicting requirements of the various
stakeholders, analyzing, documenting, validating and
managing software or system requirements. (RequirementsAnalysis, 2013)
Requirements analysis elaborates on requirements collected
at earlier stages of the project and uses models to reflect
these requirements, depict user scenarios, problems and
their relationships, functional and flow activities and
system behaviour (Al-Fataftah & Issa, 2012). A primary
benefit of modelling requirements is the opportunity this
provides for analysing them.
Problems of analysis as highlighted by Sommerville (2004)
include;
1. Stakeholders don’t know what they really want.
2. Stakeholders express requirements in their own terms.
3. Different stakeholders may have conflicting
requirements.
4. Organisational and political factors may influence the
system requirements.
17
5. The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.
2.3.3 Requirements Prioritization
Requirement prioritization is used in requirement management
for determining which requirements of a software product
should be included in a certain release. Requirements are
also prioritized to minimize risk during development so that
the most important or high risk requirements are implemented
first.
It is not always easy for developers to decide which
requirements are important to customers. This activity
assists project managers with resolving conflicts (where
customers and developers collaborate on requirements
prioritization), plan for staged deliveries, and make
necessary trade-off decisions. (Aurum & Wohlin)
The KANO model will be used to analyze the priority of
software requirements for the purpose of this study.
The Kano analysis model was developed to identify and
contrast essential customer requirements from incremental
requirements, and initiate critical thinking. The
development of the Kano analysis model in the late 1980s was
to identify and contrast essential customer requirements
18
from incremental requirements. Kano analysis allows us to
prioritize requirements as a function of customer
satisfaction.
Four categories are identified by Kano into which each
feature or requirement can be classified;
1. Surprise and delight: Capabilities that differentiate a
product from its competition
2. More is better: Dimensions along a continuum with a
clear direction of increasing utility
3. Must be: Functional barriers to entry—without these
capabilities, customers will not use the product.
4. Better not be: Represents things that dissatisfy
customers.
19
Figure 1: Kano’s Model of Customer Requirements
2.3.4 Requirements Validation
Requirements validation is concerned with demonstrating
that the requirements define the system that the
customer really wants. Requirements error costs are
high so validation is very important. Sommerville
(2004)
Requirements Validation techniques include;
1. Requirements reviews
Systematic manual analysis of the requirements.
20
2. Prototyping
Using an executable model of the system to check
requirements.
3. Test-case generation
Developing tests for requirements to check
testability.
2.3.5 Requirements Management
Requirements management is a continuous process that
involves documenting, tracing, prioritizing and agreeing
requirements. The identification of requirements, managing
of change, and identifying traceability between them can be
utilized by using management tools and automated techniques.
These tools have been the focus of the market as the need
for managing large volume of requirements from various
phases and different location are very important.
However, requirement management and traceability of
requirements becomes really complex with manually written
functional requirements. (Asghar & Mahrukh)
2.4 Challenges of Requirements Engineering
21
Requirement Engineering is a core process for software
development life cycle. Bugs in requirements are not
identified during development rather they remain concealed
until system becomes operational and customer requirements
are not met. Poor requirements lead to not only
Modifications in requirement specifications but require re-
designing, re-implementing and retesting for entire
software. Therefore, requirement engineers have to struggle
and conquer uncountable numbers of challenges for
development of effective and efficient software. There have
been many investigations conducted to explore different
challenges in various domains of requirement engineering.
However, these investigations proposed models and gave
recommendations to defeat challenges and as such
requirements requirement engineering challenges have been
categorized into seven components. These components include:
1. Technological crisis
2. Economic crisis
3. External events
4. Requirement engineering process
5. Organizational issues
6. Stakeholder’s conflicts
7. Time
These categorized challenges are further classified into
problems that occur during requirement engineering phase.
22
Requirements engineering problems and challenges presented
in the model are explained as follows;
2.4.0 Technological Crisis
Outdated requirement engineering tools may not provide with
accurate functionality for instances, requirements tools for
development of prototypes or stimulations. Discarding these
requirements engineering tool completely and installing new
tool may not be able to convert or emulate the file format.
Besides, integrating collaborative features of two
requirement engineering tools to obtain functionalities
requires deep structural and functional analysis of both
available tools, which becomes cumbersome.
2.4.1 Economic Crisis
IT market is all about new emerging technologies and
challenges which make room for an even more competitive
environment Unsolved challenges may increase overall cost of
software. For instance unclear software requirements may
increase maintenance cost. Besides, there are various other
challenges that can arise ranging from the organization
developing a system or customers may face financial
downfalls during development of software. Increase in
accounts payable, out of control spending and poorly planned
budgeting strategies can initiate bankruptcy of customer or
organization.
23
2.4.2 External Events
Targeted effectiveness in software can be achieved if
challenging external threats and risk are addressed
beforehand. Accidental deletion of valuable data, file
corruption, virus-infection or hardware failure may create
catastrophe situation for requirement engineers. Besides,
external events such as fire, bomb blast or unusual climatic
condition may affect requirement engineering process.
Consequently, such unpleasant incidents fine an astronomical
amount of cost within requirement engineering.
2.4.3 Requirements Engineering Process
The goal of requirement engineering process is to
investigate what tasks need to be performed and what are the
boundaries and constraints in software. Acquiring and
comprehending requirements for complex domains or critical
systems have always been great challenges for requirement
engineers. Additionally, stakeholders do not articulate
their requirements precisely during requirement discovery
process. As a result, requirement specifications are vague,
perplexing and ambiguous. Hence, decomposition, modeling of
requirements and identification of business processes
becomes complicated.
2.4.4 Organizational Issues
Software applications are developed from collaboration of
business and IT strategies. However, unfortunately there is
24
extensive diversity of perceptions within organizational
departments.
Hence, aligning and synchronizing strategies recommended by
different departments become critical task for requirement
engineers.
Additionally, an effective business process represents
efficient functioning of an organization. In spite,
organizations are rapidly focusing on re-designing of
business processes to make substantial changes and
improvements in their level of performance. Eventually,
changes within business process also transform software
requirements. Thus, it acquires substantial efforts to
manage these volatile requirements, which set great
challenges in requirement engineering.
2.4.5 Stakeholders Conflict
A successful project has a great influence on knowledgeable
and experienced stakeholders.
Otherwise, software may face significant risks. Inadequate
technical skills with requirement engineers and lack of
domain knowledge can have a major impact on software.
Requirement engineers are unable to adequately address
problems and end user’s needs. Besides, some pioneer
requirement engineers may be ignorant to emergent
requirement engineering tools.
25
Therefore, ineffective performance by requirement engineers
may results in outdated and error prone requirements.
However, difference in perception or unclear roles and
responsibilities leads to confrontations among requirement
engineers. These intra-group conflicts may eliminate
effective coordination between stakeholders which may have
negative impact on performance. Besides, requirement
engineer might not be available at critical time or resign
from their job. Recruiting and training new employee perhaps
not be feasible for successfully completing the development
of software within timeframe and budget.
2.4.6 Time
Scheduling is a process for planning and managing time.
Scheduling time is one of the predominantly difficult job
and entirely critical to software success. However, usually
the time required in completion of tasks during requirement
engineering phase is underestimated. As a result, delivery
of milestones gets delayed particularly when tasks are on
critical path. Great challenges endure for requirement
engineers to manage and accomplish seemingly unlimited
tasks. Hence, requirement engineers start to take short cuts
or sometimes ignore to emphasize and focus on important
aspects. Consequently, requirements are poorly established
or gets behind schedule. Besides, these futile requirements
also lead to downstream failure of entire software.
26
2.5 Empirical studies on requirements engineering practices
This section of the paper looks at a number of report
studies that span the requirements engineering practices
field in diverse countries.
RE practices are not new to the engineering world and as
such a handful of researchers have carried out a number of
investigative studies to gather why there are lapses in the
software development industries in general and it all
boiled down to a poor case of requirements documentation on
the part of the engineers as could have been caused by the
customer also.
A review of existing literature on requirements engineering
and software process improvement (SPI) reveal several
models to incrementally improve requirements engineering
process and the purported benefits reaped by such
improvements. Three predominant improvement models are the
CMM, ISO/IEC 15504 and the process capability model
developed by Sommerville and Sawyer (1997). These models
all describe (or imply) increases in productivity, enhanced
quality, improved risk management and other benefits to the
27
software development process. (Damian, Chisan,Lakshminarayanan, & Yogendra, 2005)
Hence a brief tabulated summary of various papers and
studies related to this investigation is given below under
the following headings; domain/ country name, type/ size of
company, number of companies sampled, participants, data
gathering method and finally findings gathered.
Table 1: Review of Existing Literature.
TITLE OFPAPER
Survey ofrequirementsengineering practiceinLithuaniansoftwaredevelopmentcompanies
Anempiricalstudy ofsoftwareprojectmanagementamong someselectedsoftwarehouses inNigeria
How dosoftwarearchitectsconsidernon-functionalrequirements:Anexploratorystudy
Softwarerequirementsengineering:Practicesandtechniques
Softwareengineeringrequirementsproblemsaninvestigation studyinJordaniancontext
Authors(s) Raimundasmatuleviˇcius
Davidameller,claudiaayala, jordicabot andxavierfranch
Ronaldkirkkandt
Mohammadtarawneh
Domain Lithuania Nigeria Spain Jet Jordan
28
name/country
propulsionlaboratory (jpl)
Type ofcompany
Small/large/average/non-softwaredevcompanies
Privatemultinationalcompanies
Softwareintensiveorganization(s)
Notmentioned
Focused onkeysectors;banking,softwareengineering,insurancecompanies
No ofsamplecompanies
28 8 12 1 96
Participants
Onlynumber ofparticipatingcompaniesmentioned
Onlynumber ofparticipatingcompaniesmentioned
13 10 Notmentioned
Datagatheringmethod/technique
Interviewandquestionnaire
Interview Interview Interview Interviewandquestionnaire
A summary of the findings from the above papers is reported
along the dimensions below;
29
2.5.1 Findings of Related Studies
1. The analysis of non-functional requirements would
stimulate the creativity of the software engineers. The
common non-functional requirements could be reused in
Several projects and reduce the time and resource
needs.
2. Reuse of requirements specification would be effective,
if requirements repositories are introduced. Repository
tends to support storage of requirements metadata and
traceability when relevant requirements are modi ed.fi
3. Adaptation of RE tools for organizational needs could
contribute towards RE process improvement. The market
suggests RE tools, which allow integration with other
modelling environments and support RE activities such
as scope management, version and coniguration control,
quality assurance and quality control. The requirements
speci cations of different types, contents, and levelfi
of details could be automatically generated from the
requirements repositories using appropriate selection
criteria and templates.
Below is a summary of another paper authored by Alcides
Quispe and Sergio F. Ochoa who reviewed a number of papers
also;
30
Table 2: Identifying Requirements Engineering Best Practices For VSSES
TITLE OF
PAPER
DOMAIN
NAME/
COUNTRY
TYPE OF
COMPANY
NO OF
SAMPLE
COMPANIES/
PARTICIPAN-
TS
FINDINGS/ CONCLUSION
Nikula
et al.
[Niku00]
FINLAND SMALL
AND
MEDIUM-
SIZED
12 Study reports that even
standard topics in RE
research were new and
unfamiliar to many of
the twelve companies
they observed.
ARANDA
et al.
CANADA SMALL
SIZED
7 (1) RE practices in
successful VSSE are
diverse and work well
for the organizations
where they were
applied,
(2) all studied
companies had a strong
cultural cohesion,
(3) experienced persons
were always in charge
of the RE process and
31
(4)Requirements errors
for these companies
were rarely
catastrophic.
Dorr et
al.
[Dorr08]
-- SMALL
COMPANIE
S CALLED
ReqMan
20 - 200 Not mentioned
Jantunen
c
[Jant10]
-
-
SMALL
AND
MEDIUM-
SIZED
5 Study found that
cooperation and
frequent face-to-face
communication have a
central role within the
smaller development
teams.
Quispe
et al
[Quis10]
CHILE 24 Findings show the need
for appropriate
RE practices in VSSE.
However, such study
does not identify which
are the best practices
in that scenario.
32
The above tables just prove the fact that requirement
engineering has not been a trivial aspect of software
engineering as a discipline and has indeed attracted a
number of researches and just as diverse aspects of
requirements engineering are been brooded upon likewise any
other project, one can only strive to improve on past works
and try to figure out what and how to do it better.
2.6 Empirical studies on software Engineering
The software industry is exhibiting an increasing interest
in requirements engineering — that is, understanding what
you intend to build before you’re done building it. Despite
the excitement of "Internet time," companies across many
business domains realize that time spent understanding.(Wieger, 2000)
A description of state of practice serves several purposes.
For a researcher, it outlines areas where further research
may or may not be needed. For an educator, it may outline
areas where training programs can be designed. For a
practitioner, it outlines areas where care must be taken to
obtain a working, consistent, and coherent set of practices.
Moreover, it shares the experiences from other practitioners
of what is working and what is not.
Looking through all that has been discussed draws attention
to the fact that while there may be RE practices to actually
33
follow through when developing software, the stakeholders
involved in the development life cycle all misinterpret or
rather interpret requirements differently which will be the
first issue to be examined by extensively drawing out the
key areas of great expectation in the development of the
software. It is also observed that though a lot of studies
have been done in the area of Requirement Engineering till
date, still a clear state of practice of Requirements
engineering has not been concluded because it portrays what
works for the engineer and the environment in which the
developments take place.
34
CHAPTER THREE
RESEARCH METHODOLOGY3.1 Introduction
Four software developing industries in Nigeria were
selected to represent a sample of the software industry
in Nigeria based on their experience in the industry
and a total of 19 respondents emerged from all four
organizations. The breakdown of the research method is
shown in the figure below. The research prepares
research questions, creates, and validates the
questionnaire. The research questions are formulated
after the investigative study of the related work.
36
Figure 2: Research Methodology
3.2 Survey Instruments
The entire requirements engineering process is
portrayed by a number of core activities which include
requirements elicitation, requirements analysis,
requirements, validation etc. Each activity is
correspondingly imperative for requirement engineering
to be successful and as such careful attention was
given to the each activity to enable us capture in
detail the importance attached to every bit and piece.
37
REVIEW OF RELEVANT
LITERATURE
QUESTIONNAIRE CONSTRUCTION
DATA COLLECTION
DATA ANALYSIS
SURVEY RESULTS
CONCLUSION
A questionnaire was designed after an investigative
study of related works. The questionnaire was
constructed in such a way as to capture belief and
practice of the processes of requirement engineering
from the software industries. Information about the
respondent and his organization is asked, first. The
information includes the organization’s name, the
respondent’s experience with requirements engineering
(in years) and the position of the respondent in the
organization.
The major challenge encountered during questioning is
the untimely and belated entry of responses. The
questionnaire is accompanied with quite a few bits of
information like what the purpose of the investigative
study is (to guide the respondents in answering), a
brief description of each core activity and most
importantly confidentiality and anonymity would be
maintained and preserved.
The RE definition preserves the combined understanding.
A likert scale of ‘1’ to ‘5’ is introduced (‘1’
indicating strongly disagree and ‘5’ indicating
strongly agree) in response to the questions involved
and ‘N/A’ indicating not applicable where the
respondent deemed necessary. The respondents have to
weigh the importance of the elicitation, analysis,
management, validation, prioritization, evolution,
38
description and the functionality and non-functionality
of requirements in relation to requirements
engineering. Space limit only allows the display of a
few of the questions as seen in figures 3 and 4.
3.3 Data Collection
A self-administered data collection method was used.
The questionnaire was mounted on a site and was
validated during phone calls and e-mail correspondences
of persons who have experience in the development of
software. First the respondents were contacted by
phone; the purpose of the study was briefly explained
to individual participants, if the individuals agreed
to participate in the study, such person’s e-mail
address is collected and the questionnaire URL was sent
to him by e-mail.
3.6 Survey Hypotheses
The following hypotheses were tested within the span of the
survey study of requirements engineering practices among the
software participating software industries.
39
1. Nigerian Software industries believe in RE
activities/practices.
2. Nigerian software industries engage fully in RE
practices
40
CHAPTER FOUR
RESULTS AND DISCUSSIONS
4.1 INTRODUCTION
This section discusses the survey results. The importance of
RE process activities is analyzed along two dimensions; the
belief in requirements engineering activities and the
practice of requirements engineering activities.
4.1.1 Data analysis
Two techniques are used to analyze the collected data; Data
tabulation and Data visualization. Data tabulation requires
the arrangement of the number of cases or instances that
fall into separate categories. Data visualization esp.
charting is used to identify the leading results of the
survey data.
The analysis of the belief of RE activities is given below
across all the respondents and across the software companies
represented. The data gotten was analysed using SPSS
(Statistical package for social sciences).
41
4.2 Belief and level of Engagement in Requirement
engineering practices
The study is aimed at revealing the level of belief and
level of engagement in requirements engineering practices in the
software industries. The evaluation of the results observed for
the level of belief in RE practices is presented below and the RE
practices the results are based on include requirements
elicitation, requirements analysis, requirements management,
requirements validation, requirements, requirements evolution,
requirements description and functional and non-functional
requirements.
4.2.1 Requirements Elicitation
Table 3: Requirements Elicitation
S/N
QUESTIONS SD D N A SA
1 Requirements elicitation isnecessary before thecommencement of a project. (REL1)
0 0 0 2 18
2 It is beneficial to use morethan one requirement elicitationtechniques (interviews,observation, questionnaire,prototypes, Scenarios etc.) forinformation gathering. (REL 2)
0 0 0 3 17
PERCENTAGE 0 0 0 12.5%
87.5%
42
Table 3 presents the respondents assessment of the level of
belief in Requirements elicitation where 87.5% strongly
agree (SA) and 12.5% agree (A) to the claim that
Requirements elicitation is a key process in Requirements
engineering.
048121620
SDDNASA
Figure 3: Requirements Elicitation
4.1.2 Requirements Analysis
Table 4: Requirements Analysis
S/N
QUESTIONS SD D N A SA
1 Requirements analysis is anecessary activity that should becarried out. (RA 1)
0 0 0 3 17
2 The use of a check list should be 0 0 1 6 13
43
employed during requirementsanalysis. (RA 2)PERCENTAGE 0% 0% 2.5% 22.5
%75%
048
1216
SDDNASA
Figure 4: Requirements Analysis
Table 4 presents the respondents assessment of the level of
belief in Requirements analysis where 75% strongly agree
(SA) and 22.5% agree (A) to the claim that Requirements
analysis is a key process in Requirements engineering, while
2.5% are neutral.
4.1.3 Requirements Management
Table 5: Requirements Management
S/N
QUESTIONS SD D N A SA
44
1 We believe carefulidentification of eachrequirement should becarried out.(RM 1)
0 1 1 9 9
2 Change management policiesshould not be defined.(RM6)
4 10 3 1 2
3 Attachment of matrices tothe requirement managementprocess is not important. (RM 7)
2 1 7 7 3
PERCENTAGE 10% 20% 18.33%
28.33%
23.33%
0
4
8
12
SDDNASA
Figure 5: Requirements Management
Table 5 presents the respondents assessment of the level of
belief in Requirements where 23.33% strongly agree (SA) and
28.33% agree (A) to the claim that Requirements management
is a key process in Requirements engineering. 20% disagree
(D) and 10% strongly disagree to this claim while 18% are
neutral.
45
4.1.4 Requirements Validation
Table 6: Requirements Validation
S/N
QUESTIONS SD D N A SA
1 Checks should be made thatrequirements document meetspre-existing guidelines.
0 0 0 7 13
2 It is necessary forvalidation checklists to bedefined.
0 0 2 9 9
3 Different stakeholdersshould not be involved inthe requirements validationprocess.
2 2 2 8 6
PERCENTAGE 3.33%
3.33%
6.67%
40% 46.67%
46
04812
SDDNASA
Figure 6: Requirements Validation
Table 6 presents the respondents assessment of the level of
belief in Requirements where 46.67% strongly agree (SA) and
40% agree (A) to the claim that Requirements validation is a
key process in Requirements engineering. 3.33% disagree (D)
and 3.33% strongly disagree to this claim while 6.67% are
neutral.
4.1.5 Requirements Prioritization
Table 7: Requirements Prioritization
S/N
QUESTIONS SD D N A SA
1 Requirements prioritizationis considered a core activityduring development ofsoftware.
0 0 0 8 12
47
PERCENTAGE 0% 0% 0% 40% 60%
Requirements prioritization is considered a core activity during development of software.0
2
4
6
8
10
12
14
SDDNASA
Figure 7: Requirements Prioritization
Table 7 presents the respondents assessment of the level of
belief in Requirements prioritization where 60% strongly
agree (SA) and 40% agree (A) to the claim that Requirements
analysis is a key process in Requirements
4.1.6 Requirements Evolution
Table 8: Requirements Evolution
S/N
QUESTIONS SD D N A SA
1 It is important to definechange frequency (howfrequent changes should bemade).
1 0 3 16 0
48
2 It is necessary to definethe expected lifespan of theproject.
0 1 1 8 10
3 It is necessary to definethe importance of keepingthe system up to date(technology wise).
5 0 2 13 0
4 It is important to definethe cost of keeping thesystem up to date(technology wise).
0 0 0 11 9
5 It is not necessary todefine the importance ofkeeping the system up todate (functionally).
7 6 2 4 1
6 It is not necessary todecide who will performmaintenance of the projectovertime.
3 2 0 12 3
7 Areas of greatest expectedchange need to be defined(where you are most likelyto encounter change)
0 0 0 10 10
PERCENTAGE 11.4%
6.4% 5.7% 52.9%
23.6%
49
048
1216
SDDNASA
Figure 8: Requirements Evolution
Table 8 presents the respondents assessment of the level of
belief in Requirements evolution where 23.6% strongly agree
(SA) and 52.9% agree (A) to the claim that Requirements
evolution is a key process in Requirements engineering. 6.4%
disagree (D) and 11.4% strongly disagree to this claim while
5.7% are neutral.
4.1.7 Requirements Description
Table 9: Requirements Description
S/N
QUESTIONS SD D N A SA
1 It is necessary to havestandard documents fordescribing requirements.
0 0 2 10 8
2 There should be a design forthe requirements documents tobe more readable.
0 0 1 9 10
3 Change should be an attribute 1 1 0 12 6
50
of a requirements document.4 It is important to produce a
summary of the requirements.0 1 0 9 10
PERCENTAGE 1.25%
2.5% 3.75%
50% 42.5%
04812
SDDNASA
Figure 9: Requirements Description
Table 9 presents the respondents assessment of the level of
belief in Requirements description where 42.5% strongly
agree (SA) and 50% agree (A) to the claim that description
is a key process in Requirements engineering. 2.5% disagree
(D) and 1.25% strongly disagrees to this claim while 3.75%
are neutral.
4.1.8 Functional and Non-Functional Requirements
Table 10: Functional and Non-functional Requirements
S/N
QUESTIONS SD D N A SA
1 The identified functional 0 0 1 10 9
51
requirements should bequantifiable.
2 The quantifiable objectivesapply to the manual andautomated part of theapplication.
0 0 3 11 6
3 The data required by theapplication should not bebuilt with the desiredreliability(trustworthiness).
6 7 5 0 2
4 The data should becollectible within the timeperiod specified.
0 1 0 10 8
5 User roles should beidentified.
11 9 0 0 0
6 Predefined user roles shouldbe presented to the user(client) for observation.
0 1 2 10 7
7 The skill levels of theusers should not be takeninto consideration.
3 1 2 8 6
8 Identification of the trade-off (balance) between peopleand computer is necessary.
0 0 3 10 6
9 The time span for the userfunction needs to bedefined.
0 0 4 10 6
PERCENTAGE 11.1%
10.6%
11.1%
38% 27.9%
52
0
4
8
12
SDDNASA
Figure 10: Functional and Non-functional Requirements
Table 10 presents the respondents assessment of the level of
belief in Functional and Non-functional Requirements where
27.9% strongly agree (SA) and 38.3% agree (A) to the claim
the identification of functional and non-functional
requirements is a key process in Requirements engineering.
10.6% disagree (D) and 11.1% strongly disagree to this claim
while 11.1% are neutral.
Table 11 below provides a tabulation of the descriptive
statistics for each of the respondent’s assessment of the RE
activities.
Table 11: Descriptive Statistics of level of belief in Requirements Engineering
Activities
N Minimum Maximum Mean Std.
53
Deviation
Requirementselicitation isnecessarybefore thecommencement ofa project.
20 4.00 5.00 4.9000 .30779
It isbeneficial touse more thanone requirementelicitationtechnique(interviews,observation,questionnaire,prototypes,Scenarios etc.)for informationgathering.
20 3.00 5.00 4.4000 .68056
Requirementsanalysis is anecessaryactivity thatshould becarried out.
20 4.00 5.00 4.8500 .36635
The use of acheck listshould beemployed duringrequirementsanalysis.
20 3.00 5.00 4.6000 .59824
We believecarefulidentificationof eachrequirementshould be
20 2.00 5.00 4.3000
.80131
54
carried out.Changemanagementpolicies shouldnot be defined.
20 1.00 5.00 3.6500 1.18210
Attachment ofmatrices to therequirementmanagementprocess is notimportant.
20 1.00 5.00 2.6000 1.14248
Checks shouldbe made thatrequirementsdocument meetspreexistingguidelines.
20 4.00 5.00 4.6500 .48936
It is necessaryfor validationchecklists tobe defined.
20 3.00 5.00 4.3500 .67082
Differentstakeholdersshould not beinvolved in therequirementsvalidationprocess.
20 1.00 5.00 2.3000 1.30182
Requirementsprioritizationis considered acore activityduringdevelopment ofsoftware.
20 4.00 5.00 4.6000 .50262
It is importantto definechangefrequency.
20 1.00 4.00 3.7000 .73270
55
It is necessaryto define theexpectedlifespan of theproject.
20 2.00 5.00 4.3500 .81273
It is necessaryto define theimportance ofkeeping thesystem up todate .
20 1.00 4.00 3.1500 1.30888
It is importantto define thecost of keepingthe system upto date .
20 4.00 5.00 4.4500 .51042
It is notnecessary todefine theimportance ofkeeping thesystem up todate .
20 1.00 5.00 2.3000 1.30182
It is notnecessary todecided whowill performmaintenance ofthe projectovertime.
20 1.00 5.00 2.5000 1.31789
Areas ofgreatestexpected changeneed to bedefined (whereyou are mostlikely toencounterchange)
20 4.00 5.00 4.5000 .51299
56
It is necessaryto havestandarddocuments fordescribingrequirements.
20 3.00 5.00 4.3000 .65695
There should bea design fortherequirementsdocuments to bemore readable.
20 3.00 5.00 4.4500 .60481
Change shouldbe an attributeof arequirementsdocument.
20 2.00 5.00 4.1500 .74516
It is importantto produce asummary of therequirements.
20 2.00 5.00 4.4000 .75394
The identifiedfunctionalrequirementsshould bequantifiable.
20 3.00 5.00 4.4000 .59824
Thequantifiableobjectivesapply to themanual andautomated partof theapplication.
20 3.00 5.00 4.1500 .67082
The datarequired by theapplicationshould not bebuilt with the
20 1.00 5.00 2.2500
1.20852
57
desiredreliability.The data shouldbe collectiblewithin the timeperiodspecified.
19 2.00 5.00 4.3158 .74927
User rolesshould beidentified.
20 4.00 5.00 4.5500 .51042
Predefined userroles should bepresented tothe user(client) forobservation.
20 2.00 5.00 4.1500 .81273
The skilllevels of theusers shouldnot be takenintoconsideration.
20 1.00 5.00 2.3500 1.38697
Identificationof the trade-off (balance)between peopleand computer isnecessary.
19 3.00 5.00 4.1579 .68825
The time spanfor the userfunction needsto be defined.
20 3.00 5.00 4.1000 .71818
Valid N(listwise) 18
58
Table 11 gives a descriptive data of all the respondent’s
responses including the frequency statistics such as mean,
and standard deviation. It cuts across all the different RE
activities already treated in this study and gives us an
evaluation of the level of the belief in RE activities.
4.2 Practice of Requirements engineering activities
The evaluation of results for the level of practice of RE
practices among Nigerian software industries is given below,
here, we aim to decipher the level of engagement of the
software industries in the Re practices.
4.2.1 Requirements Elicitation
Table 12: Requirements Elicitation
S/N
QUESTIONS SD D N A SA
1 Our organization uses scenarioswhen carrying out requirementselicitation.
0 0 0 15 4
2 We prototype poorly understoodrequirements.
0 3 4 8 3
3 When carrying out requirementselicitation, We considerorganizational factors whichinfluence requirements resources.
0 1 1 12 5
4 We reuse requirements from othersystems which have been developed
0 0 2 10 8
59
in the same application area.5 We use interview to elicit
requirements.1 1 1 8 8
6 We employ the use ofquestionnaire during requirementelicitation.
2 1 5 4 7
7 We define the processes foroperation.
1 2 1 10 6
PERCENTAGE 3% 5.9% 10.4%
50% 30.4%
048
1216
SDDNASA
Figure 11: Requirements Elicitation
Table 12 presents the respondents assessment of the level of
engagement in Requirements elicitation where 30.4% strongly
agree (SA) and 50% agree (A) to the actively engaging in
Requirements elicitation as a key process in Requirements
engineering. 5.9% disagree (D) and 3% strongly disagree to
this claim while 10.4% are neutral.
60
4.2.2 Requirements Analysis
Table 13: Requirement analysis
S/N
QUESTIONS SD D N A SA
1 We define the systems boundaries. 0 2 1 9 82 We perform risk analysis on the
requirements given.0 2 2 9 6
PERCENTAGE 0% 10.3%
7.7% 46.1%
35.9%
0246810
SDDNASA
Figure 12: Requirements analysis
Table 13 presents the respondents assessment of the level of
engagement in Requirements analysis where 35.9% strongly
agree (SA) and 46.1% agree (A) to the actively engaging in
Requirements elicitation as a key process in Requirements
engineering. 10.26% disagree (D) while 7.7% are neutral.
61
4.2.3 Requirements Management
Table 14: Requirements Management
S/N
QUESTIONS SD D N A SA
1 We do not have definedprinciples for requirementsmanagement.
1 8 3 5 3
2 We define traceabilitypolicies
1 2 5 7 5
3 We carry out requirementtraceability
1 3 4 9 3
4 We do not documenttraceability of requirementsfrom the origin
0 5 6 6 3
5 We identify unpredictablerequirements.
3 1 4 11 1
6 We manage requirements byelectronic means.
0 2 4 11 3
7 We do not reuse requirementsover different similarprojects.
2 11 4 1 2
8 We document rejectedrequirements.
3 3 4 8 1
PERCENTAGE 6.9% 22% 21.3%
36.6%
13.2%
62
0
4
8
12
SDDNASA
Figure 13: Requirements Management
Table 14 presents the respondents assessment of the level of
engagement in Requirements management where 13.2% strongly
agree (SA) and 36.6% agree (A) to the actively engaging in
Requirements management as a key process in Requirements
engineering. 22% disagree (D) and 6.9% strongly disagree to
this claim while 21.3% are neutral.
4.2.4 Requirements Validation
Table 15: Requirements Validation
S/N
QUESTIONS SD D N A SA
1 We organize inspection ofrequirements.
0 3 1 9 6
2 We involve externalreviewers to partake in thevalidation process
2 5 3 7 3
63
3 We encourage the use ofelectronic system (e.g. e-mail) to supportrequirements agreement
0 0 2 14 4
4 We make plans for conflictand conflict resolution(should in case it occurs)
0 2 1 9 8
5 We encourage the use ofelectronic means to supportrequirements communication
0 1 0 11 7
6 We encourage the use ofphone calls to supportrequirement communication
0 4 3 6 7
7 We encourage the use ofinterviews for requirementscommunication (face-to-face)
0 2 1 7 10
PERCENTAGE 1.4% 12.3%
8% 45.7%
32.6%
0481216
SDDNASA
Figure 14: Requirements Validation
Table 15 presents the respondents assessment of the level of
engagement in Requirements validation where 32.6% strongly
64
agree (SA) and 45.7% agree (A) to the actively engaging in
Requirements validation as a key process in Requirements
engineering. 12.3% disagree (D) and 1.4% strongly disagrees
to this claim while 8% are neutral.
4.2.5 Requirements Prioritization
Table 16: Requirements Prioritization
S/N
QUESTIONS SD D N A SA
1 We use a well definedrequirements prioritization(e.g. rating of requirementsby stakeholders according toorder of importance)
1 0 2 10 7
PERCENTAGE 5% 0% 10% 50% 35%
We use a well defined requirements prioritization (e.g. rating of requirements by stakeholders according to order of importance)0
2
4
6
8
10
12
SDDNASA
Figure 15: Requirements Prioritization
65
Table 16 presents the respondents assessment of the level of
engagement in Requirements prioritization where 35% strongly
agree (SA) and 50% agree (A) to the actively engaging in
Requirements prioritization as a key process in Requirements
engineering. 5% strongly disagree to this claim while 10%
are neutral.
4.2.6 Requirements Evolution
Table 17: Requirements Evolution
S/N
QUESTIONS S/D D N A S/A
1 We identified a plan todocument these changes.
0 1 3 9 7
2 We have a guideline forappropriately documentingthese changes
0 4 3 8 5
PERCENTAGE 0% 12.5%
15% 42.5%
30%
66
02468
10
SDDNASA
Figure 16: Requirements Evolution
Table 17 presents the respondents assessment of the level of
engagement in Requirements evolution where 30% strongly
agree (SA) and 42.5% agree (A) to the actively engaging in
Requirements evolution as a key process in Requirements
engineering. 12.5% disagree (D) and15% are neutral.
4.2.7 Requirements Description
Table 18: Requirements Description
S/N
QUESTIONS SD D N A SA
3.3
We have guidelines on howto write requirements.
0 4 4 7 5
3.4
We do not have a glossaryof specific terms.
2 4 3 8 3
3.6
We employ the use ofdiagrams and
0 2 1 9 7
67
appropriately so.PERCENTAGE 3.4% 16.95
%13.56%
40.67%
25.42%
02468
10
SDDNASA
Figure 17: Requirements Description
Table 18 presents the respondents assessment of the level of
engagement in Requirements description where 25.42% strongly
agree (SA) and 40.67% agree (A) to actively engaging in
Requirements description as a key process in Requirements
engineering. 3.4% strongly disagree and 16.95% disagree (D)
to this claim while 13.56% are neutral.
4.3 Hypothesis Testing
68
The following hypotheses were tested within the field of the
study of requirement engineering practices in Nigerian
software industries.
H1: Nigerian software industries believe in RE
practices/activities.
H2: Nigerian software industries engage fully in RE
practices.
*H3: Nigerian software industries engage partially (not
fully) in RE practices
Null Hypothesis: There is no significant difference in the
level of belief in RE practices among Nigerian software
industries.
Alternate Hypothesis: There is significant difference in the
level of belief in RE practices among Nigerian software
industries.
Table 19: One-Sample Statistics
N Mean
Std.Deviation
Std.ErrorMean
Belief.Compute 18 3.9086 .28149 .06635
69
Table 20: One-Sample Test
One-Sample Test
58.911 17 .000 3.90860 3.7686 4.0486Belief.Computet df Sig. (2-tailed)
MeanDifference Lower Upper
95% ConfidenceInterval of the
Difference
Test Value = 0
From the tables presented above, the null hypothesis will be
rejected and the alternative accepted because the
significant levels of the t statistics was found to be
significant at 1 percent levels of significance. This
implies that there is no significant difference in the level
of belief in RE practices among Nigerian software
industries.
Null Hypotheses: There is no significant difference in the
level of full engagement in RE practices/activities among
Nigerian software industries.
Alternative Hypothesis: There is significant difference in
the level of full engagement in RE practices/activities
among Nigerian software industries.
Table 21: One-Sample Statistics
N Mean
Std.Deviation
Std.ErrorMean
Practice. 15 3.7111 .53699 .13865
70
ComputeTable 22: One-Sample Test Statistics
One-Sample Test
26.766 14 .000 3.71111 3.4137 4.0085Practice.Computet df Sig. (2-tailed)
MeanDifference Lower Upper
95% ConfidenceInterval of the
Difference
Test Value = 0
1. T implies the t-statistics, which measures the level of
significance
2. df means the degree of freedom which is the (n-1),
where n is the number of respondents
3. Sig means the level of significance such as t. they
perform the same role.
4. Mean difference is the difference in the mean
respondents across the respondents. This statistics is
not as relevant.
5. 95% confidence interval measures the lower and upper
bound where the t is
From the tables presented above, the null hypothesis will be
rejected and the alternative accepted because the
significant levels of the t statistics was found to be
significant at 1 percent levels of significance. This
implies that there is no significant difference in the level
of full engagement in RE activities among Nigerian software
industries.
4.4 Discussions71
CHAPTER FIVE
DISCUSSION AND CONCLUSION5.1 Summary
This study carefully investigated the state of
requirements engineering practices in Nigerian software
industries. This chapter helps in summarizing this
project work providing highlights of the work. In view
of the acceptable adoption of requirements engineering,
the study was introduced in Chapter one, chapter two
gave an in-depth overview of requirements engineering
including the significance and consequences of poor RE
practices. Chapter three looked at the survey
methodology and the instruments used to carry out the
survey, as well as the method of data collection.
Chapter four provided the analysis of the results
gotten from the survey as well as related discussions
and finally chapter 5 summarizes the findings and
presents the conclusions and recommendation.
72
5.2 Conclusion
The software industry has struggled to build quality
software unsuccessfully and this is evident in the
deployment of major software projects because software
projects turn out disappointedly because of unconscious
response to requirements management approaches. There
is need to bridge the gap between increasing
distribution of software projects in the industry and
the challenge of optimizing the allocation and
integration of inputs necessary to meet defined project
objectives.
Therefore this study reports a survey on the RE
practices in the Nigerian software industries.
73
REFERENCES
1. Akinola, O., AJAO, F., & Akinkunmi, O. B. (2011). An
Empirical Study of Software Project Management among Some
Selected Software Houses in Nigeria. (IJCSIS) International Journal
of Computer Science and Information Security, 9.
2. Al-Fataftah, I. A., & Issa, A. A. (2012). A Systematic
Review for the Latest Development in Requirements
Engineering. World Academy of Science, Engineering and Technology.
3. Antoniou, G. (1998). The role of nonmonotonic
representations in. International Journal of Software Engineering and
Knowledge Engineering, 8(3).
4. Asghar, D. S., & Mahrukh, U. (n.d.). Requirement Engineering
Challenges in Development of Software Applications and
Selection of Customer-off-the-Shelf (COTS) Components.
International Journal of Software Engineering (IJSE), 1(2).
5. Aurum, A., & Wohlin, C. (n.d.). Requirements Engineering:
Setting the Context.
6. C.Coulin, D. a. (2004). Requirements elicitation: A survey
of techniques, approaches and tools.
7. Damian, D., Chisan, J., Lakshminarayanan, V., & Yogendra, P.
(2005). Requirements Engineering and Downstream Software
Development: Findings from a Case Study. (L. Briand, Ed.)
8. Dörr, D. J. (2012/2013). Requirements Engineering.
9. Finkelstein, A. (n.d.). Requirements Engineering: a review
and research agenda.
74
10. Hofmann, H. F., & Lehner, F. (2001, July/ August).
Requirements Engineering as a Success factor in Software Projects.
11. Introduction to Requirements Engineering. (n.d.). Springer
Berlin Heidelberg. doi:10.1007/978-3-540-68476-3_4
12. Issa, A. A., & Al-Fataftah, I. A. (2012). A Systematic
Review for the Latest Development in Requirement
Engineering. World Academy of Science, Engineering and Technology.
13. Knethen, A. v., Kamsties, E., Reussner, R., Bunse, C.,
& Shen, B. (n.d.). A Comparative Case Study with Industrial
Requirements Engineering Methods.
14. Lamsweerde, A. v. (n.d.). Requirements Engineering in
the Year 00: A Research Perspective.
15. Leffingwell, D., & Widrig, D. (2000). Managing
Software Requirements- A unified approach.
16. Matuleviˇcius, R. (2005). Survey of Requirements
Engineering Practice in Software Development Countries.
(Springer, & O. V. etal., Eds.) Information Systems Development:
Advances in Theory, Practice and Education.
17. Nuseibeh, B., & Easterbook, S. (n.d.). Requirements
Engineering:A Roadmap.
18. Rajilch, V. T., & Bennett, K. H. (2000). Software
Maintenance and Evolution In this volume.
19. Ramingwong, L. (2012, June). A Review of Requirements
Engineering Processes, Problems and Models. International Journal
of Engineering Science and Technology (IJEST), 4(6).
20. Requirement Elicitation: Wikipedia. (2013). Retrieved May 5,
2013, from Wikipedia:
http://en.wikipedia.org/wiki/Requirements_elicitation
75
21. Requirements Analysis. (2013, May 10). Retrieved from
Wikipedia:
http://en.wikipedia.org/wiki/Requirements_analysis
22. Requirements Engineering. (n.d.). Retrieved May 13, 2013,
from Wikipedia:
http://en.wikipedia.org/wiki/Requirements_engineering
23. Requirements Management. (n.d.). Retrieved April 24,
2013, from Wikipedia:
http://en.wikipedia.org/wiki/Requirements_management
24. Sen, A. M., & Hamachandran, K. (2010). Goal Oriented
Requirement Engineering: A Literature Survey. Assam University
Journal of Science & Technology: Physical Sciences and Technology, 6(II).
25. Shaw, M. (1990). Prospects for an Engineering
Discipline of Software. IEEE Software.
26. Sommerville, I. (2004). Software Engineering
Processes.
27. Sommerville, I., & Sawyer. (1997). Requirements
Engineering: A Good Practice Guide.
28. Tarawneh, M. (2012, July 15). Software Engineering
Requirements Problems; An Investigation Study in Jordanian
Context. Journal of Theoretical and Applied Information Technology, 41(1).
29. Wahono, R. S. (2003 ). Analyzing Requiremnets
Engineering Problems. IECI Chapter Japan Series, 5(2).
30. Wahono, R. S. (2003). Analyzing Requirements
Engineering Problems.
31. Wieger, K. E. (2000). When Telepathy Won’t Do: Requirements
Engineering Key Practices. Retrieved from Process Impact:
http://www.processimpact.com/articles/telepathy.html
76
32. Zave, P. (1997). Classification of Research Efforts in
Requirements Engineering. ACM Computing Surveys, 29(4).
APPENDIX
1. INTRODUCTION
This questionnaire is designed to investigate the state
of practice of Requirements Engineering (RE) in the
Nigerian Software Industry. By way of definition, RE
entails the process of developing the requirements. RE
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.
INSTRUCTIONS
You are expected to answer all questions according to
your knowledge, experience and position within your
organization.
Each question has the following multiple-choices;
N/A: Not applicable, if the question does not suit your
organization.
The other answers consist of five different levels
namely;
1: Strongly Disagree
2: Disagree
77
3: Neutral
4: Agree
5: Strongly Agree
N/A: Not Applicable
Please note that all information provided by you in this
questionnaire will be treated with utmost confidentiality
– including names, email and organization profile.
GENERAL INFORMATION
Please fill in the gap with relative information
E-Mail (Optional):
Position (indicate with a *): top-level/ managerial [ ];
middle-level [ ]; lower-level [ ]; others [ ];
Name of Organization:
Size of software development team in your organization (mark
x): Above 20 [ ]; 16-20 [ ]; 11-15 [ ]; 5-10 [ ]; 2-4 [ ];
Experience with RE (mark x where appropriate): above 20 [ ];
16-20 [ ]; 11-15 [ ]; 5-10 [ ]; 2-4 [ ];
2. REQUIREMENTS ENGINEERING ACTIVITIES (PROCESSES)
REQUIREMENTS ELICITATION
Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and other
stakeholders.
78
S/N
QUESTIONS 1 2 3 4 5 N/A
2.1
Requirements elicitation isnecessary before thecommencement of a project.
2.2
It is beneficial to use morethan one requirementelicitation techniques(interviews, observation,questionnaire, prototypes,Scenarios etc.) forinformation gathering.
2.3
Our organization usesscenarios when carrying outrequirements elicitation.
2.4
We prototype poorly understoodrequirements.
2.5
When carrying out requirementselicitation, We considerorganizational factors whichinfluence requirementsresources.
2.6
We reuse requirements fromother systems which have beendeveloped in the sameapplication area.
2.7
We use interview to elicitrequirements.
2.8
We employ the use ofquestionnaire duringrequirement elicitation.
2.9
We define the processes foroperation.
REQUIREMENT ANALYSIS
79
Requirements analysis in systems engineering and software
engineering revolves around the tasks that go into
determining the needs or conditions to meet for a new or
altered product, taking account of the possibly
conflicting requirements of the various
stakeholders, analyzing, documenting, validating and
managing software or system requirements.
S/N
QUESTIONS 1 2 3 4 5 N/A
2.10
Requirements analysis is anecessary activity that should becarried out.
2.11
The use of a check list should beemployed during requirementsanalysis.
2.12
We define the systems boundaries.
2.13
We perform risk analysis on therequirements given.
REQUIREMENTS MANAGEMENT
Requirements management is the process of
documenting, analyzing, tracing, prioritizing and agreeing
on requirements and then controlling change and
communicating to relevant stakeholders. It is a continuous
process throughout a project.
S/N
QUESTIONS 1 2 3 4 5 N/A
2. We believe careful80
14 identification of eachrequirement should becarried out.
2.15
We do not have definedprinciples forrequirements management.
2.16
We define traceabilitypolicies
2.17
We carry out requirementtraceability
2.18
We do not documenttraceability ofrequirements from theorigin
2.19
Change management policiesshould not be defined.
2.20
Attachment of matrices tothe requirement managementprocess is not important.
2.21
We identify unpredictablerequirements.
2.22
We manage requirements byelectronic means.
2.23
We do not reuserequirements overdifferent similarprojects.
2.24
We document rejectedrequirements.
REQUIREMENTS VALIDATION
Validation is a requirement activity intended to check that
development and verification procedures for a product,
service, or system (or portion thereof, or set thereof)
81
result in a product, service, or system (or portion thereof,
or set thereof) that meets initial requirements,
specifications, and regulations.
S/
N
QUESTIONS 1 2 3 4 5 N/A
2.
25
Checks should be made that
requirements document meets
pre-existing guidelines.2.
26
It is necessary for
validation checklists to be
defined.2.
27
We organize inspection of
requirements.2.
28
We involve external
reviewers to partake in the
validation process2.
29
Different stakeholders
should not be involved in
the requirements validation
process.2.
30
We encourage the use of
electronic system (e.g. e-
mail) to support
requirements agreement2.
31
We make plans for conflict
and conflict resolution
82
(should in case it occurs)2.
32
We encourage the use of
electronic means to support
requirements communication2.
33
We encourage the use of
phone calls to support
requirement communication2.
34
We encourage the use of
interviews for requirements
communication (face-to-
face)
REQUIREMENTS PRIORITIZATION
Requirement prioritization is used in requirement management
for determining which requirements of a software product
should be included in a certain release. Requirements are
also prioritized to minimize risk during development so that
the most important or high risk requirements are implemented
first.
S/
N
QUESTIONS 1 2 3 4 5 N/A
2.
35
Requirements
prioritization is
considered a core activity
during development of
software.
83
2.
36
We use a well defined
requirements
prioritization (e.g.
rating of requirements by
stakeholders according to
order of importance)
REQUIREMENTS EVOLUTION
Requirements Evolution or Maintenance as it is commonly know
entails the evolvement of requirements with respect to
change and maintenance.
S/N
QUESTIONS 1 2 3 4 5 N/A
2.37
It is important to definechange frequency (howfrequent changes should bemade).
2.38
It is necessary to definethe expected lifespan ofthe project.
2.39
It is necessary to definethe importance of keepingthe system up to date(technology wise).
2.40
It is important to definethe cost of keeping thesystem up to date(technology wise).
2.41
It is not necessary todefine the importance ofkeeping the system up todate (functionally).
84
2.42
It is not necessary todecided who will performmaintenance of the projectovertime.
2.43
Areas of greatest expectedchange need to be defined(where you are most likelyto encounter change)
2.44
We identified a plan todocument these changes.
2.45
We have a guideline forappropriately documentingthese changes
3. PRODUCT REQUIREMENTS ENGINEERING
REQUIREMENTS DESCRIPTION
A requirements description is a requirements
specification for a software system, is a complete
description of the behaviour of a system to be developed and
may include a set of use cases that describe interactions
the users will have with the software.
S/N
QUESTIONS 1 2 3 4 5 N/A
3.1
It is necessary to havestandard documents fordescribing requirements.
3. There should be a design
85
2 for the requirementsdocuments to be morereadable.
3.3
We have guidelines on howto write requirements.
3.4
We do not have a glossaryof specific terms.
3.5
Change should be anattribute of a requirementsdocument.
3.6
We employ the use ofdiagrams and appropriatelyso.
3.7
It is important to producea summary of therequirements.
FUNCTIONAL REQUIREMENTS AND NON-FUNCTIONAL REQUIREMENTS
Functional requirements specify what a system should do.
Non-functional requirements specify how a system should
behave.
S/N
QUESTIONS 1 2 3 4 5 N/A
3.8
The identified functionalrequirements should bequantifiable.
3.9
The quantifiable objectivesapply to the manual andautomated part of theapplication.
3.10
The data required by theapplication should not bebuilt with the desiredreliability(trustworthiness).
86
3.11
The data should becollectible within the timeperiod specified.
3.12
User roles should beidentified.
3.13
Predefined user rolesshould be presented to theuser (client) forobservation.
3.14
The skill levels of theusers should not be takeninto consideration.
3.15
Identification of thetrade-off (balance) betweenpeople and computer isnecessary.
3.16
The time span for the userfunction needs to bedefined.
87
Top Related