International Journal of Recent Development in Engineering and Technology

Website: www.ijrdet.com (ISSN 2347-6435(Online), Volume 1, Issue 3, December 2013)

Requirements Elicitation Techniques: Comparative Study

Omar Isam Al Mrayat1, Norita Md Norwawi2, Nurlida Basir3
1,2,3
Faculty of Science and Technology, Universiti Sains Islam Malaysia (USIM), Bandar Baru Nilai, 71800 Nilai, Negeri
Sembilan
Abstract— Over the years, software development failures is Bergey, et al. have highlighted that if the quality
really a burning issue, might be ascribed to quite a number of requirements are not proficiently identified, the ensuing
attributes, of which, no-compliance of users requirements and system cannot be properly assessed for success or failure,
using the non suitable technique to elicit user requirements well before implementation. The [5] authors have stated
are considered foremost. In order to address this issue and to
that “It is widely acknowledged within the software
facilitate system designers, this study had filtered and
compared user requirements elicitation technique, based on industry that software engineering projects are critically
principles of requirements engineering. This comparative vulnerable when these activities [elicitation, analysis,
study facilitates developers to build systems based on success specification, and validation] are performed poorly”.
stories, making use of a optimistic perspective for achieving a
foreseeable future. This paper is aimed at enhancing processes II. BACKGROUND
of choosing a suitable technique to elicit user requirements;
this is crucial to determine the requirements of the user, as it Studies have exposed that problems associated with
enables much better software development and does not waste requirements engineering could cost 10-200 times more to
resources unnecessarily. Basically, this study will complement rectify the program after its implementation, than if they
the present approaches, by representing a optimistic and were recognized during specifications [6, 7, 8]. Few other
potential factor for every single method in requirements researchers have suggested that, the comprehensive amount
engineering, which results in much better user needs, and of project budget due to requirements flaws is twenty-five
identifies novel and distinctive specifications. to forty percent 25 to 40 % [9]. It is noteworthy that,
requirements engineering is not only crucial, but will be
Keywords— Requirements Engineering, Requirements
Elicitation Techniques, Conversational methods,
disadvantageous, if the acceptable sources are not devoted
Observational methods, Analytic methods, Synthetic methods. early. Requirements Engineering (RE) “is an activity,
which aim is to discover, document and maintain a set of
I. INTRODUCTION requirements” [10, 11].
“The use of the term engineering implies that systematic
Analysts and experts have reported considerable proofs and repeatable techniques should be used to ensure that
in the research literature, related to software quality system requirements are complete, consistent and relevant”
requirements that facilitate successful software delivery. [1] [12]. Another definition according Software Test and
has reviewed 10 software project failures over the span of Evaluation Panel (STEP) is “the disciplined application of
two decades. The study has specifically ascribed three of scientific principles and techniques for developing,
those downfalls to poor requirements analysis. It has been communicating, and managing requirements” [13].
claimed that poor requirements are in eighth position in his Similarly, [14] have defined requirements engineering as
list of the top 10 errors made by developers. Wiegers have “the systematic process of developing requirements
argued “If you don‘t get the requirements right, it doesn‘t through an iterative process of analyzing a problem,
matter how well you execute the rest of the project” [2]. documenting the resulting observations, and checking the
McGovern has declared that “the critical success factor will accuracy of the understanding gained”.
always be the accuracy and completeness with which the Both these definitions indicate that requirements
business requirements and goals are captured and traced to engineering is not just a single activity, rather it a process,
the associated details” [3]. which comprises a variety of phases and actions. [15] has
According to [4], the intent of requirements analysis, is pointed out that requirements engineering can be classified
to elevate the probability of building right system, i.e., into elicitation, solution determination, specification, and
upon completion the system must satisfy the targeted maintenance.
customers and address their needs to a satisfactory degree.

