2015

ASSIGNMENT NO. 02
Review Research Paper Of Requirement
Elicitation

SOFTWARE REQUIREMENT ENGINEERING

SUBMITTED TO:
Ma’am Saria Safdar

SUBMITTED BY:
Uzma Noorin (077)
Munazza Ayub (103)
Neelum Raffique (067)
Rida Irfan (068)

BSE – VB

FATIMA JINNAH WOMEN UNIVERSITY, RAWALPINDI

11/30/2015
 REQUIREMENT ELICITATION
ABSTRACT
Requirement Elicitation is one of the important factors that help in determining the needs of
customers, users and stakeholders in building systems and software. It is the most complex part of
requirement engineering phases and it demands as much attention especially in Global Software
Development Scenarios. Without the elicitation techniques it is impossible to find out requirements and
the needs of the developing system. In recent years, the Requirements Engineering community has
dedicated a lot of efforts in order to tackle the Requirements Elicitation (RE) problem. Challenges that
we face in RE include challenges in dealing with the explosive nature of requirements, issues in
describing the system limit, issue in understanding among the different stakeholders who are affected by
the improvement of system. These challenges may result in poor requirements and termination of system
progress.

INTRODUCTION:
Requirements elicitation is a crucial first step in the software development process. Quality
requirements are essential to the success of any software development project. This research paper is
based on understanding requirement elicitation, its techniques, their usage in real time applications, to
present a view of what can go wrong in requirements elicitation and describe the issues and challenges
in various requirements elicitation techniques. Success or failure of any project depends upon the quality
of requirements and quality of the requirement and the methodology that we adopted during the
elicitation. Global Software development undertakes software developmental geographically separate
locations with efficient coordination. To meet the software objectives effective communications across
various project development locations is very important. The success of requirement elicitation based
upon identifying the appropriate stakeholders from different background and determining their needs. It
is very important to include all stakeholders in information gathering phase.

STAGES OF REQUIREMENT ELICITATION PROCESS

 Understanding the Application Area

This stage provides understanding about Stakeholders ‘abilities and domain knowledge,
Limitations of computer resources and functionality, and accessibility of other resources

 Classifying the Foundations of Requirements

Requirements may exist in a mixture of formats. In all software development projects
number of sources for requirements are used. E.g: Stakeholders represent the clearest source of
requirements for the system. Users are used to provide detailed information about the issues and
user requirements.

 Analysis, Identification and Documentation of the Stakeholders

The most important step in RE is to analyze and identify all the relevant stakeholders, who
are affected in some way by the implementation of the system. Generally, customer is the most
apparent stakeholder of the system.

 Collecting Information about Users’ need and write Description

In this stage we examine needs and wants of stakeholders in detail. This stage identifies
problems about stakeholder’s abilities and domain knowledge.

 Conducting Interview for Stakeholders

Interviews are conducted to refines the needs and opportunity expressed in description of
users and to recognize keywords used by the users. Interviews may be structured or unstructured.
  Selecting Elicitation Method
The selection of elicitation method depends on the particular environment of the project
and it is often a serious aspect in the completion of the elicitation process. The selection of
method is based on analyst ‘choice.

 Fitting the Requirements to the Domain

This stage solved the issue of problem domain which may hinder the rest of development.
These issues can be solved only by employing domain experts and knowledge experts.

 Prototyping
At this stage analyst have a correct set of requirements, which is tested by building a
prototype. Prototyping test the efficiency and completeness of requirements. It provides away to
check the outcome of user’s needs.

 Confirmation of Prototype
Every system necessity should be tested for its practicality, quality, unambiguity, and
accuracy. After this confirmation stakeholders have the prospect to define system requirements
more precisely by rejecting redundant information. This will help developers and expert to
understand actual requirements of client.

 Overall Analysis
It is the last stage of requirement elicitation process in which expert check whole set of
system necessities to make sure all done so far is accurate. After this stage developer actually
starts develop the system.

ELICITATION TECHNIQUES

 Direct Approach
In direct approach the purpose is to enhance the understanding of the problems of system
that is currently in used. Most common techniques used are Interviews, case study, Prototyping.
 Indirect Approach
Indirect methods are used in order to obtain information that cannot be easily articulated
directly. Questioners, documents analysis are its examples.

Various Requirement Elicitation Techniques

The various requirement elicitation techniques are:
 Interview
Interviewing consists of asking the domain expert questions about the domain of interest
and how they perform their tasks. Interviews can be unstructured, semi structured, or structured.
Some interview methods are used to build a particular type of model of the task. The model is
built by the knowledge engineer based on information obtained during the interview and then
reviewed with the domain expert.

 Questionnaires
