Requirement Engineering

2008:PR003
Requirements Engineering:
Elicitation Techniques
Sai Ganesh. Gunda
Source:http://www.marcocioffi.com/archives/2005/04/requirements-engineering/
MASTERS THESIS
Software Engineering, 2008
Department of Technology, Mathematics and Computer Science
MASTERS THESIS
Requirements Engineering: Elicitation Techniques
Abstract
Requirement engineering is the first and crucial phase in the development of software.
The main aim of the requirement engineering process is gathering of requirements. It
involves set of activities like system feasibility study, elicitation analysis, validation and
management of the requirements. There are many methods already exist to perform the
requirement gathering process and the software developers apply them to gather the
requirements but still they are facing so many problems in gathering the requirements
due to the lack of knowledge on result of the methods and selection of appropriate
method. This affects the quality of software and increases the production cost of
software. this paper presents the literature study and the experimental case study on
analyzing and compare different methods for requirement gathering process, this
provides the flexibility to requirements engineers to know the characteristics and the
effectiveness of every method, it is useful to select the particular elicitation method
depends on the type of application and the situation. And this analysis may be useful for
the future development of new methods for requirement elicitation.
Author: Sai Ganesh. Gunda

Examiner: Dr. Steven Kirk
Advisor: Dr. Steven Kirk
Programme: Software Engineering, 2008
Subject: Software Engineering Level: Master
Date: June, 2008 Report Number: 2008:PR003
Keywords Requirement Engineering, Elicitation, Functional Requirements, Non- Functional
Requirements, Questionnaires, Interviews, Requirements Reuse, Prototyping, Social
Analysis, User Centred Design, JAD and Brainstorming.
Publisher: University West, Department of Technology, Mathematics and Computer Science,

S-461 86 Trollhttan, SWEDEN
Phone: + 46 520 22 30 00 Fax: + 46 520 22 32 99 Web: www.hv.se
Acknowledgement
I want to thank Dr. Steven Kirk (supervisor), for his invaluable guidance and
suggestions. I also want to thank my parents, for their support and belief in me. Without
them, I would never be the person, who I am now.
1
Contents
1. Introduction...................................................................................................................................3
2. Background....................................................................................................................................4
2.1 User requirements................................................................................................................5
2.2 System Requirements ..........................................................................................................5
2.2.1 Functional requirements........................................................................................5
2.2.2 Non functional requirements ...............................................................................5
2.3 Requirements engineering ..................................................................................................6
3. Requirements Engineering Process............................................................................................6
3.1 Feasibility study....................................................................................................................8
3.2 Requirements Elicitation and Analysis .............................................................................9
4. Classic Requirements Elicitation techniques ..........................................................................10
4.1 Interviews............................................................................................................................11
4.2 Questionnaire .....................................................................................................................11
4.3 Social analysis .....................................................................................................................12
5. Modern Requirements Elicitation Techniques.......................................................................13
5.1 Prototyping .........................................................................................................................13
5.2 Requirements reuse ...........................................................................................................15
5.3 Scenarios .............................................................................................................................16
5.4 Brainstorming.....................................................................................................................16
5.5 Joint Application Development.......................................................................................17
5.6 User Centered Design .......................................................................................................17
6. Method .........................................................................................................................................18
7. Results ..........................................................................................................................................20
7.1 Experimental Survey .........................................................................................................20
7.2 Literature Review ...............................................................................................................24
8. Discussions ..................................................................................................................................26
8.1 Experimental Survey .........................................................................................................26
8.2 Literature Review ...............................................................................................................26
8.3 Comparison of results from Literature Review and Experimental Survey ...............27
8.4 Margin of Error..................................................................................................................27
9. Future Works...............................................................................................................................28
10. Conclusion.................................................................................................................................28
12. References..................................................................................................................................29
A. Appendix.....................................................................................................................................36
2
1. Introduction
Nowadays the usage of computer applications and software is increasing day by day and
these systems play a vital role in the management of businesses existing today. Most of
the software products developed today is to extend the existing system functionalities.
Due to the todays commercial on the shelf products development [1, 2], the vast range
of fields that uses the computers today, different services are expected by customers,
which make it difficult to develop software that fulfils the expectations of the users.
Since the 1960s the development of computer based systems has faced many problems
[3, 4] that leaded to too many projects being delayed and over budget. The systems that
were delivered also did not meet the requirements, or satisfy the intended purpose
which resulted in the dissatisfaction of the users. The main reason that could be stated
for this problem is difficulties faced in the gathering of requirements [4], as
requirements engineering is the first step in the software development. Whenever the
requirements engineers lack the knowledge of the performance and characteristics of the
different elicitation methods, the activities related to requirements will fail, thus leading
to wrong gathering of requirements that makes the wrong requirements specification
document. The wrong specification document set the improper objectives in product
development phase. The product developed with the wrong specification document
never meets the customers expectations and the intended services. Moreover, the
changes in the requirements in the middle of the project development phase will lead to
delay and increased cost.
There are some famous cases of software failure due to improper use of requirements
elicitation methods. One of such famous case is the Ariane5 Flight 501 (European
Ariane 5 expendable launch System) where the requirements specifications of Ariane4
were reused. But, Ariane5s flight path was much different which could not be handled
by the code developed using Ariane4s requirements specification. This is one of the
examples which show the importance of requirements elicitation and also the
importance of selecting the appropriate elicitation method [57].
Goals This paper describes the different activities involved in requirements engineering
process. The main goal of this paper is to analyze and compare of the different methods
for the requirements elicitation process, which will be useful to find the different
characteristics and the performance of different elicitation methods both in theoretical
and practical approach. Hence the results presented in this paper are acquired using both
literature study and an experimental survey. The survey on the different elicitation
methods that forms the part of the paper is conducted among the experienced people
who are currently using the requirements elicitation methods in the software industry.
Literature review presented in this paper compares the different elicitation methods
according to their characteristics. This papers deals only with the requirements
elicitation part of the requirement engineering process.
The research presented in this thesis commences with the Introduction section, in which
the current problems faced in the process of requirements elicitation and the methods
used to solve it are presented. The work done in this paper may be small and limited,
but it will be useful for the development of new methods in the future.
3
Section 2 includes the background that presents the basic information required to
understand the topic and rest of the paper. This section provides the definitions and the
importance of the requirements engineering process in the software development. It
deals with the different activities involved in the requirements engineering process like
feasibility studies and requirements elicitation and analysis.
Section 3 contains the description of different activities involved in the requirements

engineering process and the inputs and out puts of the requirements engineering
process. Subsections in this, describes the topic of requirements elicitation, which forms
the main topic of this paper. This subsection describes the purpose of the requirements
elicitation in the requirements engineering process and the different activities involved
in the requirements elicitation process with diagrammatic representation.
Section 4 and 5 starts with describing various methods for the requirements elicitation
process, this provides the basic guide lines to perform the different methods of
requirements elicitation. This section is based on the literature study of experts articles
in the field of software engineering and requirements engineering. The articles are
gathered from various sources, each describing different elicitation methods. Section 6
describes the method used to gather the material from the different sources and the
method used for conducting the survey among experienced professional and their
opinion on the elicitation methods and the usage of these methods in the industry level.
Results section provides the result of the research. It describes the comparison of
different elicitation methods based on the experimental survey and the literature review.
This section also includes the discussion of every observed result in detail. Future work
that can be carried on and the conclusion derived from the work are followed by the
results section.
2. Background
DEFINITION
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
behaviour, and to their evolution over time and across software families [5]
There has been many research works already conducted on this topic from 1990, such as
Basher Nuseibehs paper Requirements Engineering Road map[5] and Requirements
Elicitation Techniques: Analyzing the Gap between Technology Availability and
Technology Use by Ann M. Hickey, Alan M. Davis and Denali Kaiser[13]. However,
these papers did not contain an actual analysis of the different methods used in the
Industrial level. This is a vital part to gather the advantages and disadvantages of the
methods in a practical way. In order to fill this gap, a survey is added as the part of this
paper.
4
Requirements specify the services that should be provided by the system, the method in
which they should be provided and constraints in providing these services.
Requirements forms the first phase in the software lifecycle, as given by Somerville
Requirements are the things we should discover early stages of the software
development life cycle. The gathered requirements describe how the system will
behave, system domain, user level facilities and the constraints on which the system
should be operated [4 6]. There are typically 2 main types of these requirements, which
will be described in the following sections.
2.1 User requirements