1
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
Dorfman has segregated requirements engineering into In addition, [23] have defined requirement elicitation is
five phases, such as, elicitation, analysis, specification, the first step in the first step in gathering user requirements;
validation/verification, and management [16]. [17] have it is the process of understanding and acquiring the needs
identified that requirements engineering has the following of users and other stakeholders.
phases; eliciting requirements, modeling and analyzing The term “elicitation” is used to capture the idea that, the
requirements, communicating requirements, agreeing on individuals, who will be engaged within the system on a
requirements, and evolving requirements. daily basis, are the appropriate source for the identification
Even though we mostly agree with the classifications of of needs and opportunities, and that designers must “draw”
the requirements engineering process mentioned above, the requirements from such stakeholders. It is important to
however, we feel that the researchers have failed to include note that the requirements elicitation process focuses on
a phase to support requirements during the early stages of “what” is expected to be achieved by the predicted system
development. Therefore, we have considered requirements irrespective of “how” it is to be achieved. In the literature,
engineering as a process, which is composed of five a range of process models have been developed to identify
distinct, but related phases. Figure I below shows these the various features of the requirements phase of the
phases; however, we do not consider security requirements software. One widely employed model suggests three
engineering to be a sequential process (as each phase can fundamental stages, such as: elicitation, specification, and
and should affect the others). validation of requirements [19]. It is noteworthy that the
requirements elicitation is concerned with the process of
determining what issues must be addressed by a design
effort. Requirements specification is constructed upon the
elicitation activity, and comprises the specific
documentation of the specifications for the system [24].
Generally, this constitutes both natural language
explanations and official modeling techniques. Ultimately,
requirements are carried out to assure the recognition of
stakeholders for the requirements, which have been
reported and which will be applied in pursuing design
initiatives [25]. While this three-stage model indicates a
linear strategy to develop requirements. The three phases
FIGURE I Requirements Engineering Phases Surveyed.
are generally employed iteratively, often moving
progressively in more detailed levels of requirements
Source: Adapted from Sommerville. Software Engineering gathering.
Book,(1998). Just as the requirements phase process is critical to the
overall success of software design efforts, the requirements
III. REQUIREMENTS ELICITATION elicitation also plays a crucial initial role in the extensive
Quite a number of authors have stated that requirement requirements elicitation process. One of the crucial features
elicitation is the first phase of the process, by which a of requirements elicitation is that, it is typically one of the
project team determines the organizational needs that must most important components, by which the project team
be addressed by the project effort [18, 19, 20, 21]. members acquire knowledge related to organizational
Particularly, requirements elicitation concentrates on the domain. [19] have stated that “the importance of
preliminary pursuit of identified requirements and requirements elicitation cannot easily be overestimated;
possibilities of the social actors (e.g., participants, users) when you have to solve somebody else’s problem the first
most strongly associated with the system. A report from thing you have to do is to find out more about it” (P.21).
[22] claims that requirement elicitation is concerned with The emphasis of the requirements process is generally
software requirements originate from and how the software presented as the process revealing the essential obstacles
engineer can gather them. It is the first stage in within the business context, generally known as “problem
understanding the problem, which needs the software is domain”.
required to solve.

2
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
Consequently, traditional requirements elicitation Methods in this group are also referred as verbal
strategies signify a shortfall based mode of inquiry, which methods [32]. A standard conversational strategy is
is participating “in a study of what is unsuitable, not interview. It is generally used in requirements elicitation
working, not up to standard, and in need of a ‘fix’” [26]. In [20]. Other methods under this category include workshop,
the following section, an overview of the most relevant focus groups and brainstorming (Table I).
techniques used in requirements elicitation are presented in TABLE I
the context of a standard software development process. Conversational methods
Also, the classifications of requirements elicitation
Method Literature Executor Illustration
techniques are demonstrated and briefly highlight a number
of the most widely employed methods of requirements support
elicitation and discuss the associated strengths and the
[20, 33, An Interviewer discusses
challenges. experienced the desired product with
Overall, the goal is to force the analyst, user, and other 34]
analyst with different groups of
stakeholders to understand the requirements they want to generic people and builds up an
address. Defining requirements calls for effective knowledge understanding of their
Interviews about the requirements
interaction and open communication between the user and application (Interviewer asks
the developer to generate the necessary requirements they domain questions to the
want to address and the information that can be used to specialist or end-users,
develop the system that meets the needs of the user [27]. related to a particular
topic)

IV. REQUIREMENTS ELICITATION TECHNIQUES [33, 34] An Stakeholder