Questionnaires are very important technique in requirement elicitation techniques,
questionnaires helps to get the information from many peoples, analyst can gather opinions from
two ways: to get statistical evidence for an assumption, or to gather opinions and suggestions.

 Observation
 In Observation methods, the knowledge engineer observes the expert performing a task.
This prevents the knowledge engineer from inadvertently interfering in the process, but does not
provide any insight into why decisions are made.

 Documents Analysis
Document analysis involves gathering information from existing documentation. It may
or may not involve interaction with a human expert to confirm or add to this information.

 Prototyping
Actually prototyping is the process to build the model about the system. Prototypes help
the system designers to build the information system according the requirements and easy to
manipulate for end users. Prototyping is an iterative process and it is also part of the analysis
phase of system development life cycle. Prototyping can extend the information collection
process, because prototyping can convert the basic things (indefinable requirements into
definable requirements).

FAILURE AND ABANDONMENT RATES

The most common definition of failure is when a project goes over time, over budget or does not meet
its objectives in anyway.
 Cost of Failure
The cost of this failure is enormous. The failure of information systems projects is a
global problem and of significant size.
 Persistence of Failure
Failure of Information Systems projects is not only at high levels, but has been persistent
over many years. Time commentary on information systems project failure has continued to
indicate that little progress is being made in this costly problem. The persistence is remarkable as
significant work has been done in addressing failure and it would be expected that this work
would impact professional practice and hence performance.

PROPOSED RESEARCH WORK

The objective of research is to determine the issues that exist in the requirement elicitation, make
a structural model that predicts the impacts of elicitation issues and requirements uncertainty on project
success. Then empirically test the model through survey data. We present the method to achieve these
goals.

Research methodology
P1 P2
Conduct in-depth interviews with industry Conduct document analysis on
practitioners (termed as “practitioner Requirements Elicitation Issues (termed
group”) as "research group")

Compare results from practitioner

group and research group
P3

Determine elicitation dimensions that

influence the overall RE process P4
 P5
Theoretical modeling of
requirements uncertainty
and elicitation dimensions

Empirical validation of the

theoretical model through
surveys
P6

Phase 1: we conduct in-depth interviews with industry practitioners.

Phase 2: we conduct document analysis on elicitation issues. The outcome of this phase is state-of-the-
art requirements elicitation issues.
Phase 3: we compare the results of first and second phase.
Phase 4: we determine dimensions that influence the elicitation factors and have an impact on the
overall RE success.
Phase 5: we do the theoretical modeling of requirement uncertainty and elicitation factors.
Phase 6: It is the last phase in which we empirically test the model.

LITERATURE REVIEW
According to Gabriela et.al, about 40% to 60% projects failed due to poor software management
and requirement definition. Challenges that we faced in Elicitation are categorized in to three groups.
i. Problem of Scope: For requirement elicitation it is very important to understand the boundaries
of System
ii. Problem of understanding: Users have incomplete understanding of their needs they have poor
understanding of computer capabilities and limitations so problem of understanding is a big
challenge in requirement elicitation.
iii. Problem of Volatility: These problems arises due to poor change management processor
understanding of the requirement as change
PRACTITIONERS VIEW
According to practitioners, issues related to requirements become the major cause of project
failure. Most of practitioners believe that some basics need to be applied well and this is related to
structuring and documenting requirements.

Motivation in Research
The results of the survey amongst practitioners of mature organizations indicated that challenges
still existed in this field. These challenges are
 Lack of business/ application knowledge
 Misinterpretation of requirements
 Poor documentation skills
 Incorrect requirements
 Incomplete/ ambiguous requirements
 Poor communication skills/ articulation
 Stakeholder identification/ involvement
THE ROLE OF RE IN INFORMATION SYSTEMS PROJECT FAILURE
There is no suggestion here that RE is the only or the critical factor in failure, but that, as an
individual factor it is significant when compared with others.
The contention can be broken into two propositions:
i. The greatest contribution to system failure comes from poor RE
ii. The cost of fixing RE problems is higher than other sources of error.

There is a general agreement that poor RE is an important and potentially damaging part of
building a system. There is also a general agreement amongst commentators that fixing the results of
poor RE is more expensive than for other mistakes. RE is critical to project success. In the next section
evidence is examined as to the relevance of the interview of clients to good RE.

CLASSIFICATION OF PROBLEMS IN RE
The identified problems with RE can be summarized in nine categories:
i. There are human aspects of RE that preclude simple communication between consultant
and client
ii. The language of humans is not always suitable for technological solution
iii. Requirements change as the project proceeds
iv. Clients will sometimes ask for requirements that the organization does not need
v. The client cannot say what the business needs
vi. Some clients do not want to help you with the project
vii. RE failed because it was not done properly
viii. Symptoms that are not problems are often reported
ix. RE is not deterministic

