> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

REQUIREMENT ELICITATION
TECHNIQUES REVIEW
Iman M. Misdan, Irra S. A. Fakhruddin, N. Humairah M.Nazri, Shaarweshwary S.,
A. Hafizi Ishak
II. REQUIREMENT ELICITATION

Abstract—Requirement Elicitation is an important process for A. Definition

both stakeholders and software engineers to make it easier for Requirements elicitation is the process of discovering,
them to identify, understand and document system requirements.
extracting and gathering requirements for a system through
The aim, major advantages, and typical procedures of
requirement elicitation techniques are highlighted in this brief communication with the stakeholders [5]. This process is often
overview. Three of the most commonly practiced elicitation handled by an individual with good communication skills and
techniques which are interview, observation and prototyping will knowledge in software engineering such as requirement analyst
be explained in detail including the evaluation using SWOT or requirement engineer. It is their responsibility to
analysis framework to structure our findings. Furthermore, all communicate or observe stakeholders to gather sufficient
three techniques will be compared in four critical aspects which is information and requirements. On the other hand, stakeholders
stakeholder involvement, accuracy, time and cost This document
aims to serve as a quick reference for software professionals
generally are anyone involved in the project who might benefit
looking for a brief summary of requirement elicitation methods or be impacted from it. According to [6] the term stakeholder is
and the role they play in the software development process. used as a general term to describe individuals, groups or
organizations that have an interest in the project and can
Index Terms— Requirement Elicitation, Requirement Elicitation mobilize resources to affect its outcome in some way. Hence,
Technique, Software Engineering, Requirement Engineering stakeholder’s feedback is vital in ensuring a successful system
to be developed which leads to the emergence of variety
requirement elicitation techniques to be used in different
scenarios or environments depending on the nature of the
I. INTRODUCTION
project. Specifically, requirement elicitation is an activity
EQUIREMENT elicitation techniques are an essential involved in discovering the requirements for the system which
part consist of four main stages starting from objective setting to
R of software development because it allows
stakeholders’ needs and expectations to be acknowledged,
background knowledge acquisition, knowledge organization
and finally stakeholder requirements collection. In reality,
comprehended and documented. To ensure that the system to be requirements elicitation is a multidimensional and iterative
developed is able to satisfy user demands and meets intended activity that heavily depends on the communication skills of
goals, successful eliciting requirements processes needs to be requirements engineers and the commitment of the system
done which establishes the groundwork for successful software stakeholders [4]. In literature, there are a few elicitation
projects. Thus, it is essential for software experts, especially techniques widely used in the field of software engineering
requirement engineers, to be able to extract precise and thorough which are interviews, brainstorming, observations and social
requirements by using a variety of approaches, which helps to analysis, requirements reuse and prototyping.
avoid misunderstandings, reduce project risks, and enhance
overall software system quality. According to the research [1],
B. Purposes of requirement elicitation
the requirements phase is considered as one of the most
significant phases of the software development lifecycle. It In general, due to the importance of stakeholders’ feedback in
includes the tasks of Elicitation, Analysis, Documentation, ensuring the project success, requirement elicitation is an
Validation and Management. In this document, three of the most important process carried out to involve stakeholders in the
iconic requirement elicitation techniques will be thoroughly software development lifecycle. Furthermore, requirements
reviewed which is the interview, observation and prototyping elicitation is necessary to ensure that the process of software
technique. Throughout the review, the definition, purposes, development is based on a consistent and comprehensive
advantages and disadvantages of the aforementioned techniques understanding about stakeholders’ goal and requirements for a
will be discussed in detail. system, which are analyzed and specified with requirements. It
has a very high impact on subsequent design and development
phases as well [2]. Thus, the primary objective of requirement
elicitation in requirements engineering process is to discover,
extracting and gathering requirements for a system through
communication with the stakeholders. The objectives of
requirement elicitation can be break down in details as follows:
• To understand and discover stakeholder’s requirements.
As discussed, the requirement elicitation process revolves
around the inputs from stakeholders to understand them and
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 2