experienced representatives gather
CATEGORIES outside together for a short but
Workshop,
The requirements elicitation techniques facilitates the facilitator intensely focused period
focus groups
developers to have an understanding of the requirements of to create or review high
-level features of the
users, this phase allows the developers to recognize the desired products
requirements of stakeholders, other than the actual users of
[34, 35, 36 An Brainstorming is a kind
systems [28, 29]. Nevertheless, [30] have stated that experienced of mini conference, held
elicitation is the process, which motivates the dynamic , 37, 38]
outside among six to ten
contribution of users in system development, which facilitator experts. Members from
consequently increases the accomplishments and endurance Brainstorming different walks of life
involve in the
of information systems. According to [31] specifications
brainstorming, chaired
progression is an rigorous communication procedure by the organizer, who
among stakeholders and the programmers, therefore the asserts the topic to be
four kinds of elicitation methods vary depending on the discussed
context of communication: observational, conversational,
analytic, and synthetic [31]. Each and every kind provides a One of the most common types of social relationship is
unique communication model among programmers and conversation. Generally people are pleased to express about
stakeholders, and demonstrates the characteristics of a the jobs they perform, and the challenges they encounter.
strategy. Realizing the category of method facilitates The verbal needs and limitations are generally called non-
engineers to comprehend various elicitation methods and tacit specifications. As oral communication is realistic and
guides them to choose a suitable technique, for productive to gather non-tacit knowledge, the
requirements elicitation. conversational methods constitute the principal approach to
non-tacit requirements elicitation, by carrying out
A. Conversational Methods interviews, workshops or brainstorming sessions [39].
The conversational method provides a means of verbal Generally, conversational strategies are extremely used in
communication between two or more people. As requirements development, however not by itself, they
conversation is a normal means to convey requirements and require combining other kinds of techniques, to accomplish
concepts, and ask and answer questions, it is efficient to the software development phase.
build and comprehend the issues and to elicit generic
product requirements [32].

3
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
However, they require a lot of human efforts [18, 40]: Observational methods seem to be best suited, when
conference set up and creating transcript and examining individuals find it complicated to communicate their
records of a live conversation, and consume a lot of time. requirements and when analysts search for a improved
On the other hand, it is concern to accomplish the comprehension of the perspective, where the preferred
elicitation process, particularly when employing workshop product has to be utilized [42]. Good examples of tacit
or brainstorming, e.g. organizing the meeting and making information consist of the scheduled work, which
sure that the representatives are available for the meeting individuals accomplish day-to-day, spontaneously and in
[20]. the organizational or social contexts, which most likely
affect the specifications. As people are acquainted with the
B. Observational Methods
perspective and scenario of their work, they do not
The observational method provides a means to develop a deliberately contemplate about the schedules and the
rich understanding of the application domain by observing working environment. It is challenging for them to
human activities [31]. In addition to non-tacit requirements, enunciate how work is performed, despite the fact that
some requirements are obvious to stakeholders, but occasionally the routine work is simple to be revealed to
difficult to verbalize, which is called as tacit requirements others [20]. Therefore, to be engrossed in the actual work
[39]. Verbal communication is frequently weak, when scenario, to acquire the observational facts, can assist
gathering tacit requirements. Consequently, observing how engineers to thoroughly, understand the routine of work,
people perform their routine work, facilitates gather the societal group, the organization, and the wider
information, which are challenging to explain in words. perspective, within which the product is used. As
Methods under this group are illustrated in Table II. observation methods fall into the category of longitudinal
TABLE II studies, in general, it takes longer period than the other
Observational methods methods [43], which is considered as main disadvantage of
Method Literature Executor Illustration such methods, especially when the project has tight
schedule at the requirements stage. Besides this,
Support
observation requires compassion and receptiveness to the
Social analysis [20, 39] An observer physical environment [31]. It is easy for observers to
and spends a period perceive a good image about the work context, but it is
Ethnographic in a society or normally hard to specify and analyse their perception.
study The observer culture on Observational methods are used for understanding
must be making detailed
[33, 41, observation of complex societies, rather than making judgments about
accepted by the
17] people being all their improving or supporting the ways of working [20, 31].
studied as a practices. User They are beneficial to discover fundamental elements of
Observation kindred spirit culture and work routine order, such as the standard design of work, and
and must be environment are
observed offer the most relevant information towards designing
sufficiently
familiar that solutions [44]. Consequently, it is generally a good practice
[33, 39] they carry on A subject is
to begin with an observational method, to get a preliminary
with their engaged in some comprehension of the preferred product, when the
normal practices task, and development team falls short of experiences of product
as if he was not concurrently
Protocol
there development in a given domain.
analysis speaks out loud
and explains his C. Analytic Methods
thought
Analytic methods provide ways to explore the existing
documentation or knowledge and acquire requirements
from a series of deductions. These methods are illustrated
in Table III.