User requirements describe the expected services from the system, constraints on
achieving them and the way the system provides the requirements [6]. It must be written
in such a way, that it must be understandable by a person without technical experience
and background knowledge. These requirements are generally defined using the
external activities and behaviour of the system and is never defined based on system
design or implementation [6, 7].
2.2 System Requirements

System requirements provide the in-depth knowledge of the user requirements.
System requirements are the basic principles that should be followed to design the
system architecture [6]. The software engineer should analyse these requirements to
know about what exactly has to be implemented and provided in the proposed system
[7]. This is very important and useful to make an agreement or the contract for the
implementation of the system [6]. System requirements are classified in to different
types as follows,
2.2.1 Functional requirements

These are the functions/ services that define [6, 8]
What the system is expected to provide

How the system should respond or react to particular input or situation
What the system should not do
Constraints on implementing the above said requirements.
These requirements mainly depend on the users of the system and the type of software
that is developed [3, 6]
2.2.2 Non functional requirements

These requirements define the effectiveness of the functions provided by the system.
They are not provided by the system, but they affect the functions provided by the
system [8]. Any system that does not provide a reliable service and also security
measures against any threats will be not being considered as a success. These
requirements form the basis of the quality of the system. For example, a Banking
system that satisfies every functional requirement, and does not provide any non
functional requirements is sure to fail. Thus, the failure of the non functional
requirements will lead to the failure of the whole system. Non functional requirements
include [1, 6, 8].
5
Safety and security measures provided by the system

Reliability and efficiency of the system
Portability and integrity of the system
Memory used and cost effectiveness of the system
This also includes budget, scheduling, etc.
2.3 Requirements engineering

Requirements engineering is a branch of system engineering[5]. The work in the
requirements engineering is related to the analysis of the system boundaries and the
system characteristics. The requirements engineering involves requirements elicitation,
documentation and maintenance of the requirements. Requirements engineering is a
repeatable and systematic technique. In each and every phase of the requirements
engineering lifecycle, the requirements are analyzed and evaluated to find the
consistency and completeness of the requirements [4, 9]. The requirements that are
gathered from this process are applicable to whole system and not only for a single
component.
The cost of the requirements engineering depends on the size and the type of the
system that is being developed. For large systems it wills costs 15% of the total budget
only for formal requirement specification, for smaller systems it varies from 8 to 10
percent [4, 5].
There are many problems due to usage of wrong requirements [4, 10]. They are,
1. Delayed and over budget projects.
2. The product does not reach the intended purpose. The customers, who are
actually paying for the system, are not satisfied.
3. The errors encountered in the development of the system, is the reason for the
problems in using the system.
4. The continuous use of such system makes it error prone, and thus increases the
cost of the maintenance.
Rectifying an error resulted by the wrong requirement is much harder than correcting
the errors occurred in the later stages of the project.
Correcting the requirements errors requires the rework on system design,
implementation and testing. The cost of correcting the requirements errors is 100 times
more than the cost of the simple errors occurred in the later stages of the project [4].
3. Requirements Engineering Process

A process is organizing a set of activities; it is a continuous transformation of input to
output activity [2, 4]. Requirements engineering is also an organized and structured
process with the set of activities to transform input to output followed by elicitation,
validation and maintaining the requirements [6, 10]. The activities involved in the
requirement engineering include,
Feasibility study
Requirements elicitation and analysis
6
Requirements validation
Requirements management
Requirements documents.
Unlike the Software engineering process, Requirement engineering is also made up of

different activities that connect, interact and lead one another to form a whole
Requirements engineering lifecycle. This lifecycle is represented in figure 1, and is
followed by an explanation of various activities.
Feasibility Requirements Require

study gathering Validation
Require
specification
Feasibility study
User and system

requirements
System models
Requirements
Document
Figure 1: Requirements engineering process [6].
The detailed background theory of the activities showed in the figure 1 describes
planning and scheduling of the activities, inputs and outputs of the every activity, tools
used to perform each activity.
The performance of the activities depends mostly on the people who are involved in the
requirements engineering process; they will decide the major issues like where and
when to perform the activities. The requirements engineers will decide the usage of the
different available resources depending on the situation and the necessity [6].
The requirements engineering process is an input and output activity [4], it mainly
depends upon the four things to perform the requirements process, which are known as
the inputs of the requirements engineering process. They are [4],
1. Existing system document

2. user and stake holders requirements
3. organization and business procedures
4. Domain Knowledge.
The outputs for the Requirements engineering process are,
1. Final requirements
2. Specification of system
3. System models
7
Diagrammatic representation of Inputs and outputs of a requirements engineering

process
Existing
system
document
Final
Stake holders requirements
requirements
Requirements
engineering
process Specification
of system
Business and
organisation
procedures
System models
Domain
knowledge
Figure 2: Inputs and Outputs of a Requirements engineering process [4].
3.1 Feasibility study

The first step in the Requirement engineering process is the feasibility study. The
Feasibility study is based mainly on the necessity of the proposed system in the
organization and the domain information of the system. The result of the feasibility
study provides us with the report of the worthiness of the proposed system. It also
recommends whether the proposed system should be developed or not, and whether the
requirements engineering process should be initiated for the proposed system [6, 11].
This feasibility study helps the requirements engineers to answer the questions like[6],
Does the overall objectives of the organisation is satisfied by the system?

Can the system be developed within the proposed budget and timeline?
Can the proposed system made to co-exist with the existing systems?
In the problems specified above, the first one is most critical, as it answers the problem
whether the system satisfies the intended objective or not. Unless the system answers
this problem positively, there is no use in developing the system. Any organization that
desires to develop the systems should have the clear arguments and statements on their
objectives.
This feasibility study involves set of activities such as information gathering,
assessment and the report of the information [6]. The assessment activity is used to find
the different solutions for the problems faced in the feasibility study process. Once the
solution is acquired, the questions can be answered from the source of information. The
sample questions that arise in this cyclic process are [6],
1. The reaction of the organisation if the proposed system is not implemented.
8
2. Can the existing system integrated with the proposed system to solve the
problems.
3. The level of problems that has to be solved by the proposed system.
4. Can the proposed system be developed and used with the existing technology or
newer technology is needed?
5. What exactly the proposed systems should support and not be support?
The main source for the feasibility study activity includes the total management
department, technical professional, experts judgement and the people who are familiar
with the usage and type of the system. The required information in this activity is
gathered from analyzing the different types of user expectations on the new system. The
gathered information is used for the preparation of the feasibility report. This report is
basis for the critical decision regarding the changes in system development decisions,
schedule, and budget. The feasibility study report some times affects and changes the
overall objective of the organization.
3.2 Requirements Elicitation and Analysis

Requirements elicitation is the process of gathering the requirements. In this process the
technical professional in the organization, like software developers and the system
engineers, work together with the users of the system and the customers [12]. This
process is useful in finding the problems that has to be solved. The problems include,
1. What the proposed system should provide?

2. What are the expected services form the system?
3. What are the required characteristics of the system?
4. What are the required hardware and software constraints of the system?
Requirements elicitation process includes a chain of processes that interact with each
other to produce requirements documentation. The lifecycle of the requirements
elicitation process is represented in figure 3 and the steps involved are explained [6]
Diagrammatic Representation of Requirements elicitation process
Requiremen
Requiremen ts
ts c heck
Background Requiremen
Knowledge ts priority
Requirements
documents
Gathering Conflict
requirement resolution
Requiremen
ts classify
Figure 3: Requirements elicitation process [6]
9
Back ground Knowledge

The analyst must understand the back ground and the domain knowledge of the
application that is being developed.
Example: If the system is developed for ATM, the developer should have some basic
knowledge of how the ATM works.
Gathering the requirements