provide solutions that are able to satisfy their needs. By software development team members. By obtaining insights and
eliciting requirements from stakeholders such as clients, asking related questions from stakeholders, such as business
end-users and administrators through effective analysts, customers, domain experts, and users, this technique
communication and active listening, the project team will aims to collect required information about the intended system.
get a complete understanding about the system that is going According to the research [3], the degree of success of an
to develop with minimal conflict. interview session depends on the questions created or asked (but
• To solve the conflict between stakeholders. Stakeholders difficulty about the questions is that which questions should be
consist of a variety group of people with different asked, particularly if the interviewer is not familiar with the
backgrounds and knowledge levels. In reality, all domain) and it is also depending on ability of the expert to
stakeholders may or may not agree to requirements from represent their knowledge. There are various methods to conduct
other stakeholders. Thus, it is essential for the requirement interviews such as through video conferencing, conducted face to
engineer to be able to identify the significance of certain face sessions or over the phone, depending on the participants'
stakeholders compared to others to properly prioritize preferences, schedules and locations. When used as a requirement
what should be accepted as the project requirement. In elicitation approach, interviews help create precise and thorough
some cases, however, software engineers can’t just software requirements by facilitating effective communication
prioritize some stakeholder over others in a conflict. This and enabling a deeper knowledge of stakeholder perspectives. The
is where good negotiation skills are needed to resolve the following are the SWOT analysis of interview techniques:
conflict via negotiation to come to an agreement. This part
of requirement elicitation is also vital since it is • Strength of interview technique
undesirable that some of the stakeholders might be 1- Able to clearly understand interviewee perspective.
unsatisfied and refuse to use the system later.
Understanding interviewee perspective is possible
• To define system boundaries, capability and constraints. through interviews that have the opportunity for
Stakeholders such as end users and administrators will most interactive conversation that gives a chance to acquire
likely provide requirements on what the system should be knowledge about their experiences, opinions, and
able to do. However, a software developer is also a viewpoints which might assist in clearing any ambiguity
stakeholder in a project. They are mostly responsible to in their requirements. Thus, software development teams
advise other stakeholders with their technical knowledge to can understand the stakeholder requirements and their
define the boundaries of the system scope and explain to the underlying motivations from the requirement obtained
other stakeholders how the system will be able to fulfill or by engaging in direct conversations.
unable to fulfill some of their requirements. Thus, the key
2- Interviews provide real-time feedback and follow-
features and functionalities that stakeholders want and the
ups.
developer able to develop can be defined so no party will
be disappointed or stressed resulting in a successful system. Through interviews, participants may provide feedback
on the concepts, prototypes or ideas that have been
Thus, the requirement elicitation process is undeniably
brought out on the spot. This input can be used to hone
important in ensuring the stated objective to be fulfilled resulting
requirements, verify theories, and ensure that the
to the development of a system that is capable of accurately
software meets the stakeholder expectations.
addressing stakeholders’ needs and requirements.
Furthermore, the interviewer may also follow up with
explanation or additional inquiry in order to clear up any
ambiguity on both ends. In developing a complex system
there are a lot of details to be covered which makes it
hard for people to memorize everything. Days or weeks
III. REQUIREMENT ELICITATION TECHNIQUES
after a discussion, the participant might already forget
what has been discussed. Hence, the timeliness of
There are a variety of requirement elicitation techniques as per response and follow up in an interview is a great value
aforementioned, however in this document we will be focusing in ensuring accurate requirements.
our review on three of the most iconic and familiar requirement
3- Uncover implicit messages.
elicitation techniques which is interview, observation and
prototyping. For the purpose of our review, we will be using the Stakeholders may have unexpressed or implicit
SWOT analysis framework which analyzes the subject based on requirements that are not apparent from written
its strength and weakness which comes from internal factors and documentation or verbal discussion. Interviews provide
the opportunity or threats which represents the external factor that a platform to explore these hidden needs, preferences,
may impact it. and constraints that may significantly impact the
software system's success through observation of
expression and body language of interviewee during the
A. Technique 1: Interview
session.
As one of the requirement elicitation techniques, interviews
require direct and structured discussion between stakeholders and
• Weakness of interview technique
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 3