i. There are Human Aspects of RE that Preclude Simple Communication between Consultant
and Client
This problem type has several manifestations. The problems arising from human
limitations in communication can be summarized as follows:
 Humans have cognitive limitations that preclude complete communication.
 A suggestion for approaching this is the use of procedural prompts when framing
questions.
 These encourage deeper thought before answers and have been tested several times with
measurable success.
 People have different cultures (business or social) and backgrounds and so a common
language does not always. For instance, technical people do not understand business
concepts and business people do not understand IT.
 Some success has been obtained in bringing together the frames of reference of
consultant and client through discourse analysis.
 Some plain language statements can mean two different things, e.g., words can be
synonyms or homonyms. The way people express problems can be misleading.
 The amount of information presented can be too large to analyse.
 People who must be consulted disagree on what the requirements should be.

ii. The Language of Humans Is Not Always Suitable for Technological Solution
To convert from English into a technically robust specification entails a range of
problems. These include:
 Many terms used in the real world, e.g., ‘user friendliness’ and ‘reliability’ do not have
exact meanings in a technical sense.
  Some statements of the problem cannot be used to create a solution because of their form
or language.
 Not everything that can be done has equal importance. In a technical solution everything
included has the same priority.
 Some methodologies have gaps.
 The problem is interpreted as being bigger than the originally intended problem.
 Real world problems are very complex. They are also wicked. A wicked problem is one
where the definition of the problem is difficult.
 Some consultants find the process difficult and rely upon their knowledge of previous
solutions.

iii. Requirements Change as the Project Proceeds

A distinct type of reported problem arises independent of the accuracy of an initial
specification. This can be seen as one of three types of change:
 Clients learn what is possible during the project.
 Business is essentially dynamic and so requirements change during the lifetime of the
project.
 People change their mind about what they want.

iv. Clients will Sometimes Ask for Requirements that the Organization Does Not Need
Requirements can be specified directly from client conversations. This is not always
sensible, for instance:
 The client asks for something that is not really needed.
 The client asks for something they are not committed to.

v. The Client Cannot Say What the Business Needs

Problems can arise when the assumption the clients understand their business needs turns
out to be unfounded:
 Some requirements are tacit. That is, understood by the client, but not stated by them as it
forms part of their tacit knowledge.
 Some clients only know about a single section of the business that needs to be fixed.

vi. Some Clients Do Not Want To Help You with the Project
Requirements can be made difficult to elicit if the client representatives are not committed
to the project. This can take several forms:
 A client representative has interests that conflict with others in the project or with the
aims of the project.
 Some people will use resistance tactics to avoid a conclusion to RE.
 Clients see the new system as a part of power struggles in the organization.

vii. RE Failed Because It Was Not Done Properly (e.g., User Input Not Allowed)
Another distinct type of problem is lack of professional training or behavior in the
consultant or analyst:
 No user input was obtained.
 Theory of RE was not used in practice.

viii. Symptoms That Are Not Problems Are Often Reported

Statements are often made using the words “sources of problem” when the description is of
a symptom, e.g., “the three leading sources of project difficulty – i.e., lack of user input,
incomplete requirements, and changing specifications”. The most common of these symptoms
 reported is the outcome of RE being an incomplete or incorrect set of requirements. This can
take a few forms:
 Incomplete requirements.
 Changing specifications.
 Finished system does not include all requirements asked for.
 Incorrect requirements.

RE Is Not Deterministic
There are no causal connections between RE activities and eventual requirements. This type of
thinking has been reflected in a number of post-modern approaches to studying RE.

ISSUES AND CHALLENGES IN ELICITATION TECHNIQUES

Traditional Techniques
This is also known as conversational method, which includes Interviews, Workshops,
Brainstorming, Focus Group. By conducting interviews, workshops or brainstorming and focus group
the requirements are verbalized by stakeholders and communicated with the analysts. Major issues occur
in this method are:
 Sometimes interviewers ask some questions but don’t get response according to his/her
requirements.
 When questions are asked from different stakeholders, they are not assured by having same
words repeated in each session related to subject. These words will impact different meanings to
different people in different environment

Collaborative Techniques
These are also called synthetic methods. Collaborative technique forms a whole stage by
systematically combining conversation, observation, and analysis into single methods for developing
requirement. Issues occur in this technique are:
 In Collaborative method stakeholders will be unable to communicate embedded knowledge.
 As stakeholders may have widely different status within the organization, requirements engineers
will find difficulty to share their thoughts.
Contextual Techniques
These are known as observational method. Contextual techniques help to provide the better
understanding of the application domain by observing human activities. The aim of this technique is to
assemble data about stakeholders, their backgrounds, working techniques and then to interpret the data
to improvement in comprehensive understanding of requirements and proper system design. Issues
occur in this technique are:
 When project has tight schedule along with time limitation at requirement stage and not enough