This is the activity of discovering the requirements by involving with the stakeholders
and users.
Requirements classification
This activity includes the organizing of the requirements gathered from different
sources.
Requirements conflict
This activity involves with the stakeholders and requirements engineers. This is used to
solve the problems in the requirements that contradict the organization and business
rules.
Requirements Prioritization
Discovering the important requirements by interacting with the stake holders and
organize them in to most priority order.
Requirements check
This activity involves checking the stake holders expectations on the system with the
gathered requirements.
Requirements elicitation process not only helps the organization to gather the
requirements, but also it analyses the requirements and the business procedures of the
organization. The requirements elicitation and analysis is a difficult activity in the
requirements engineering, due to the following reasons [6].
1. Lack of technical knowledge and unawareness of the technical aspects of the

system from the stake holders side.
2. Some times they may demand unrealistic things and they do not know what they
exactly expecting form the system.
3. Stakeholders express their requirements in the most general terms; it is difficult
to find the technical aspects of the system form the general terms.
4. Different people expect different services form the proposed system,
requirements engineers has to discover the good sources of requirements and
commonalities.
5. Business procedures, political influences and the budget matters where the clear
analysis is required.
4. Classic Requirements Elicitation techniques

These requirements elicitation techniques have been used for a long time. These are
tested and proven methods. The different classic requirements elicitation processes are,
10
4.1 Interviews
Interviews are the commonly used and most popular method for requirements elicitation
[4, 18]. In this method the analyst and the engineers of the requirements engineering
process discuss with the different types of stake holders to understand the requirements
of the system and the objective they have to fulfil in the system [16, 17]. There are
typically 2 main types of interviews, which will be described in the following sections
[4, 16, 52].
1. Closed Interview: In this interview the requirements engineer prepare some

predefined questions and he tries to get the answers for these questions from the
stake holders.
2. Open interview: In this interview the requirements engineer does not prepare
any predefined questions, and he tries to get the information from the
stakeholders in open discussions. He mostly concentrates on finding the stake
holders expectations on the system.
Generally the interviews start with the predefined questions [4]. However, in the
process of the interview, a lot of different considerable things may arise, that leads to
open discussion. Interviews are effective for understating the problems in the existing
system and to find the general requirements of the stakeholders. But, it is difficult to
decide the boundaries of the proposed system and the organization procedures using this
method. To make the effective interview the requirement engineer and the stake holders
has to perform in the following ways [4, 16, 17].
1. Interviewer should be patient enough to listen to the stake holders views and the
requirements. He should be open-minded.
2. Stake holders should be expressive in the interview; they should express their views
in definite context.
4.2 Questionnaire
Questionnaires are one of the methods of gathering requirements in less cost [26].
Questionnaires reach a large number of people, not only in less time but also in a lesser
cost. But the results extracted from the questionnaires should be clearly analysed. The
result from the questionnaires mainly depends on the two factors [20, 23, 24],
1. Effectiveness and the design of the questionnaire

2. Honesty of the respondent.
A well designed and effective questionnaire can be used to decide the actual user
requirements, objectives and the constraints [22]. A good structured questionnaire
influences people to answer honestly thus making it possible to gather reliable
results from a large group of people. The data collected through questionnaires can
be used to analyze the obtained results, both systematically and quantitatively [26].
The designing of questionnaire is a multi stage process and should be viewed
accordingly.
11
The steps involved in designing and administering a questionnaire are [22, 26],
1. The purpose of the survey should be defined

2. The sampling group (respondents to the survey) should be decided
3. Preparing and developing the Questionnaire
4. Conducting the Questionnaire process
5. Gathering and analysing the results
Steps in arranging a questionnaire [25]
The questions should be arranged well, so that general questions are followed by
particular questions.
Arrange the questions such that, easy questions comes first.
Arrange the questions in a order of known to unknown
Try to use closed format questions in the beginning.
The questions relevant to the main subject should be given high priority and
stated at the start of the questionnaire.
Avoid personal and intimate questions at the beginning
The general factors which affect the usage of the questionnaire are [24, 25, 26]
1. The available resources to gather the requirements: The usage off the
questionnaire mainly depends on the available resources. When the resources
and the funds are less, the questionnaire is the best method to gather the
requirements because the cost of the administrational is very less. The
questionnaire can also be used to save the time by gathering the requirements
from a large number of people in a very short interval.
2. Type of Requirements that has to be gathering: The type of the information
that has to be gathered depends on the level of the respondents knowledge and
background.
3. Anonymity provided to the respondent: These are the general factors to use
the questionnaire but there is no particular rule as and when to use the
questionnaire for gathering requirements.
4.3 Social analysis

Social analysis is also known as Observation. Observation is the method of collecting
requirements by observing the people doing their normal work. This method is
generally used to find the additional requirements needed by the user, when the user is
unable to explain their expected requirements from the new product and problems with
the existing product.
This social analysis is of four types [33, 34]. They are,
Passive observations- This social analysis is carried out without direct involvement of
the observer in the society. The observation of the peoples work is carried out by
recording using videotapes, video cameras and surveillance cameras. The
12
documentation of the problems and the requirements are prepared from the recorded
data.
Active observation- This observation is carried out with the direct involvement of the
observer. The people are provided with the new product prototype or existing product to
perform the operations on the product. The observer provides the domain knowledge to
the user to work with the product and he makes the report of the requirements of the
people by observing their work with the product.
Explanatory Observations- In this type of observation, the users talk loudly,

explaining what they are doing, while using the product. The observer takes notes using
the explanation given by the user.
Ethnography [4,33,58] - In this method the observer is completely immersed in the

society. The observer goes through in depth observation of the society and their works.
There is no particular formula to carry out this method but it is time consuming and
expensive method to gather the requirements.
5. Modern Requirements Elicitation Techniques

There are different types of modern elicitation techniques, which will be described in
the following section.
5.1 Prototyping
Prototype is the representations or visualizations of the actual system parts [2, 4, 27].
The prototype is designed in the early stages of the implementation of the project. It
provides the General idea of the actual system functions and the work flow. Prototyping
is used to gather the requirements from the users by presenting GUI based system
functions [28].
The main aim of Requirements Elicitation is to gather the requirements before the
product is developed. But it is difficult to discover the additional requirements until it
comes in to usage or some body is actually using it [1, 4, 28]. The process of gathering
the requirements from the stakeholders and the end users is limited and it is difficult to
discover their expectations and the requirements on the new product with out providing
some model that resembles the appearance of the real product.
A prototype represents the actual product in both functional and graphical sense [6, 29].
It provides the flexibility to the users and the stake holders to work with the initial
version of the product to understand the system and discuss them to think of the
additional and missed requirements. Prototyping is a most expensive than the all other
methods of requirements elicitation [30].
13
Diagrammatic representation of the Prototype lifecycle model
Figure 4: Prototype life cycle model source [3].
Prototypes are generally developed in the early stages of the actual product development
process. The software developers use these prototypes in the situations like,
1. When the users are unable to express their requirements.

2. If it is a new product and the users have no experience with this product.
3. When ever the requirements analysis and feasibility studies is difficult.
These prototypes are typically of two types. They are [1, 4, 31, 32],
1. Throw-away prototypes: This type of prototype is not reusable and hence is

discarded when ever the requirements elicitation process is complete.
2. Evolutionary prototypes: This type of prototypes is reusable. They are evolved
or improved according to the feedback and is given as the original product.
Advantages of Prototyping
Reduces time of development.
Reduces cost of development.
The users provided with a visual representation, thus facilitating system
implementation.
Provides high level of user satisfaction.
The ways in which the system can be enhanced in future is known.
Disadvantages of Prototyping
The users may expect the finished product to be the same as the prototype
Developers may be tempted to stop with the prototype.
Can lead to unfinished system implementation.
14
5.2 Requirements reuse

In the field of software engineering reusing the requirements of the existing system is
common method of requirements elicitation [2,4,33, 34]. Using the existing Knowledge
to develop the new product has many advantages that include low cost and less time.
Though each product has their own type of stake holders and users, there is still number
of situations that the reusing of the requirements takes place [4, 35].
Example,
1. User interface designs of the application domain information
2. Different companies database and security policies.
Nowadays in software industries the more than half of the requirements for the new
project requirements are acquired from the existing projects [2, 6, 36]. Although there is
need to check the requirements before they are used in the proposed product, the reused
requirements are already validated and analysed thus reducing the time of testing.
Successful reuse starts with the having an organizational culture that consciously
encourage reuse rather than reinvention [2].
The various questions that help us to find the reusable requirements are [36],
What are the problems in the existing product?