1- Exhaustive preparation depending on both parties’ network signal strength

Prior to the interviews, the interviewer is required to do which may directly impact the interview sessions.
thorough research on the targeted company or person in 2- Distraction and diversion
order to have a better view of the interview while An interview session can easily divert to another
focusing on reaching certain objectives throughout the unrelated topic due to factors such as mutual interest or
interview. The interviewer may be burdened by this task personal history between both parties. Depending on the
as there is a lot of information to take on especially when type of person being interviewed, some people might
considering the fact that multiple distinct stakeholders bring up unnecessary topics during the conversion in
might be involved, and thus may affect their which case it's quite hard on the interviewer to handle,
performance during the interview which impacts the especially if the other party is a person of high
quality of requirements obtained. importance. According to [1], sometimes interviewers
do not get the response according to the interviewers’
2- Unnecessary information requirement and thus this issue varies between each
Being a verbal communication-based technique, the individuals both the interviewer and the interviewee.
interview might provide the interviewer not only with Thus, the personality of the interviewee may also affect
information required for the project but also random the outcome of an interview session.
nonsense, unnecessary or unrelated information to the Overall, interviewing is a good and efficient technique
project. It is hard to contain what is being spoken by the commonly practiced. However, it is important to note that the
interviewee even in a formal structured interview since success of interview is heavily reliant on the interviewer
letting them speak their mind is the essence of the communication skills toward variety type of persons. Thus, even
interview to begin with. Thus, the interviewer must be though it doesn’t have high materialistic requirement to be
able to filter any unnecessary information so that it won’t executed it requires excellent skills to be successful.
confuse their requirements.
B. Technique 2: Observation
• Opportunity in Interview technique Another technique often used in eliciting requirements is
1- Build rapport and trust. observation which requires paying close attention to analyze how
Conducting interviews may foster a sense of stakeholders behave, act and interact in either their natural
collaboration and partnership between the software environment or while utilizing the existing system. By personally
observing stakeholders’ practices and behaviors, this technique
development team and stakeholders. It helps build
rapport, establishes trust, and enhances the overall tries to get a thorough understanding of the context in which the
communication and relationship between the two software will be used and to identify both implicit and explicit
parties. requirements. Observation can offer insightful information of user
pain points, workflows, and opportunities for development.
2- Promotes the system to potential users. Software development teams can obtain firsthand information,
Interviewing actively involves stakeholders who will be identify unstated needs, and validate or refute presumptions about
using the system to make them feel acknowledged and system requirements by fully immersing themselves in the
valued by the developers. It might also spark interest in stakeholders’ environment. This technique complements other
them, making them look forward to the completion of the requirement elicitation methods and helps in ensuring that the
system that they contributed to by providing constructive final result of the system is adapted to the particular requirements
feedback. This is especially valuable for systems that of the stakeholders. The following are e the advantages and
aim to be monetized and rely on the number of their end disadvantages of observation categorized according to swot
users. analysis:

• Threats to interview technique • Strength of observation technique

1- Require proper space in order to be conducted. 1- Able to gain better contextual
A suitable environment is necessary for an interview to understanding.
be conductive and effective. The environment for the
Software development teams can gain a better
interview room also plays a role in enhancing the quality
understanding of the stakeholders’ work environment
of the interview where too much noise may affect the
through observation, including equipment, workspace,
hearing and the understandability of both interviewer
and resources on hand. According to [7] Observation
and interviewee. Such factors may contribute to
allows the observer to view what users actually do in
problems in conducting interviews resulting in bad
context, overcoming issues with stakeholders,
requirements. Nowadays, interviews can easily be done
describing idealized or oversimplified work processes.
online without needing any room or premises. However,
Thus, the teams can gain a better understanding of the
it is still open to threat of connectivity and accessibility
unique limitations, opportunities and challenges that
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 4