time for observation, there appears significant issues in contextual technique
 Observation needs sensitivity and awareness about the environment. Sufficient time is necessary
for observation method because it is easy for observers to perceive a rich picture about the work
context, but it is normally difficult to specify and investigate their perception. Therefore, there
must be qualified person as an observation conductor otherwise project schedule may suffer
which creates issues in this phase.

Cognitive Techniques
Cognitive Techniques are developed for knowledge acquisition. It provides a way to discover the
presented documentation or knowledge and gain requirements from a series of assumption. Issues occurs
in this technique are:
 Cognitive techniques are effective in case of proper documentation and expert’s knowledge only.
Innovative Techniques
This technique is also known as model-driven prototyping based technique. It is classified in
rapid prototyping and evolutionary prototyping, which is a visual representation of ‘what the System
will look like’. Normally, users are expected to draw the features through a pen/pencil on paper and
share with Requirement Engineers. Alternatively, a graphics program can also be used for the purpose.
Issues occur in this technique are:
 This technique is used for user interface and it is suitable only for small and medium sized
projects rather than huge project

SYSTEMATIC LITERATURE REVIEW METHODOLOGY

We have defined a set of inclusion / exclusion criteria, which delimit the scope of the Systematic
Literature Review (SLR):

Publication Inclusion And Exclusion Criteria

Inclusion criteria Exclusion criteria

Elicits functional requirements (FRs) or non- Elicits knowledge outside of the software
functional requirements (NFRs) or both. engineering domain.
Describes comprehensive approaches Describes requirements elicitation techniques
e.g. interviews, brainstorming, ethnography,
etc.
Published in 1989 or after Published before 1989
In conference, journal, or in/is a book. In workshops, regional conferences, and
theses.

Some definitions used to establish the study scope are:

 Approach: an “approach” is a systematic arrangement, usually in steps, of ideas or actions
intended to deal with a problem or situation.
 Method: a “method” consists of heuristics and guidelines for the requirements engineer at
different stages of a process.
 Technique: a “technique” is a way of doing something or a practical method applied to some
particular task.
For each identified approach, we are interested in solving the following detailed research questions:

RESEARCH QUESTIONS

RQ0 What approaches exist which allow the requirements elicitation in software
development processes?
RQ1 What sources of requirements are required by the approach?
RQ2 What is the purpose of the approach? What targets are produced by the approach?

RQ3 What knowledge is represented in the approach? How is represented?

RQ4 How the requirements are discovered? What methods, resources and tools are used
by the approach?

In our SLR we followed a two-steps process;

SLR RESULTS
In relation to RQ0. The identified publications were found in the following scientific databases:

In order to establish the evolution of the RE field in the last 25 years, we have defined two periods of
comparison. Fig. 4 presents the number of publications in each of these periods.
RQ2. Purpose and target.

RQ3. Knowledge and representation used. The main forms of knowledge representation used in both
periods are Scenarios and Goal models. In the first period researchers use Scenarios and Goal models in
similar proportions. Otherwise, in the last period there is a wide preference for Goal models over
Scenarios. We also observe that Viewpoint models, Conceptual meta-models and Goal obstacles are
diminishing in their use during the last period.
RQ4. Methods, Considering methods, we have grouped the approaches into categories which extend
those proposed by van Lamsweerde and Wieringa and Daneva. Most used categories in both periods are
Reference-model-based approaches, Goal-based reasoning and Scenario-based elicitation and validation.

Conclusion and Future work

Requirement elicitation is like a backbone. It is initial process and towards creativity and based for
making any software. There is no single technique, which fulfill all the demands of requirement
elicitation and information gathering but it is necessary to keep in mind that success of requirement
elicitation didn’t depend upon number of techniques used but how these techniques are used and how
exact the approach is to meet the stakeholder demands.
It is also concluded from the research that the root cause of each challenge is the maximum human
intervention in this process. Incorporation of latest Artificial Intelligence (AI) techniques may limit such
intervention up to some extent and seems to provide some fruitful results. In relation to the Sources of
requirements used by the proposals, we found that in last period, Stakeholders goals are the most used
input. As to the Knowledge and representation used, we found that Goal models are by far the preferred
form of knowledge, followed by Scenarios, Security goals, Use cases and Ontology. Regarding the
Methods used by the proposals, we observe a significant growth on the use of Goal based reasoning
approaches. We estimate that these methods have been mainly fostered by challenges of trends like
internet, mobility and the need for innovation among others; therefore, they will play an important role
in the future. This work may provide a significant guidance to the RE practitioners for developing a
quality software with less cost and efforts.