4
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
TABLE III Furthermore, they recognize and reuse requirements
Analytic methods
from the specification of the heritage or identical products.
Method Literature Executor Illustration It is always worth searching and filtering for reports and
Support recorded information, relevant to the desired product. The
mapping techniques are beneficial for knowledge
[20, 33,41, Documentation In this technique acquisition, in analytic methods [50]. Multidimensional
45, 46, 47] the systems within scaling [50, 51] allows users to obtain conceptual structure,
Requirement
the same product
reuse
family is used to
to recognize aspects and identify cause-effect associations
identify of a process, and variance analysis [50,52] to use existing
requirements of system as a basis for determining new system requirements.
the desired system Generally these techniques are considered as knowledge
[20, 45, Documentation A common acquisition strategies; however they are also flexible in
46] method consisting requirements elicitation. As explained in Table III,
of reading and laddering [48] is utilized to elicit justification and
Documentation studying available
documentation for explanation of technological terminologies or subjective
studies /content
content that is terms, and to elicit, how specialists composite their
relevant to and knowledge about a field, and card sorting [49]. Generally,
useful on the the analytic strategies are not essential to requirements
requirements
elicitation tasks elicitation, because requirements are grabbed ultimately
from other sources, instead of end users and clients.
[48] Expert ’s It involves the Nevertheless, they form secondary variants, to enhance the
creation, reviewing
knowledge and modification performance and usefulness of requirements elicitation,
of hierarchical particularly when the information from heritage or relevant
Analysis
content of expert’s products is re-usable.
Laddering
knowledge, often
in the form of D. Synthetic Methods
ladders (i.e. tree
diagrams) According to [39], the synthetic strategies incorporate
various channels of communication, and offer models to
[49] Expert’s The expert is illustrate the characteristics and relationship of system, they
asked to sort into
knowledge groups a set of deliver good hints for requirement recognition, in the form
cards each of of abundant semantic models. For instance, the prototypes
Card sorting which has the offer an initial version of the system to the users, which can
name of some emphasize them about the functions which are usually in
domain entity
written or depicted any other case ignored. Storyboard technique, which is
on it categorized between scenarios and prototyping. It presents
a procession of prospects beginning from sample
A wide range of studies have focused on requirements of components to live interactive reports [34]. Appreciative
the preferred product, which consists of problem Inquiry (AI) is a combined method, which includes
evaluation, organizational charts, specifications, user communication between clients and designers, examine the
manuals of existing systems, research report of competitive existing systems, tracking the behaviours of the users and
systems in market. By understanding it, the engineers visualize the future system or software, with all the
capture the information about the application domain, the necessary functions. It includes combined strategies, which
work-flow, the characteristics of product, and map it to the enhance requirements elicitation process. Examples of
requirements specification [48]. synthetic methods are illustrated in Table IV.