affect the requirements by observing stakeholders in Unlike interviews, it is possible for observation to be
their natural environment. done without being noticed although quite limited.
2- Uncover Implicit message. This indirect approach may extract information that
Similar to interview, observation allows gaining more can be valuable especially in the case of stakeholders
comprehensive implicit messages such as their having issues expressing their needs when confronted
expression or nonverbal complaints during their normal directly.
workflow or while using an existing system which can
• Threats to observation technique
lead to possible requirements to improve that particular
part. Due to the limitation of human memory, during 1- Hawthorne Effect
documentation or interviews, stakeholders may fail to The Hawthorne effect refers to the alteration of behavior
explicitly express particular requirements or needs. by the subjects of study due to the awareness of being
Thus, software development teams can find these observed. This might jeopardize the accuracy of the
implicit requirements that are not clearly specified but requirement being elicited due to the fakeness or
might be important for the success of the system. exaggeration of stakeholders' actions that try to
emphasize only the bad or good part of existing
3- Validate information and presumptions.
workflow toward their own personal benefit.
Through observation of actual action, behavior, or
system usage of the stakeholders we can match the 2- Misinterpretation
reality on the ground with any presumptions or existing Every information gained from observation is purely
information. This is especially effective if stakeholders subjective and might not be interpreted similarly by
being monitored are unaware of the observer so that they everyone due to different personalities. For example, a
will act more naturally as they always do. process that might look easy to the observer due to the
skills and experiences of the stakeholder might actually
be an exhausting process that can be simplified or
• Weakness of observation technique
improvised by a software solution. Thus, requirements
1- Exhaustive and time consuming. from observation might be inaccurate which may cause
Observing requires the observer to continuously monitor failure in providing a complete solution.
the stakeholders with no specified duration. It depends 3- Invasive
on how long the processes being observed are, however
The presence of the observer during the business process
most of the time it will indeed consume a huge amount
might disrupt it or distract the stakeholders in their
of time to capture requirements solely by observing
activity. Considering the fact that the observation might
stakeholders. This is because sufficient time is necessary
take quite a long time, this may affect the overall
for the observation method since it is easy for observers
performance of the stakeholders.
to perceive a rich picture about the work context, but it
is normally difficult to specify and investigate their Generally, observation is quite lacking in eliciting
perception [1]. Thus, in the aspect of time, observation requirements. This is especially true when the observer has
technique is very unclear and hard to predict. limited knowledge regarding the business process being observed.
However, it consumes almost no resources other than time. Thus,
2- Limited scope.
for software projects with low budget such as students’
Observation requires transparency between stakeholders coursework projects, observation is the technique that has always
and the observer, however in a complex business process been used. On the other hand, for critical large-scale projects it
that may involve sensitive processes or operations, would be wise to not rely on observation fully but also directly
privacy concerns arise making it hard to fully observe interact with the stakeholders via other techniques to supplement
the complete process. Thus, when performing the observation lacking factors.
observation ethical consideration and privacy concerns
might need to be considered in order to not violate
anyone's privacy. C. Technique 3: Prototyping
As a strategy for eliciting software requirements, prototyping
involves building an initial, particular functionality or condensed
• Opportunities in Observation technique version of the software system in order to collect feedback and
1- Discovering pain points and opportunities optimize the requirements. A prototype acts as an actual example
Observation helps identify pain points, bottlenecks, and of the suggested system, enabling stakeholders to engage with it
areas of improvement in the existing processes or and offer insightful feedback. The main purpose of prototyping is
systems. By observing stakeholder frustrations, to make it easier to explore and validate requirements by allowing
challenges, or workarounds, software development stakeholders to experience and visualize the user interfaces,
teams can address these issues through well-defined systems’ features, and behavior. Depending on the level of detail
requirements, thereby enhancing the overall user needed, prototypes can take many different forms including
experience. interactive wireframes, paper-based sketches, or functional mock-
2- Unbiased information ups. According to the research [8], based on the prototypes
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 5