What the proposed product should provide to over come the difficulties in the
existing product?
Who are the users and the stakeholders of the existing and proposed products?
It is difficult to say that particular proposed product is completely different from the
existing product, because it is easy to find reused requirements in any project
requirement specification [2]
Diagrammatic representation of Reusable requirements:
co Reusable
nte requirem
Recognize
which
existing
Requirements
Figure 5: Reusable Requirements [2]
Stake holders will provide the related documents and the existing system documents to
find the reusable requirements [1]. Some times the documents of the existing product
questionnaire are also helpful in finding the source of reusable requirements. Finding
15
and using the reusable requirements for the projects is the best way of requirements
elicitation [6, 36, 37].
5.3 Scenarios
The scenarios of the particular system will give the working method of different
interaction sessions or the situations of the system [38, 39]. These scenarios are helpful
for requirements elicitation in two ways. They are [40].
1. Analyzing the different sessions of the system gives the flexibility to find the
requirements
2. The user response after interaction with the scenarios will give the flexibility to
find the requirements.
Scenarios are generally used after the initial requirements specification is finished [4,41,
42]. The scenarios are produced by the developers when the initial requirements are
collected and the basic idea about the functions to be provided by the system is
prepared. The developed scenarios will be used to find and prepare the detailed
requirements specification.
The method to prepare the scenario is as follows [4, 43, 44]
1. Scenario should start with the particular state called the starting point
2. Every state should be connected with the next state.
3. Every state should contain the Normal, exceptional and alternative flow of
events.
4. Every state should describe the actions performed on that state.
5. The interaction should be ended with the final state.
Generally the software industries use the text based and picture based scenarios [2, 4].
The developer provides the scenario model for the system. The user and the
requirements engineer work with the scenarios of the proposed system. The
requirements engineer takes the notes of the user comments, suggestions and difficulties
that user faced when interacting with the scenario. Scenarios of the proposed system are
always prepared with the involvement of the stake holders to clarify what they require
in each interaction. Use cases developed for the system are the basic guidelines for the
scenario models.
5.4 Brainstorming
Brainstorming is a techniques used to generate new ideas and find the solution to a
specific issue [2, 39, 45,58]. This is conducted as a conference with six to ten members.
The members are from the different departments and domain experts are also included.
This conference is headed by the organizer, who states the issue to be discussed. The
conference is generally held in a round table fashion. Every member person is allotted
with certain time interval to explain their ideas. Notepads are provided to all members
to write their ideas and suggestions. The team of brainstorming will then decide the best
idea by voting from the group and that idea is selected as the solution to the issue
discussed in the conference.
16
Brainstorming can be used to answer the following questions [45,58],
What exactly the system should provide

What are the business and organization rules required to follow
What type of questions should be there in the interviews and questionnaires?
What are the risk factors effect the proposed system development and what to do
avoid that?
5.5 Joint Application Development

It is an organized and structured technique for requirements elicitation [46]. This is
conducted in the same manner as brainstorming, except that the stakeholders and the
users are also allowed to participate and discuss on the design of the proposed system.
The participant in these sessions does not exceed 20 to 30 [46].
The requirements engineers start the session by providing the general overview of the
system. The discussion with the stakeholders and the users continues until the final
requirements are gathered. This leads to elicitation of better requirements in the first
attempt and it reduces the time spent on the requirements phase [46].
The success of the JAD depends on [47,58]
1. leader of the JAD session

2. Developers, end-users and the stakeholders of the product.
3. Group involvement.
5.6 User Centered Design

This method is similar to Joint Application Development. The one difference is that the
user acts as the part of the development team. The user takes active part in the designing
and development of the system [48,58]. The user provides his ideas and contributes his
suggestions as a member of the development team. The activities involved in user
centered design shown in figure 6.
Diagrammatic Representation of User Centered Design Activities
Figure 6: Activities Involved in user centred design [59]
17
Advantages of User Centred Design [49,58]
The user is closely involved with the development

The user feedback can be obtained immediately
Reduces time and cost spent on gathering user feedback.
6. Method
There are various articles and papers present on the topic of Requirements Engineering.
Some of them are presented using Literature review and others using various practical
means. There are also papers on requirements engineering for specific applications.
However, very few are the papers that present these two perspectives together [51-56].
The main constraints that were considered for choosing the methods for this thesis work
were time, cost and reliability. Literature review, as it is gathered from reliable sources,
proved to be much reliable and cost free. Though much time was spent on collecting the
sources, it proved to be an effective method. On the other hand, the practical method has
to be as reliable as Literature review. Interview would have been the best method if not
for the time and cost constraints. It is not possible to meet many experts in the available
time. Questionnaires require much less time than Interview as it could be distributed at
the same time to may respondents. However, care was taken in choosing the
respondents in order to achieve the reliability. The methods used to conduct the survey
are explained later. The other reasons that these methods were chosen are,
Literature review is one of the methods that are very effective to read and
analyze various papers, articles and books presented on the topic.
To have a deeper understanding of the topic, one must be aware of as many
different views and opinions of the experts. Literature review is a best method to
achieve this.
On any aspect of engineering, theoretical knowledge alone is not helpful when it
comes to real world applications. It is important to have practical knowledge. It
is on this basis that Experimental survey was chosen as one of the perspectives
for this paper.
It is always a best approach to compare the practical and theoretical results so as
to have a more reliable result. Hence, Literature review and Survey was selected.
Literature review
A properly written literature review filters the necessary information from the sources
that is analysed. The literature review in this paper mainly focuses on the materials
gathered from different books and the articles published in the IEEE, ACM and
SCIRUS by different experts in the field of requirements engineering and the software
development. The literature review for this thesis work was conducted using
information gathered from ten books and approximately thirty to forty papers.
18
The appropriate keywords to filter the papers in IEEE and ACM libraries were obtained
by using random keywords in the GOOGLE AND YAHOO search pages. These
keywords were then used in the various libraries to get the most appropriate papers on
the topic. Once the papers were found, the following parameters were used to select the
papers for thesis. They are,
Reliability In general, papers presented in IEEE and ACM are reliable. However,
papers presented by professors and lecturers were given higher priority. The articles that
were selected were also mainly written by professors. In the case of the Books, the book
used for the course literature was selected. Other books used in this thesis are selected
based on their relevance and expertise on the topic.
Timeline Requirements engineering is a new field when compared with other

software engineering processes. But it also follows some basic principles of software
engineering. The papers were chosen such that, they contain most advanced information
on the topic. The papers referenced in the thesis are mostly recent papers, which were
presented when the requirements engineering started to shape up. However, to explain
basic principles some old and much reliable papers were selected.
Reputation The papers used in this thesis were also selected based on their
reputation. Most of the papers presented in this thesis are cited many times by reliable
authors. Goggle Scholar was used for this purpose. References were also gathered by
studying the references used in the selected papers.
The results gathered from the literature review were then tabulated. And according to
the authors view on the advantages and disadvantages of the various methods, they were
tabulated based on their usability for a particular type of application (sample table1) or
based on their cost and time usage. This table was later used to calculate the percentage
and the results were plotted as a graph (Figure 13 and Figure 14)
Experiment
This paper does not contain only the theoretical methods of gathering requirements. But
also, a practical approach is used in order to experience the problems that are faced in
the real world. A real survey is conducted among the professionals working in
requirements and software development field. The survey consists of questions aimed at
gathering the way the professionals feels about various requirements techniques, and the
problems they face in using them in the industrial level. The results gathered from the
survey is analysed and discussed. It is also compared with the outcome of literature
review, so as to find out the gap between the theoretical and practical usage of the
requirements elicitation techniques.
The main parameters that were used for the Survey are as follows,
Sample Size The number of total respondents is an important factor to achieve a