5
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
TABLE IV [57, 58, 59, Appreciative
Synthetic methods Inquiry (acronym
60, 61, 62]
"AI") is principally
Method literature Executor Illustration an organizational
Appreciative development
support
Inquiry (AI) method, which
[20, 34, 35, This approach focuses on increasing
53] describes the precise what an organization
details of the current does well rather than
Scenarios, and future processes, on eliminating what
passive which comprises the it does badly
storyboards actions and
interactions between The synthetic methods are generally integrated at other
the users and the
phases of the product development life cycle. As the
Analysts and system
purpose of synthetic methods is to enhance the
stakeholder
[20, 34, It provides communication among programmers and the clients, they
representatives
17] stakeholders with a
communicate
concrete (although
are appropriate for various phases of the development
and coordinate process. They efficiently coordinate the requirements stage
partial) model or
to reach a with the remaining development processes.
system that they
common
might expect to be
Prototyping, understanding
delivered at the end
Interactive of the
of a project. It is
V. COMPARISON BETWEEN CATEGORIES OF
requirements REQUIREMENTS ELICITATION TECHNIQUES
storyboards often used to elicit
and validate system
requirements.
The categories are due to the outcomes of dissimilarities
Prototype generally between the requirements elicitation techniques, each and
represents and every group has some characteristics, which make all
visualizes the actual categories to have distinctive characteristics. The table
parts of system
below shows comparison among various groups of
[35, 39, 54, It stands for Joint elicitation techniques and their benefits and drawbacks.
55] Application
Development. Rapid TABLE V
Application Comparison between categories of elicitation techniques
Development and
Stakeholder Observable Future system
emphasizes user Category
Participation phenomena Knowledge
involvement through
group sessions with Definitely Not applicable Some hints or
unbiased facilitator. stakeholders are guidelines are
This approach is the main provided that might
JAD/RAD Conversation
more or less similar participants guide the future
to the brainstorming, al methods development of
however, it differs is systems. Novel ideas
one aspect, where the might lead the
stakeholders and the analyst to envisage
users are also future system
allowed to participate
and discuss on the Stake holders do The whole Observing the
design of the not participate, process is current methods are
proposed system Observational as this method based on the not easily applied to
methods totally involves phenomenon the development of
[56] It is a combination of the observer to of observation future concepts
open-ended observe the (s), hence this
interview, workplace activities of the criteria is very
observation, and end-user crucial
Contextual prototyping. This
inquiry method is primarily Stake holders do A lot of The analyzing of
used for interactive Analytic not participate factors, codes and other
systems design methods including the existing documents
where user interface codes are will pave way for
design in critical observed getting knowledge
about the future
6
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
system Based on the explanation about the various categories of
involves Some parts of The strong Synthetic elicitation methods, it is evident that, each and every
collaboration the process is methodspractices, category has its own advantages and disadvantages. The
between based on the make people to give above table has clearly illustrated the pros and cons of each
stakeholders and phenomenon more ideas about the method. The conversational methods have a lot of
systems analysts of future systems,.
to identify needs observations, Hence gaining advantages, such as the actual fact, which is very helpful
or requirements hence this knowledge about for collecting loaded information about the requirements.
criteria is very future system is one Apart from unearthing opinions, the interview technique
Synthetic crucial also of the biggest
methods indentifies feelings and goals of different individuals. With
Behaviors of advantage of this
people are method. Synthetic the help of interviews, it is easy to dig the details by asking
observed methods are a follow-up questions. However the conversational methods
strategy for have the following disadvantages: it is very difficult to
purposeful change
master the skills of interviewing. The requirement
that identifies the
best of “what is” to elicitation depends a lot on the behaviour and attitude of
pursue dreams and interviewer. Moreover, the interviewer has to be always
possibilities of “what unbiased. Even though we can collect lot information with
could be” the interview method, we cannot assure for getting
Understanding
Identifying Predictive ability of meaningful information.
Category sources of unique attributes The benefits of observational methods can be
the domain
requirements elicited
summarized as follows; the observational methods are
Diverse, Nil Nil better option for fetching basic aspects of routine order.
Conversation knowledge Furthermore, they offer crucial information for designing
al methods sharing might
make analyst to
solution. These methods are very handy, when the
understand development team lacks experience about product domain.
domains However, there are some problems in practicing the
Observational Nil Depends on the
observational methods. The most critical drawback is that,
methods observer observational methods need a lot of time, and these
Observational
methods
techniques are not good choice, when schedule is tight.
clearly makes
the analyst to Similar to conversational methods, the observational
understand the methods are also very difficult to understand thoroughly.
domain Furthermore, observational methods need sensitivity and
Again, the code Definitely, this Nil responsiveness towards physical environment. Many
analyzing method needs studies have discussed about the analytic methods and give
Analytic process will makes the the techniques that are related to this category as mentioned
methods reveal the facts analysts to
of domain understand
before, for example reusing the requirements of the existing
and identify system as common method of requirements elicitation.
the source of There are a lot of advantages of using the existing
requirements knowledge to develop the new product, which includes low
As the experts Synthetic It’s one of the most cost and less time. Despite the disparities of type of users
will be made to methods important features is and stakeholders, this method is used very commonly
converse about generates the predictive and particularly in developing user interfaces, database and
the domain, it volumes of find a unique
becomes very data that attributes
security policies.
Synthetic effective means provide great Many projects have failed due to the employment of
methods to understand the detail on the inappropriate elicitation methods. One such example of big
domain. This origins and project failure is “Ariane 5 Flight 501 (European Ariane 5
type makes the consequences
analyst to of local needs
expendable launch System)”, where, the requirements
unambiguously and resource specifications of Ariane 4 were reused.
understand the constraints
domain