provided by the software engineers, the stakeholders can give and be on the same page. Too many prototypes built
their feedback and propose some new requirements. Also, may lead to confusion among clients and developers
prototypes can be very helpful to detect errors and bugs or even a which put up more time in developing the next
little misunderstanding about a particular requirement earlier. By prototype before reaching the final prototype of the
actively including stakeholders in the requirement validation product.
process, prototyping as a requirement elicitation technique
promotes collaboration, reduces risks, and increases the overall
1- Limited stakeholder representation.
quality of the completed software system. Prototyping comes with
variety of advantages and disadvantages: Normally not all stakeholders participate in testing the
prototype. Thus, a subset of stakeholders who are
usually involved in prototyping plays a major role in
• Strength of prototyping technique. the validation and feedback process. These subsets of
1- Provide visualization of the system. stakeholders may result in overlooking important or
Visualization of the system via prototyping provides other perspectives and requirements from other
stakeholders with working previews from which they stakeholders, leading to biased decisions as it only
may understand the user interfaces, systems’ features rewards or gives profit for them.
and overall behavior of the system. Thus, the prototype
will be able to assist stakeholders to get a better grasp of • Opportunities in prototyping technique.
how the final software will look and function.
1- Flexible Iterative and incremental development.
2- Constructive feedback.
Prototypes are often repeated resulting in multiple
Prototypes offer a platform for the stakeholders to have versions of prototype. In each iteration, requirements
a firsthand experience with the system and provide can be honed and implemented from which
feedback. This feedback can cover a wide range of issues stakeholders can provide follow-up feedback. In this
from pointing out usability problems and making way any error or issue can be detected earlier and
suggestions for improvements to modifying explanation to stakeholders should be far easier via a
requirements after using the prototype directly. prototype which simulates what is actually happening.
3- Validation of assumptions. 2- Reduce development time.
Using prototypes, software development teams and Prototype is a working example which means it is
stakeholders can validate assumptions made during the operable and often is very close to the complete system
requirement elicitation process. Stakeholders can in terms of functionality. Thus, in a good scenario
verify whether their initial expectation and assumption where the prototype is accepted and is near to
match the system's actual capability and behavior by completion, it might take just a little bit of time in the
testing the prototype. development to improve the system before production.

• Weakness of prototyping technique. • Threats to prototyping technique.

1- High cost. 1- Misinterpretation of prototypes.
Although prototyping comes with a variety of benefits, Stakeholders may treat prototypes as fully functional
developing a working example of a system doesn’t systems, leading to potential misunderstandings about
come free. Depending on the number of prototypes the limitations and scope of the prototype. This may
required to collect complete requirements, the cost can cause uncertainty among customers as they assume that
fluctuate even higher. Thus, prototyping is not always the prototype is yet to be finished and does not convey
feasible, especially for large complex systems which the requirements that they wish for. False interpretation
increase the risk of loss in case of incorrect prototype of prototypes also leads to potential disinterest among
developed due to lack of experience or existing customers due to dissatisfaction when the actual final
requirements. product does not match the prior prototypes. On the other
2- Time consuming hand, a badly presented prototype might lower the
Prototyping may consume a lot of time in order to impression of stakeholders from the get-go which can
develop what can be considered as a working example affect the subsequent processes.
of the system. Furthermore, in order to achieve the final
product of the prototype, multiple prototypes will be
created along the process which progressively 2- Technical feasibility challenges.
improved toward the goal. Minor changes on the
Prototypes might showcase some interactions or features
current prototype will encourage more creation of the
that are impractical or difficult to implement in the final
prototype until it has fulfilled the requirements. Not to
system. Technical limitations or constraints usually
mention that in order for a product to be successful, the
contribute to such a challenge. Prior to the challenge, it
client and developers must share the same objective
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 6