reliable result. Hundred respondents would have been much more reliable, but for the
time constraint. So a more appropriate size of 35 was chosen.
19
Reliability since this survey is about Requirements engineering elicitation, the

respondents must be aware of the process and should have at least basic knowledge
about the process. So the respondents were chosen from the software field and also from
management group of software companies. Years of experience and the educational
background was also considered.
Designing of the questionnaire The questionnaire was designed after a thorough

study of the effective designing of a questionnaire [21-26]. In brief, the questionnaire
that was designed had a consistent flow. General information and questions formed the
first section of the questionnaire, while, the in depth questions about the topic formed
the second section. Moreover, apart from the personal opinions of the respondents, the
methods used in their respective companies were also collected. While most of the
questions were multiple choice questions, some questions were also of grading type.
Conducting the survey since the survey was conducted among the professionals
mostly from Seven Indian multinational companies, E-Mail was used for distribution of
the questionnaire. The respondents, after filling out the questionnaire, returned the
results via E-Mail.
Analysis of the results The results collected from the respondents, were then
tabulated. The percentage was then calculated based on various parameters. In order to
provide the reader with a visual representation for easy understanding, the tabulated
data was plotted in a Graph (Figure 7 to Figure 12)
7. Results
In this section, the results gathered from Literature Review and Experimental Survey is
listed down. Graphs are used for visual representation and easy understanding.
7.1 Experimental Survey

The survey was conducted among thirty five professionals working in Seven Indian
software concerns. The participants were from different educational background, years
of experience and the field they currently work. From the thirty five participants, twenty
five answered to the questions, while ten had not responded. The respondents were
selected from seven different Indian companies. The results are as follows,
20
Educational Background
This graph shows the number of respondents according to their educational background.
It was important to plot this as this shows that the survey was conducted among
members from different educational backgrounds (based on university degree), thus
eliminating the possibility of the survey being conducted among a same group, for
example say software developers.
12
10 Computer Science
8 Information
Technology
6
Business
4 Administration
Others (Electrical,
2 Electronics, etc.,)
0
Figure 7: Respondents - according to the educational background
Years of Experience
In this graph, the respondents are divided by their years of experience in their relative
field. This was an important aspect as later it proved that, respondents with higher
experience believed that requirements engineering were an important phase in software
development.
14
12
10
8
6
4
2
0
1-3 Years 3-5 years More Than 5
years
Figure 8: Respondents according to the years of experience
Are Requirements very important for development?

The respondents were asked to express their views on the importance of requirements
engineering. It was interesting to find that respondents with more experience thought
that the requirements engineering was an important aspect, whereas the fresher in the
field had very little idea about the process. This is shown in Figure 12.
21
12
10
0
Yes No I do not know
Figure 8: Importance of Requirements
Effectiveness of the method

To calculate the effectiveness of the method, question no 11 was used. The respondents
who believed that the requirements engineering was an important process (Figure 9)
answered this question. Then a table was drawn with each method listed. For each
respondent selecting the method, the particular method was incremented by one. Then,
this sum was divided by the number of total respondents for this question and the
percentage was calculated. The results are plotted in the graph below.
100
90
80
70
60
in percentage
50
40
30
20
10
0
JAD
UC
Bra
Sce
Pro
Qu
Inte
Re
So
cia
use
est
D
in s
toty
rvie
nar
l
ion
d
An
torm
ios
pin
ws
Re
nai
aly
qui
ing
res
sis
rem
ent
s
Figure 10: Effectiveness of method used for Requirements Elicitation
Method Popularity in Industrial Usage

While Figure 10 shows the view of the respondents on the effectiveness of the different
methods, this graph shows the method used in their respective companies. To get this
22
result, the same method used for Figure 9 was used. However, in this, all the
respondents (25) were asked to tick the methods used in their respective companies.
Then the same type of table used for Figure 10 was used. And each method was
incremented by one according to the selection of the respondent. Then this sum was
divided by the total number of respondents and the percentage was calculated. This is
plotted in Figure 10. From the comparison of figure 10 and 11, it is clear that, reusing
requirements is popular both among the respondents and also in companies.
100
90
80
70
in percentage
60
50
40
30
20
10
0
J AD
UC
Re
So
Pr o
Qu
Bra
Sc
Inte
c ia
us e
ena
est
D
toty
i
r v ie
ns
l An
i on
d
rios
pin
tor
ws
Re
nai
a ly
mi
g
qui
re s
ng
sis
re
me
nts
Figure 11: Popularly used requirements elicitation method in industries
Comparison of the Years of Experience and the Importance of Requirements

This is a combined graph of the respondents years of experience (Figure 8) and their
view on the importance of requirements (Figure 9). It clearly showed that the higher the
experience, the more the importance for requirements engineering.
8
6 High Experience
Medium Experience
4 Low Experience
2
0
Yes No I do not
know
Figure 12: Comparison of years of Experience and importance of requirements
23
7.2 Literature Review

In this section, the result that has been formed using the literature review of various
journals and papers has been presented. These sources were read, understood, analysed
and results were collected. Based on the gathered results, the effective method for the
type of application developed and effective method on the basis of cost and time
requirements were calculated. This result is compared and analysed with the result
found by experimental survey in the Discussion sections.
In order to represent the collected information, the method of grading each requirements
elicitation process in a numerical of zero to ten according to the authors opinion on the
pros and cons of the method was discussed and the data was collected accordingly.
However, this was a difficult method and there was question of reliability on the grade
allotted. So, to overcome this, a new method was formed using the available data on the
authors views on the usability of the requirements elicitation processes. In this method,
each process and type of applications was tabulated and the process was incremented
with a one if the author expressed a positive view that the particular method can be used
for the particular type of application(see sample table 1). Then using this data,
percentage was calculated and plotted (Figure 13).
Methods Applications General Industrial Specific Scientific Complex

Applications Applications Applications
Interviews 1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1
Questionnaires 1+1+1+1+1+1+1+1 1+1+1+1+1+1 1+1+1+1
Social Analysis 1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1+1
Prototyping 1+1+1+1+1+1 1+1+1+1 1+1+1+1+1+1+1
Scenario 1+1+1+1+1+1 1+1+1+1+1 1+1+1+1+1+1+1
Brain Storming 1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1
JAD 1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1+1
UCD 1+1+1+1+1 1+1+1+1+1+1+1+1 1+1+1+1
Reused Requirements 1+1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1
Table 1 sample table of the method used to calculate the usability of the method for
the particular type of applications.
The other parameter that was used was cost and time required by each method. To
gather these results, the same method used for Figure 13 was used, except that this time
the authors view on the cost and time required by the methods were tabulated. If the
method required much time it was incremented by 1. The same was done for cost also.
Then the percentage was calculated. The lower the percentage, the lesser the cost and
time required by the method, thus making it a most effective method, when cost and
time is considered. The results were then plotted in Figure 14.
24
100
90
80
70
In Percentage
60
50
40
30
20
10
0
sis
s
ts
s
D
g
s
re
io
w
in
in
JA
UC
en
ly
ie
ar
m
ai
yp
na
m
rv
nn
en
or
ot
re
te
lA
st
tio
Sc
ot
ui
In
n
cia
Pr
es
eq
ai
So
Qu
Br
R
ed
us
General Applications Industrial Specific Applicatons Scientific Applications
Re
Figure 13: Method effectiveness according to the type of application
100
90
80
70
In Percentage
60
50
40
30
20
10
0
s
D
g
s
g
s is
ts
ire
w
io
n
in
JA
UC
en
pi
ly
e
ar
m
na
vi
na
m
en
or
ot
er
re
lA
st
Sc
io
ot
t
ui
In
n
t
ia
Pr
es
eq
ai
c
So
Qu
Br
R
ed
us
Cost Time
Re
Figure 14: Cost and Time requirement of requirements elicitation methods
25
8. Discussions
8.1 Experimental Survey

In the survey conducted, there were very interesting results to be observed. They are,
Experience Matters
If you ask an inexperienced developer he would probably say that an application can be
developed just with the knowledge of the developer, where as a seasoned programmer
would be more concerned about the various parameters that affects the quality of the
software. This was proved by the survey (Figure 12). People with higher experience
believed that requirements gathering are a much important task in software development
lifecycle.
Effectiveness of the method