7
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
However, the flight path of Ariane 5 was very much VI. CONCLUSION
different, hence, the system developed using the The beneficial factors of synthetic methods are: these
requirements of Ariane 4 was unable to handle the Ariane 5 methods is built upon the positive aspects of an
flight path, this is one of the most important disadvantages organization or group, it recognizes factors, which are well
of analytic methods, because the failure will be after testing executed; therefore, we can have a very effective and
the new software or system, so this methods depends on the optimistic effect on state of mind, assurance, and value of
old code or software that might completely or partially individuals and groups. Contributors are motivated,
different from the new software. because they feel very much appreciated. Due to the casual
The synthetic methods, it is particularly valuable for conversational style of questioning, and specific focus on
stakeholders such as, business owners and end users who the participants, it is easy to involve individuals in
might not understand the technical aspects of requirements, synthetic methods, who generally do not get involved in
however, will better relate to a visual representation of the these kinds of activities.
end product. Prototyping as a example may be an
interactive screen, a mock-up, a navigation flow or a REFERENCES
storyboard. Simple, throwaway prototypes might be [1] Nelson, R. R. 2007. “IT project management: Infamous failures,
executed in the initial stages of discovery, and more classic mistakes, and best practices”. MIS Quarterly Executive. 6(2),
detailed, interactive prototypes might be done once 67-78.
business requirements have been identified [31]. Another [2] Wiegers, K. E. 2006. “More about software requirements: Thorny
issues and practical advice”. Microsoft Press: Redmond Washington.
example under the same category is appreciative inquiry
[3] McGovern, F. 2007. “Getting requirements right in the analysis
technique (AI), in order to clearly understand this phase”. Compuware White Paper.
technique, it is crucial to dissect the terms and comprehend [4] Zowghi, D., & Coulin, C. 2005. “2 Requirements Elicitation : A
the meaning in the context: appreciation means to Survey of Techniques, Approaches , and Tools”.
recognize and value the contributions or attributes of things [5] IEEE SWEBOK, R. 2004. "Software Engineering Body of
and people around us. Inquiry indicates the exploration and Knowledge."
identification of possibilities of novel ideas. When [6] Boehm, B. & Papaccio, P.1988. “Understanding and Controlling
combined, this term means that by appreciating what is Software Costs”. IEEE Transactions on Software Engineering. SE-4,
10.
good and valuable in the present situation, it is possible to
[7] McConnell, S. 2001. “From the Editor - An Ounce of Prevention”.
discover and understand the means to institute positive IEEE Software. 18, 3.
change for the future [61]. [8] Romero & Mariona. 2010. “Sure: secure and usable requirements
The positive aspects of appreciative inquiry are: this engineering”.Retrieved fromhttp://dl.acm.org/citation.cfm?id=1925
approach is constructed upon the advantages of an 644.
organization or group; it understands things that are well [9] Wiegers, K.2003: “Software Requirements”. Microsoft Press.
implemented. Consequently, a very beneficial and [10] Pamela Zave. 1997. “Classification of research efforts in
optimistic influence on spirits, guarantee and value of requirements engineering”. ACM Comput. Surv. 29(4):315–321.
individuals and groups, contributors can become [11] Raimundas Matulevicius. 2005. “Process Support for Requirements
empowered and encouraged. It is very easy to involve Engineering A Requirements Engineering Tool Evaluation
Approach”. PhD thesis, NTNU. Doctoral theses at NTNU. 142.
people, who do not generally get engaged in this kind of
[12] Sommerville and Sawyer. 1997. “Requirements Engineering”. A
activity, due to the fact of the conversational style of Good Practice. John Wiley and Sons.
questioning and specific focus on the participants [62, 63, [13] Software Test & Evaluation Panel (STEP). 1991. “Requirements
64]. However, the disadvantages of the appreciative inquiry Definition Implementation Team: Operational Requirements for
are: it consumes time, needs periodic commitment, to Automated Capabilities”. Draft Pamphlet (Draft PAM).
motivate participants and occasionally additional works [14] Loucopoulos, P., and Champion. 1989. “R.E.M.: Knowledge-Based
should be done to get people out of the SWOT (strengths Support for Requirements Engineering”. Information and Software
Technology.
weaknesses, opportunities threat) mindset.