is possible for stakeholders to feel disappointed or and presented to stakeholders to receive their feedback. This
frustrated when certain aspects of the requirements process will be repeated until a complete requirement is obtained
cannot be fulfilled in the prototype or worse, in the actual that is able to satisfy the stakeholders’ wants and needs. In each
product that is to be established. iteration, stakeholders will always be involved to provide their
3- Difficulty in maintaining consistency. constructive feedback.
On the other hand, we consider stakeholder involvement in an
Prototyping requires multiple changes and iteration
interview as moderate due to the limitation of stakeholder in
throughout the process. It is undeniable that it is
expressing their relevant opinion in a formal structured interview
challenging just to maintain coherence and consistency
where there are a set of questions being asked and they are
in the requirements. A small part or iteration of the
required to only answer it. The process of the interview itself is
prototype that changed is possible in giving
facilitated by the interviewer which means that the stakeholders
implications on previously established prototypes
don't have much control over the conversation in most cases.
requirements, requiring more thorough documentation
Lastly, observation has the lowest stakeholders’ involvement
and management by the developers.
due to the fact that during observation most of the time
Prototyping is a very detailed process that provides a working stakeholders do not do anything to contribute toward the
example for stakeholders to try and provide feedback on. Their requirement gathering process. Requirement engineers
feedback based on the experience using the prototype system is themselves have to observe, comprehend, interpret and analyze
valuable and accurate making prototype a very good requirement the stakeholders’ actions throughout the observation.
elicitation technique. However, the cost to execute it might need
to be considered beforehand since depending on the complexity
of the system and number of stakeholders prototyping might takes B. Accuracy of requirements gathered.
longer to finish due to conflicting feedbacks from stakeholders We deemed that prototyping has the highest accuracy since
that require more negotiations to be done. stakeholders are presented with actual working examples from
which they can gain a clear view and understanding of the system
being developed allowing them to provide a more comprehensive,
constructive and specific feedback.
As for interview technique, most of the time requirements
IV. COMPARISON OF REQUIREMENT ELICITATION gathered through it are reliable, however interviewee might be
TECHNIQUES anyone from a variety of background with different understanding
of the subject being discussed. Thus, some of the stakeholders
The primary objective of requirement elicitation is to ensure might not be well versed in the related field jeopardizing the
successful software projects by implementing various techniques. completeness of the requirements.
Previously in this document, we have discussed in detail three of Observation on the other hand is very ambiguous in terms of
the requirement elicitation techniques which are interview, accuracy of requirements. This is because being aware of the
observation and prototyping. In this section we will be comparing observer, stakeholders might act unnaturally. The accuracy of the
all three techniques in four vital aspects in determining the requirement is almost entirely reliant toward the stakeholders
suitable requirement elicitation technique, which is the which makes its accuracy questionable from the requirement
stakeholder’s involvement, accuracy of requirement elicited, cost engineer point of view. However, it is important to note that both
of execution and time needed for each technique. interview and observation have another advantage on its
capability in collecting subtle implicit information.

Technique Stakeholders Accuracy Cost Time C. Cost of execution

involvement Even though prototyping is the most promising technique, it
undeniably requires the highest cost to implement among these
Interview Medium Medium Medium Medium techniques. To develop a working example design or system can
Observation Low Low Low High be very costly depending on the complexity of the system.
Next, the cost of conducting an interview comes from a variety
Prototyping High High High High of aspects depending on the mode and method of its
The table above shows the general comparison of the three implementation. For example, online interviews will require good
requirement elicitation techniques in four different aspects. The network connection and suitable devices while offline interviews
reasoning will be discussed in detail in the following section. will incur transportation cost and accommodation cost in some
cases. The cost may rise depending on the number of stakeholders
to be interviewed and their geographical location.
A. Stakeholders’ involvement On the contrary, observation has the lowest cost since it only
Involvement of stakeholders is essential in ensuring good requires the observer to monitor the stakeholder by being present
requirements. In this aspect we concluded that prototyping has the at their working environment. There might be some cost for
highest degree of stakeholders’ involvement due to the nature of transport or accommodation but it's undeniably the lowest cost of
the technique where a working example is designed or developed the three mentioned techniques.
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 7

Lastly, the prototyping technique is an ideal technique that