Interviews, Questionnaires and Reusing were voted by most respondents to be the most
effective methods (Figure 10). It is also interesting to note that all these methods require
less interaction of the developers directly with the users.
Popularity of the method in Industries

The industries were more concerned with the cost effectiveness of the method.
Prototyping is one of the methods in which the developed model can be further evolved
and presented as the final system, thus eliminating extra cost and time. And also, it is
one of the methods that actually represents the system as a working model and could be
easily understood by the user. Hence Prototyping was one of the methods highly
popular in industries. Apart from prototyping, Reusing, Questionnaires and Brain
storming were also the mostly used methods in the Industries (Figure 11)
The other results that were drawn are as follows,
People from Management Background had a slight more priority for cost than
the effectiveness, whereas people with software background had much priority
for effectiveness (Figure 11 and Figure 7)
Respondents generally voted for methods that requires less interaction possible
(Figure 10)
Questionnaire was one of the methods that were voted by most number of
respondents as the most effective method. (Figure 10)
8.2 Literature Review

The results from the literature review were found to be more or less similar to the
conducted survey, except on some points. The results are,
Cost and Time effectiveness

From Figure 14, it is clear that Questionnaires and Reusing Requirements was the
method with less time and cost. The other result that can be drawn from this is that, the
methods that had user involvement was found to take more time and cost (Figure 14)
26
The other results that were found were,

Social Analysis and Prototyping are the methods that had an average score, for
all the types of applications (figure 13).That is, they were found to be the
methods that can be effective for all type of applications.
From Figure 13 it is clear that JAD and Prototyping are found to be good for
complex systems.
8.3 Comparison of results from Literature Review and Experimental

Survey
In this section, we give the compare the results obtained from the two methods. They
are,
Questionnaires and Requirements Reusing were found to be the popular and less
time taking methods in both literature review and the survey (Figure 10, Figure
11and Figure 14).
Developers tend to avoid interaction and direct involvement with user, and it
was found to be more costly too (Figure 10 and Figure 14 )
Though prototyping was one of the methods that required high time and cost, it
was found to be one of the popular methods used in industries (Figure 11and
Figure 14)
Questionnaires was popular, but it was generally agreed that the reliability of the
method greatly depend on the respondents and the type of group the
questionnaire is conducted and hence is more advantageous for general
applications(Figure 10, Figure 13 and Figure 14)
Social analysis is effective but it requires high budget and timeline (Figure 10,
Figure 13and Figure 14)
8.4 Margin of Error

The margin of error was estimated to be around 5 percent. The group of respondents
were selected in such a way that all the possible groups that might affect the
requirements elicitation method were included. The respondents are from different
educational background, various levels of experience and from different companies.
Respondents are from developers and also from management. However, the reasons for
the margin of error are as follows,
The eighty percent of sample size consists of professionals only from the Indian
companies
The result documented here includes people from management also, which
might affect the priority for the technical excellence when discussing the
appropriate method of requirement elicitation.
The survey is conducted via E-Mail, so some doubts of the respondents might be
left unanswered, thus affecting the survey.
The respondents are from only seven companies.
27
9. Future Works
The thesis work can be further extended by using different methods other than
questionnaire. Also, the number of respondents can be increased to reduce the margin of
error and to increase the quality of the result.
10. Conclusion
In this paper, the different Requirements elicitation methods are studied, compared and
discussed using Literature Review and Experimental Survey. The results gathered were
analysed using various parameters and is found to be interesting. Though there are
various requirements elicitation methods, only some of the methods were found to be
popular among both the developers and management people (Figure 10, 11 and Figure
14). Every method has its own strength, but, the selection of the method is mostly
dependent on the type of the application being developed. While JAD is effective for
scientific applications as it includes experts from the specific field, questionnaire is
much more effective when it comes to general applications where cost and time
constraints are more (Figure 13 and Figure 14).
The more experienced believed in the importance of Requirements Engineering, while
the less experienced had very little knowledge about the process (Figure 12). This
happens due to the practical knowledge and problems faced during the development
process. The more experienced people were aware of the problems and faults that will
occur when the proper requirements documentation is unavailable. It also depends on
the organisational rules and the development team.
The survey was mostly conducted among Indian multi national companies. It was found
that the much established companies followed traditional methods of requirements
elicitation, whereas new companies were much open to try new methods. The
established companies were much more concerned about the effectiveness of the
process even if it costs more. But for the new companies, cost was an important
constraint that leads them to try out new methods that showed more result in less time
and cost possible.
This main aim of this paper was to compare the pros and cons of various methods of
requirements elicitation using Literature Review and Experimental survey. Apart from
achieving this, this paper has also succeeded in identifying the opinion of the
professionals in the field and along with the popularity of the methods in the companies.
The paper also opens path for further study on the topic by considering various other
conditions and parameters that might affect the requirements elicitation process.
28
12. References
1. Christ of Ebert: Practical Requirements engineering solutions, University of
twente, IEEE publications, volume 21, issue 2, April 2004, pages: 16-18
http://csdl.computer.org/comp/mags/so/2004/02/s2016.pdf
2. Suzanne Robertson, James Robertson: Mastering the requirements process.

Addison Wesley, 1998.
3. Merlin Dorfman: Requirements engineering. Carnegie Mellon University,

interactive publishers, 1999
http://www.sei.cmu.edu/news-at-sei/features/1999/mar/Background.mar99.pdf
4. Kotonya and Ian Somerville: Requirements engineering process and techniques.

Edition Willey, 8th Edition
5. Bashar Nuseibeh, Steve Easterbrook: Requirements engineering: A road map,

ACM publications, Sep 2000, pages 35-46.
http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf
6. Somerville: Software engineering. 8th edition, Addison Wesley
7. Neil maiden: User requirements and system requirements. City university of

London, IEEE publications, volume 25, issue 2, April 2008, pages 90-91.
http://ieeexplore.ieee.org/iel5/52/4455615/04455639.pdf?tp=&arnumber=4455639&isn
umber=4455615
8. Ruth Malan, Dana Bred Meyer: Functional Requirements and Use Cases. Hewlett-
Packard Company, 2000.
www.digilife.be/quickreferences/PT/Functional%20Requirements%20and%20Use%20
Cases.pdf
9. Pie Hsia, Alan m Davis, David C.kung: Status Report in requirement

Engineering.IEEE publications, vol 10, issue 6, Nov 1993, pages 7-79.
http://ieeexplore.ieee.org/iel1/52/6217/00241974.pdf?tp=&arnumber=241974&isnumbe
r=6217
10. Betty h.C cheng, Joanne M.atlee: Research directions in

requirementsEngineering.IEEE publications, pages 285-303, 2007, ISBN 0-7695-
2829-5
http://delivery.acm.org/10.1145/1260000/1254725/28290285.pdf?key1=1254725&key2
=2821250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420
29
11. Nakajo, T. & Kume, H. (1991): A Case History Analysis of Software Error Cause-
Effect Relationships. Transactions on Software Engineering. Vol 17, issue 8, 1991,
pages 830-838
12.Seda Gursesa, Jens H. Jahnkeb, Christina Obryb, Adeniyi Onabajob,Thomas

Sentence, Morgan Price eliciting confidentiality requirements in practice.IEEE
publications, page 101-116,2005.
http://delivery.acm.org/10.1145/1110000/1105642/p101-
gurses.pdf?key1=1105642&key2=1460250121&coll=ACM&dl=ACM&CFID=675312
24&CFTOKEN=54899420
13. Hickey, AnnM.Davis, AlanM.Kaiser, Denali: Requirements Elicitation

Techniques: Analyzing the Gap between Technology Availability and Technology Use
Comparative Technology Transfer and Society. Muse publications, Volume 1, Number
3, December 2003, pp. 279-302
http://muse.jhu.edu/login?uri=/journals/comparative_technology_transfer_and_society/
v001/1.3hickey.pdf
14. Goguen, J. & Jirotka, M. (Ed.). (1994): Requirements Engineering: Social and
Technical Issues. London: Academic Press.
15. Dardenne, A., Lamsweerde, A. v. & Fickas, S. (1993): Goal-Directed