8
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
[15] Davis, A. 1990. “Software Requirements: Analysis and [34] Leffingwell, D. and Widrig, D. 2003. “Managing Software
Specification”. Prentice Hall. Requirements - A User Case Approach”. 2nd Ed. Addison-Wesley.
[16] Dorfman, M. 1990. “Tutorial: System and Software Requirements [35] Zowghi, D., & Coulin, C. 2005. “2 Requirements Elicitation : A
Engineering”. IEEE Computer Society Press. Survey of Techniques, Approaches , and Tools”.
[17] Nuseibeh, B. and Easterbrook, S. 2000. “Requirements engineering”. [36] Tsumaki, T., & Tamai, T. 2005. “A framework for matching
a roadmap. in Proceedings of the Conference on The Future of requirements engineering techniques to project characteristics and
Software Engineering, (Limerick, Ireland), ACM Press. 35 - 46. situation changes”. … of Situational Requirements Engineering …,
[18] Goguen, J. & Linden, C. 1993. “Techniques for Requirements 44–58. Retrieved from http://cui.unige.ch/db-
Elicitation”. 1st IEEE International Symposium on Requirements research/SREP05/Papers/04.pdf.
Engineering (RE'93), San Diego, USA, 4-6th January. pp. 152-164. [37] [37] Chauncey e. Wilson. 2006. “Brainstorming Pitfalls and Best
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=324822. Practices”. ACM. vol 13,issue 5.,pages 50-63.
[19] Loucopoulos, P., and Karakostas. 1995. “V. System Requirements http://delivery.acm.org/10.1145/1160000/1151342/p50-wilson.
Engineering McGraw-Hill”. Inc., New York, NY. pdf?key1=1151342&key2=0909760121&coll=ACM&dl=ACM&CF
ID=67531224&CFTOKEN=54899420.
[20] Kotonya, G., and Sommerville, I. 1998. “Requirements
Engineering”. Processes and Techniques John Wiley & Sons. New [38] Linn Gustafson. 2008. “Requirements Engineering Verification
York, NY. validation”. University West, Course slides.
[21] Escalona, M., & Koch, N. 2004. “Requirements engineering for web [39] Maiden, N. &Rugg, G. 1996. ACRE: “Selecting Methods for
applications-a comparative study”. Journal of Web Engineering. Requirement Acquisition”. IEEE, Software Engineering Journal.
2(3), 193–212. Retrieved from http://citeseerx.ist.psu.edu 11(3):183-19247.
/viewdoc/download?doi=10.1.1.153.5974&rep=rep1&type=pdf. [40] Christel, M.G. and Kang, K.C. 1992. “Issues in requirements
[22] IEEE SWEBOK, R. 2004. "Software Engineering Body of elicitation Technical report”. CMU/SEI-92-TR-12 ESC-TR-92-012.
Knowledge." Carnegie Mellon University. Pittsburgh, PA,80.
[23] Browne, G. J., & Ramesh, V. 2002. “Improving information [41] Stephen Viler & Ian Sommerville. 1999. “Social analysis in the
requirements determination: a cognitive perspective”. Information & requirements engineering process: From ethnography to method”.
Management. 39(8), 625–645. doi:10.1016/S0378-7206(02)00014-9. IEEE. pages 6-13. http://ieeexplore.ieee.org/iel5/6303/
16860/00777980. pdf?tp=&arnumber =777980&isnumber=16860.
[24] Vessey, I., and Conger, S. 1994. "Requirements Specification:
Learning Object, Process, and Data Methodologies". [42] Viller, S. and Sommerville, I. 2000. “Social analysis in the
Communications of the ACM. (37:5), pp 102-113. requirements engineering process: from ethnography to method”. in
Proceedings of the 4th International Symposium on Requirements
[25] Wallace, D.R., and Ippolito, L.M. 1997. "Verifying and Validating
Engineering. (RE'99), (Limerick, Ireland, 1999), IEEE CS press.
Software Requirements Specifications". in: Software Requirements
Engineering, R.H. Thayer and M. Dorfman (eds.), IEEE Computer [43] Myers, M.D. 1999. “Investigating information systems with
Society Press. Los Alamitos. CA. pp. 389-404. ethnographic research”. Communications of the AIS, 2.
[26] Whitney, D. 1998. "Let’s change the subject and change our [44] Hutchings, A.F. and Knox, S.T. 1995. “Creating products: Customer
organization: an appreciative inquiry approach to organization demand”. Comm. ACM. 38 (5). 72-80.
change". Career Development International (3:7), pp 314-319. [45] Cybulski, J.L. and Reed, K. 2000. “Requirements Classification and
[27] Guinan, P., Bostrom, R.P. 1986. “Development of computer based Reuse: Crossing Domain Boundaries”. in Conference on Software
information system: A communications framework”. SIGMIS Reuse. ICSR'2000, (Vienna and Austria), 190-210.
Database. 17(3), 3-16. [46] Knethen, A.v., Paech, B., Kiedaisch, F. and Houdek, F. 2002.
[28] Browne, G. J., & Ramesh, V. 2002. “Improving information “Systematic requirements recycling through abstraction and
requirements determination: a cognitive perspective”. Information & traceability”. in IEEE Joint International Conference on
Management. 39(8), 625–645. doi:10.1016/S0378-7206(02)00014-9. Requirements Engineering.
[29] Hickey AM, Davis AM. 2004. “A unified model of requirements [47] Woo, H.G. and Robinson, W.N. 2002. “Reuse of scenario
elicitation”. J Manage Inf Syst 20(4):65. specifications using an automated relational learner: a lightweight
approach”. in IEEE Joint International Conference on Requirements
[30] Farzan R, DiMicco JM, Millen DR, Dugan C, Geyer W, Brownholtz
Engineering. 173 - 180.
EA. 2008. “Results from deploying a participation incentive
mechanism within the enterprise”. [48] Rugg, G., Eva, M., Mahmood, A., Rehman, N., Andrews, S. and
Davies, S. 2002. “Eliciting information about organizational culture
[31] Zhang, Z. 2007. “Effective Requirements Development-A
via laddering”. Information Systems Journal, 12 (3).215-229.
Comparison of Requirements Elicitation techniques”. Tampere,
Finland, INSPIRE, 225–240. Retrieved from [49] Rugg, G. and McGeorge, P. 1999. “The concept sorting techniques”.
http://pdf.aminer.org/000/359/901/requirements_elicitation_with_ind The Encyclopedia of Library and Information Science. 65(28). 43 -
irect_knowledge_elicitation_techniques_comparison_of_three.pdf. 71.
[32] Avison, D.E. and Fitzgerald, G. (eds.). 1995. “Information Systems [50] Byrd, T.A., Cossick, K.L. and Zmud, R.W. 1992. “A Synthesis of
Development: Methodologies, Techniques and Tools”. McGraw-Hill Research on Requirements Analysis and Knowledge Acquisition
Book Company. Techniques”. MIS Quarterly. 16 (1). 117 - 138.
[33] Goguen, J. & Linden, C. 1993. “Techniques for Requirements [51] Wright, G. and Ayton, P. 1987. “Eliciting and modeling expert
Elicitation”. 1st IEEE International Symposium on Requirements knowledge”. Decision Support Systems. 3 (4). 13-26.
Engineering (RE'93), San Diego, USA, 4-6th January. pp. 152-164.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=324822.

9
 International Journal of Recent Development in Engineering and Technology
Website: www.ijrdet.com (ISSN 2347-6435(Online) Volume 1, Issue 3, December 2013)
[52] Hawgood, J., Land, F. and Mumford, E. 1978. “A participative [58] Cooperrider, D.L. & Whitney, D. 2001. “A positive revolution in
approach to forward planning and system change”. In Proceedings of change. In Cooperrider”. D. L. Sorenson, P., Whitney, D. & Yeager,
the 2nd Conference of the European Cooperation in Informatics. T. (eds.) Appreciative Inquiry: An Emerging Direction for
(Venice, Italy, 1978), 39 -81. Organization Development (9-29). Champaign, IL: Stipes.
[53] Stuart Anderson Massimo Felici. 2001. “Requirements engineering [59] Barrett, F.J. & Fry, R.E. 2005. “Appreciative Inquiry: A Positive
questionnaire”. Approach to Building Cooperative Capacity”. Chagrin Falls, OH:
http://homepages.inf.ed.ac.uk/mfelici/doc/questionnaire.pdf. Taos Institute.
[54] Coughlan, J., & Macredie, R. 2002. “Effective communication in [60] Whitney, D. & Trosten-Bloom, A. 2003. “The Power of
requirements elicitation: a comparison of methodologies”. Appreciative Inquiry”. San Francisco: Berrett-Koehler.
Requirements Engineering. 7(2), 47–60. [61] Kelm, J.B. 2005. “Appreciative Living: The Principles of
doi:10.1007/s007660200004. Appreciative Inquiry in Personal Life”. Wake Forest, NC: Venet.
[55] Charles F. Manski1 and Francesca Molinari. 2008. “Skip [62] Mrayat, O., Norwawi, N., & Basir, N. 2013. “Appreciative Inquiry
Sequencing:A Decision Problem In Questionnaire Design”. North- in Eliciting Software Requirements”. International Journal of
western University and Cornell University. vol 2, pages 264-285. Computer Science and Electronics Engineering (IJCSEE), 1(3).
http://arxiv.org/PS_cache/arxiv/pdf/0803/0803.3875v1.pdf.
[63] Gonzales, C. 2011a. “Eliciting user requirements using Appreciative
[56] Holtzblatt, K. and Beyer, H. 1993. “Making customer-centered inquiry”. Empirical Software Engineering. 20(4), 65–84. Retrieved
design work for teams”. Comm. ACM. 36 (10). 93 - 103. from. http://www.springerlink.com/index/X74905W1820K7187.pdf.
[57] Cooperrider, D.L. & Srivastva, S. 1987. “Appreciative inquiry in [64] Gonzales, C. K., & Leroy, G. 2011. “Eliciting user requirements
organizational life”. In Woodman, R. W. & Pasmore, W.A. (eds) using Appreciative inquiry”. Empirical Software Engineering, 16(6),
Research In Organizational Change And Development. Vol. 1 (129- 733–772. doi:10.1007/s10664-011-9156-x.
169). Stamford, CT: JAI Press.

10