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

JUNE 2013

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

35

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