Requirements Acquisition. Science of Computer Programming, 20:3-50.
16. Hove, S.E.; And, B: Experiences from conducting semi-structured interviews in

empirical software engineering research. Software Metrics, 2005. 11th IEEE
International Symposium, Volume, Issue, 19-22, Sept2005, Page(s):10pp.-Digital
Object Identifier 10.1109/METRICS.2005.24
http://ieeexplore.ieee.org/iel5/10089/32322/01509301.pdf?tp=&arnumber=1509301&is
number=32322
17. Tira Cohene and Steve Easterbrook: Contextual analysis for interview design.
Department of Computer Science, University of Toronto, Toronto Canada, IEEE
publications, 2005, pages 95-104.
http://ieeexplore.ieee.org/iel5/10247/32667/01531031.pdf?tp=&arnumber=1531031&is
number=32667
18. Julio Cesar shampoos do prude liete, ana Paula piano gilvaz: Requirements
Elicitation Driven by Interviews: The Use of Viewpoints. IEEE publications, Page: 85
Year of Publication: 1996.
30
http://delivery.acm.org/10.1145/860000/858259/73610085.pdf?key1=858259&key2=27
08150121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420
19. Amy Voida & Elizabeth D. Mynatt, Thomas Erickson & Wendy A. Kellogg:
Interview over instant messaging. ACM publications, 2004, pages1344-1347.
http://delivery.acm.org/10.1145/990000/986060/p1344voida.pdf?key1=986060&key2=
3618150121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420
20. Dimitrics Plexousakis: User requirements report. Cyclades IST - 2000 25456.
An Open Collaborative Virtual Archive Environment
http://www.ics.forth.gr/isl/projects/cyclades/d1_1.pdf
21.J. Michael Moore, Frank M. Shipman: A Comparison of Questionnaire-Based and

GUI-Based Requirements Gathering. IEEE publications, 2000, pages 35-43.
http://ieeexplore.ieee.org/iel5/7013/18910/00873648.pdf?tp=&arnumber=873648&isnu
mber=18910
22. J.Michael Moore, Frank M. Shipman: A general introduction to the design of

questionnaires for survey research, University of Leeds, online document.
http://www.leeds.ac.uk/iss/documentation/top/top2.pdf
23. Charles F. Manski1 and Francesca Molinari: Skip Sequencing:A Decision Problem
In Questionnaire Design. North-western University and Cornell University, 2008, vol
2, pages 264-285.
http://arxiv.org/PS_cache/arxiv/pdf/0803/0803.3875v1.pdf
24. Stuart Anderson Massimo Felici: Requirements engineering questionnaire.

http://homepages.inf.ed.ac.uk/mfelici/doc/questionnaire.pdf
25. Wai-Ching Leung: how to design a questionnaire. University of East Anglia

http://student.bmj.com/back_issues/0601/education/187.html
26. http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/quest-
design:Questionnaire Design.Online document.
27. Andriole s.j:Fast cheap requirements prototype: or else. Drexel university, IEEE,
vol 11, issue 2, Mar 19994, pages 85-87.
http://ieeexplore.ieee.org/iel1/52/6703/00268964.pdf?tp=&arnumber=268964&isnumbe
r=6703
28. Ian graham: Structured prototyping for requirements specification in expert

systems and conventional IT project.IEEE, vol 2, issue 2, 1991, pages 82-89.
31
http://ieeexplore.ieee.org/iel1/2218/2861/00087760.pdf?tp=&arnumber=87760&isnumb
er=2861
29. Hassan ghoma,Douglas b.h scott: prototyping as a tool in the specification of user
requirements. IEEE, Pages: 333 - 342 Year of Publication: 1981 ISBN:0-89791-146-
6
gomaa.pdf?key1=802546&key2=9030250121&coll=ACM&dl=ACM&CFID=6753122
4&CFTOKEN=54899420
30. St.louis: what is prototyping. University of Missouri, Online document

http://www.umsl.edu/~sauterv/analysis/prototyping/proto.html
31. Davis, A: Operational Prototyping: A New Development Approach.

Software,IEEE,vol 9,issue 5,1992,Page: 70-78.
32. Luqi and W Royce: Status Report: Computer-Aided Prototyping. IEEE