D. Time needed to complete the process. provides high accuracy and stakeholders involvement.
However, it is not always feasible to be done due to its cost
Timeliness is vital in delivering a software system. In this and also it requires sufficient knowledge to develop an
aspect, the interview would be the quickest since it only requires acceptable prototype.
scheduling appointments with the stakeholders and conducting it
on the appointed time. It may even only take a few hours, however In conclusion, there is no single perfect requirement
considering that the time needed might fluctuate depending on the elicitation technique that can fit in all scenarios. Selection of
number of targeted interviewees we deemed the time as moderate which technique to be done precisely relies on the scenarios
among the three techniques. and environment of the projects itself. It is also common to
use multiple requirement elicitation technique to compromise
Next, in the aspect of time, observation is very vague as there's each of its disadvantages.
no fixed duration of observation since it purely depends on
complexity of the business process. However, observing a process
once or only done by a single person might not be sufficient,
leading to more time needed for observation to produce accurate REFERENCES
requirements. Due to the fact that time is one of its successful
deciding factors we concluded observation technique time cost [1] S. Sharma and S. K. Pandey, “Requirements elicitation: Issues and
high since the primary goal is to ensure accurate requirement challenges,” 2014 International Conference on Computing for
which certainly takes time. Sustainable Global Development (INDIACom), Mar. 2014, doi:
https://doi.org/10.1109/indiacom.2014.6828119.
Finally, the prototyping technique will undeniably increase
time taken in the requirement elicitation phase due to the need to [2] S. Sharma and S. K. Pandey, “Revisiting Requirements Elicitation
Techniques,” International Journal of Computer Applications, vol.
develop a working example to be presented to the stakeholders.
75, no. 12, pp. 35–39, Aug. 2013, doi:
On the other hand, prototyping may help developers to reduce https://doi.org/10.5120/13166-
time on development phase [3] since with a working example 0889.
ready, only improvement based on requirement needs to be done. [3] T. Iqbal and M. Suaib, “Requirement elicitation technique: -A
review paper,” International Journal of Computer & Mathematical
Sciences, vol. 3, no. 9, p. 1, Dec. 2014.
[4] S. Pandey and M. Batra, “Formal Methods in Requirements Phase
V. CONCLUSION
of
SDLC The Institute of Chartered Accountants of India (Set up by an
Throughout this document we have defined and explained Act of Parliament) NOIDA -201309, INDIA,” International Journal of
regarding requirement elicitation centralized around the three Computer Applications, vol. 70, no. 13, pp. 975–8887, 2013.
techniques which are interview, observation, and prototyping. We [5] S. Pandey and K. Mustafa, “Recent Advances in SRE Research,”
have emphasized its advantages and disadvantages through IJCSE) International Journal on Computer Science and Engineering,
vol. 02, no. 04, pp. 1079–1085, 2010.
evaluation using the SWOT analysis framework. Finally, we practice of successful
compared all three requirement elicitation techniques in four main [6] S. L. W, “Stakeholder analysis: a pivotal
projects,” in Proceedings of the Project Management Institute
aspects which is stakeholders’ involvement, accuracy, cost and Annual
time. Seminars & Symposium, Houston, Texas, USA, 2000.
One of the techniques, interview is widely used due to its [7] S. Tiwari, S. S. Rathore, and A. Gupta, “Selecting requirement
elicitation techniques for software projects,” IEEE Xplore, Sep. 01,
moderate costs while providing sufficiently accurate information 2012. https://ieeexplore.ieee.org/document/6349486
provided that its conducted excellently. However, it is hard to
[8] B. Suranto, “Software prototypes: Enhancing the quality of
cover all stakeholders’ requirements by using interviews alone requirements engineering process,” 2015 International Symposium
since it can be quite taxing especially if the system involves on Technology Management and Emerging Technologies
publics making it impossible to interview every stakeholder. (ISTMET), Aug. 2015, doi:
Thus, interviews would be most fitting for projects that have a https://doi.org/10.1109/istmet.2015.7359019.
specific group of stakeholders targeted.

Next, observation is the simplest technique and the lowest

cost to implement. However, its reliance toward stakeholders’
behavior makes its information rather questionable,

jeopardizing the requirements elicited from it. Thus, it would be

ideal to not only rely on observation but also integrate it with other
techniques such as interviews to validate any questionable
information.