Software,vol 9,issue 6, Nov. 1992, pp. 77-81.
33. Stephen Viler & Ian Sommerville: Social analysis in the requirements engineering
process: From ethnography to method.IEEE, 1999, pages 6-13.
mber=16860
34. Goguen, J. & Linden, C.: Techniques for Requirements Elicitation. 1st IEEE
International Symposium on Requirements Engineering (RE'93), San Diego, USA, 4-
6th January 1993, pp. 152-164.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=324822
35. W. Lam, J.A. McDermid and A.J. Vickers: Ten Steps towards Systematic
Requirements Reuse. IEEE publications, 1997, pages 6-15.
mber=12313
36. N.A.M Maiden: Reuse oriented requirement engineering in nature. ACM

publications, Volume 20, Issue 3 (July 1995), Pages: 90 93, Year of
Publication: 1995, ISSN: 0163-5948.
maiden.pdf?key1=219324&key2=9601250121&coll=ACM&dl=ACM&CFID=6753122
4&CFTOKEN=54899420
32
37. Bretty h.c cheng: Research Directions in Requirements engineering. ACM

publications, Pages 285-303,Year of Publication: 2007.
http://delivery.acm.org/10.1145/1260000/1254725/28290285.pdf?key1=1254725&key2
=2821250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420
38. Alistair Suctliffe:Scenario-Based Requirements Analysis Alistair Sutcliffe Centre

for HCI Design. School of Informatics, City University, London, UK.Springer
London,pages 48-65,2008.
http://www.springerlink.com/content/jw76516n334g8241/fulltext.pdf
39. Shari, Lawrence, pfleeger: Software engineering theory and practices.

International Edition, 1998
40. Alistair Sutcliffe: Scenario-based Requirements Engineering.IEEE, Sep 2003,

pages 320-329.
http://ieeexplore.ieee.org/iel5/8725/27626/01232776.pdf?tp=&arnumber=1232776&isn
umber=27626
41.Julio Cesar Sampaio do Prado Leite a, Gustavo Rossi a, Federico Balaguer b, Vanesa
Maiorana b, Gladys Kaplan b, Graciela Hadad b and Alejandro Oliveros b: Enhancing
a Requirements Baseline with Scenarios.Springer link,vol 2,pages 184-198,2007.
http://www-di.inf.puc-rio.br/~julio/Slct-pub/baseline.pdf
42. Henrik Behrens: Requirements AnalysisUsing Statecharts and Generated

Scenarios. FernUniversitt, Hagen, 2004.
http://www.fernuni-hagen.de/se/PDFs/Re2002Paper.pdf
43. Martin Glinz: Improving the Quality of Requirements with Scenarios. Preceedings
of Second World Congress for Software Quality,sept 2000.
http://www.ifi.uzh.ch/rerg/fileadmin/downloads/publications/papers/2WCSQ.pdf
44.Jarke, M. & Kurki-Suonio, R. (1998). Guest Editorial: Special issue on Scenario

Management. IEEE Transactions on Software Engineering, IEEE, 1998, 24(12).pages
1033-1035.
45. Chauncey e. Wilson: Brainstorming Pitfalls and Best Practices.ACM,vol 13,issue

5,2006.,pages 50-63.
wilson.pdf?key1=1151342&key2=0909760121&coll=ACM&dl=ACM&CFID=675312
24&CFTOKEN=54899420
33
46. Maiden, N. &Rugg, G. (1996).ACRE: Selecting Methods for Requirement

Acquisition.IEEE, Software Engineering Journal, 11(3):183-19247.
47. Yihwa Irene Liou: Integrating Group Support Systems, Joint Application
Development, and Computer-Aided Software Engineering for Requirements
Specification.IEEE, 1993, vol 3, pages 4-12.
Unhttp://ieeexplore.ieee.org/iel2/449/7027/00284291.pdf?tp=&arnumber=284291&isnu
mber=7027
48. Abras, C., Maloney-Krichmar, D., Preece, J. (2004): User-Centered Design. In

Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage
Publications.
http://www.ifsm.umbc.edu/~preece/Papers/Usercentered_design_encyclopedia_chapter.
pdf
49. Karel Vredenburg, Ji-Ye Mao, Paul W. Smith, and Tom Carey: A survey of user
centered design in practice.ACM, 2002, pages 471-478.
http://portal.acm.org/citation.cfm?id=503376.503460&coll=ACM&dl=ACM&CFID=6
8830115&CFTOKEN=60008348
50. Zheying Zhang: Effective Requirements Development - A Comparison of

Requirements Elicitation techniques.SQM publishers, 2007.
www.cs.uta.fi/re/rem.pdf
51. Wesley James Lloyd,Mary Beth Rosson,James D. Arthur: Effectiveness of

Elicitation Techniques in Distributed Requirements Engineering.IEEE,311-318,2002.
http://csdl2.computer.org/comp/proceedings/re/2002/1465/00/14650311.pdf
52. Joseph a gorgen, charlotte linde: Techniques for requirements elicitation.2002.

http://www.cs.brown.edu/courses/cs190/current/documents/restricted/goguen.pdf
53. Ann M. Hickey Alan M. Davis: Requirements Elicitation and Elicitation

Technique Selection: A Model for Two Knowledge-Intensive Software Development
Processes.IEEE,pages 152-164,1993.
http://csdl2.computer.org/comp/proceedings/hicss/2003/1874/03/187430096a.pdf
54. Michael G. ChristelKyo C. Kang: Issues in Requirements Elicitation issues.IEEE,

2003, onpage 10pp-.
September 1992, Technical Report, CMU/SEI-92-TR-012ESC-TR-92-012
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf
55. Michael przybilski: Requirements Elicitation in International Research Projects.

Helsinki Institute for Information Technology (HIIT).
http://www.cs.helsinki.fi/u/przybils/papers/amcis2006.pdf
34
56. Belani, H.; Pripuzic, K.; Kobas: Implementing for web surveys for requirements
elicitation.IEEE,vol 2,pages 465-469,2004.
http://ieeexplore.ieee.org/iel5/9871/31386/01458610.pdf?arnumber=1458610
57. Stephen. Bull: "Component Architecture" in the RISKS-Forum Digest: Forum on

Risks to the Public in Computers And Related Systems, ACM Committee on Computers
and Public Policy, Peter G. Neumann, moderator, (Robinson, RISKS-23.73), 22 Feb
2005
http://catless.ncl.ac.uk/Risks/23.74.html#subj2.10
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
58. Linn Gustafson: Requirements Engineering Verification validation, University

West, Course slides, Feb-2008
59. Manfred Tscheligi, Peter Frhlich, Verena Giller: Draft Guide: First Steps to User
Centred Design.IST support measures IST-1999-29067, version 1.0,2002.
35
A. Appendix
SURVEY QUESTIONNAIRE
Preface
The main aim of this questionnaire is to find the different views on requirements
elicitation practices in the industrial level.
How to fill in the questionnaire: Answer all the questions according to your knowledge,
skills and position within your organization.
Each question has following multiple-choices
N/A: Not Applicable

U: Unknown
VL: Very Low
L : Low
A : Average
H : High
VH : Very High
General Information
Please fill in the following with the relevant information.
Name (optional) :
E- Mail :
Age :
Organization :
Education :
Experience with RE :
Date :
36
Survey on Requirements Elicitation Techniques [21-26]
Mark each of the Questions with N/A or U or VL or L or A or H or VH.
1. Do you like to carry out feasibility study before starting a new project?
2. Do you like to carry requirements elicitation before going to start a project?
3. Do you like to use questionnaires for requirements elicitation?
4. Do you use prototype to elicit requirements?
5. Do you use scenarios or use cases to elicit requirements?
6. Do you use interviews to elicit requirements?
7. Do you reuse requirements from other existing systems?
8. Do you use the questionnaires for requirements elicitation?
9. Do you conduct the interviews to gather the requirements?
10. Do you conduct the observations while interviews?
11. Tick the methods which are effective for Requirement (your personal opinion,
multiple selections allowed. Use * to indicate your selection)?
a. Interviews ( )
b. Questionnaires ( )
c. Observations ( )
d. Social analysis ( )
e. Prototype ( )
f. Scenario ( )
g. Brain Storming ( )
h. JAD ( )
i. User centered design ( )
12. Tick the popular methods which are used in your companies for requirements
elicitation (multiple selections allowed)?
a. Interviews ( )
b. Questionnaires ( )
c. Observations ( )
d. social analysis ( )
e. prototype ( )
f. Scenario ( )
g. Brain Storming ( )
37
h. JAD ( )
11. How much time do you spend for the requirements engineering in a total project
time?
12. Which method you prefer mostly to gather the requirements? Can you give the
Rating for usage of the particular method in the industry level?
a. Interviews ( )
b. questionnaire ( )
c. Observations ( )
d. prototypes ( )
e. Scenarios ()
f. Reuse ( )
g. Brainstorming ( )
h. Jad ( )
13. Which method will take more time and cost?
14. Do you prefer user centered design to gather the requirements?
15. Can you provide any general information regarding the different methods of
requirements? (I mean which method will give the good result depends on the project
and the situation).
-----------------------------------------------------------------------------------------------------
--
-----------------------------------------------------------------------------------------------------
--.
38

Requirement Engineering

Uploaded by

Copyright:

Available Formats

Requirement Engineering

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirement Engineering

Uploaded by

Copyright:

Available Formats

2008:PR003

Requirements Engineering: Elicitation Techniques

The main aim of the requirement engineering process is gathering of requirements. It

effectiveness of every method, it is useful to select the particular elicitation method

the future development of new methods for requirement elicitation.

Author: Sai Ganesh. Gunda

Publisher: University West, Department of Technology, Mathematics and Computer Science,

Section 3 contains the description of different activities involved in the requirements

Requirements engineering is the branch of software Engineering concerned with the

2.1 User requirements

2.2 System Requirements

2.2.1 Functional requirements

What the system is expected to provide

2.2.2 Non functional requirements

Safety and security measures provided by the system

This also includes budget, scheduling, etc.

2.3 Requirements engineering

3. Requirements Engineering Process

Unlike the Software engineering process, Requirement engineering is also made up of

Feasibility Requirements Require

User and system

Figure 1: Requirements engineering process [6].

1. Existing system document

The outputs for the Requirements engineering process are,

Diagrammatic representation of Inputs and outputs of a requirements engineering

Figure 2: Inputs and Outputs of a Requirements engineering process [4].

3.1 Feasibility study

Does the overall objectives of the organisation is satisfied by the system?

1. The reaction of the organisation if the proposed system is not implemented.

3.2 Requirements Elicitation and Analysis

1. What the proposed system should provide?

Diagrammatic Representation of Requirements elicitation process

Figure 3: Requirements elicitation process [6]

Back ground Knowledge

Gathering the requirements

1. Lack of technical knowledge and unawareness of the technical aspects of the

4. Classic Requirements Elicitation techniques

1. Closed Interview: In this interview the requirements engineer prepare some

1. Effectiveness and the design of the questionnaire

1. The purpose of the survey should be defined

Steps in arranging a questionnaire [25]

4.3 Social analysis

This social analysis is of four types [33, 34]. They are,

Explanatory Observations- In this type of observation, the users talk loudly,

Ethnography [4,33,58] - In this method the observer is completely immersed in the

5. Modern Requirements Elicitation Techniques

Diagrammatic representation of the Prototype lifecycle model

Figure 4: Prototype life cycle model source [3].

1. When the users are unable to express their requirements.

1. Throw-away prototypes: This type of prototype is not reusable and hence is

5.2 Requirements reuse

What are the problems in the existing product?

Diagrammatic representation of Reusable requirements:

Figure 5: Reusable Requirements [2]

The method to prepare the scenario is as follows [4, 43, 44]

Brainstorming can be used to answer the following questions [45,58],

What exactly the system should provide

5.5 Joint Application Development

The success of the JAD depends on [47,58]