---
Video Title: Requirement Elicitation Techniques
Description: Requirement Elicitation Techniques
Watch more Videos at https://www.tutorialspoint.com/videotutorials/index.htm
Lecture By: Mr. Arnab Chakraborty, Tutorials Point India Private Limited
---

Recommend elicitation techniques.

So, how to gather all these recommends?

So, in this video, we are going to discuss
on that.

Recommend elicitation
is a process to find out

the requirements for an
intended software system.

That means, the software
system which is intended,

that means, which is
going to get developed.

And from where you are going to gather all
these requirements?

From the stakeholders.

That means, who are involved in this
particular project.

So, by communicating with the client,
end users, system users and others who

have a stake in the software system
development.

So, from them, we are supposed to gather
all these recommends.

So, there are various ways to discover
these recommends.

So, now, we are going to discuss some of
them, the major ways.

The first one we are going to discuss is
the interviews.

So, interviews are strong medium to
collect requirements.

Organization may conduct several types of
interviews.

So, some of them are structured
or closed interviews, where

every single information to
gather is decided in advance.

And they follow a pattern and matter to
discussion, to have the discussion formally.

Next one is the other way.

Next one is the non-structured profile.

So, next one is the non-structured.

So, in case of structured,
we know that what

are the information you
are supposed to gather.

So, we are having that particular list.

And through this interview, we are
gathering all this information.

So, next one is the non-structured or open
interviews, where information together is

not decided in advance, and more flexible
and less biased.

So, that is another way to gather our
information through interviews.

So, another one is the oral interviews.

Next, written interviews.

One to one interviews, which are held
between two persons across the table.

Then, group interviews, which are held
between groups of participants,

they help to uncover their missing
requirements as numerous people are involved.

So, we can go for one to one meeting,
we can go for group discussion,

we can have the written interviews,
we are having the oral interviews.

So, multiple different ways to conduct
such interviews.

So, next one is the surveys.

So, organization may conduct surveys among
various stakeholders by querying about

their expectations and
requirements from the,

from the upcoming going
to be developed system.

Next one is the questionnaire.

A document with predefined set of
objective questions and respective options

are handed over to the all stakeholders to
answer them and which are collected and

then it will get compiled to get the
ultimate requirement list.

A shortcoming of this technique is that,
if an opinion for some issue is not

mentioned in the questionnaire,
the issue might be left unattended.

So, this is the one of the shortcoming we
are having.

So, making the questionnaire is a big
challenge.

Here, we should cover all the expected
recommends.

So, now we are having the task analysis.

So, team of engineering
and developers may analyze

the operation for which
the new system is required.

So, this new system will have which kind
of functionalities?

What are the tasks to be implemented?

So, from there, we can also generate our
recommend list.

If the client already has some software to
perform certain operations, it is studied

and recommends of the proposed systems are
getting constructed, domain analysis.

So, every software falls into some domain
category.

The expert people in the
domain can be a great help

to analyze general and
some specific recommend.

So, depending upon the domain in which the
software will be working.

So, we are having some prior experience,
prior idea.

If we have conducted such projects earlier
in that very respective domain,

then from there, we can easily collect all
the recommends there.

Next one is the brainstorming.

If an informal debate is held among
various stakeholders and all their inputs

are recorded for further recommend
analysis.

So, that is one of the method is known as
brainstorming.

So, in this way, we have defined,
we have discussed what are the main ways,

the main means to calculate or say to
collect this recommend from the stakeholders.

Next one is the prototyping.

Prototyping is building user interface
without adding detail functionality for

user to interpret the features of intended
software product.

So, in case of prototype, we are just
making the miniature version of the

software, where the main functionalities
are getting implemented, not the all

functionalities, it is not the full
version of the software.

So, that prototype that
is the minimum or the

miniature version of the
software can be developed.

It helps giving better idea of recommends.

So, if there is no software installed at
the client's end for developer's

reference, and the client is not aware of
its own recommends, the developer creates

a prototype based on initially mentioned
recommends.

The prototype is shown to the client and
the feedback is noted.

The client feedback serves as an input for
the requirement gathering.

If the client is not having
such software pre-loaded on

the system, so from here
we can start our discussion.

In that case, we can develop
one prototype software in

the domain in which the
software is going to be developed.

And on this particular
prototype, we can have a

discussion after giving the
demonstration to the client.

We can get the feedback from the client.

What are the add-on features the client is
actually demanding?

What are the other
features the client is want

to want to deduct from
the existing prototype?

So, in this way, we can
have a communication in

between the client and
respective developing team.

So, that ultimately the recommend list
will get confirmed and it can be formed.

Observation.

A team of experts visit the client's
organization or workplace.

They observe the actual working of the
existing install systems.

They observe the workflow at the client's
end and how execution problems are dealt.

The team itself draws some
conclusion which aid to form the

requirement expected from
the software, for the software.

So, now in this case, you see this is
known as the observation.

So, the respective development team will
be visiting the client site and if there

are some existing software are there on
the client machine.

So, they will observe how
the client is interacting with

the software and what are
the difficulties they are facing.

So, that is why they are going for the new
software development.

And if the client is not having
any pre-installed software,

so they might be doing
the job in some manual way.

So, they also observe that how this manual
processes are getting carried out So,

from there, they will
have a communication with

the client and they will
make one recommend list.

So, here in this particular, in this
particular flowchart, we have discussed

that how this elicitation of recommends
can be done.

So, elicit recommends, so that is the
starting state and that is the final state.

So, if you consider this one as the
activity diagram, so it is the activity

diagram you can consider.

Otherwise, you can just consider This one
has a flow chart, but it is not a flow

chart because flow chart does not have
such initial state and final state.

So, let us consider this one as activity
diagram.

So, this elicit recommence, this particular
process has got elaborately demonstrated.

This one has got elaborately demonstrated
here.

So, in this way, we are having this,
we would say, it is version 1.0.

It is a version say 2.0 and it is having
the version for this This one for say

another version for this.

So, now this one has got elaborately
explained here.

So, conduct meetings,
make lists of functions

and classes, make
lists of constraints, etc.

Then formal prioritization, yes or no.

If it is yes, use QFD to prioritize the
requirements.

So, informally prioritize the
requirements, if the priorities are not

suggested by the client or not has been
decided.

Then create use cases.

What is the use case?

You can go for our UML tutorial,
which I have presented there.

So, we can also know the what is the use
case.

So, use case, this particular word, use
case means the functional requirements.

So, for each and every use case,
one process has to be generated.

So, that is nothing but representing one
functional requirements of the software.

And that is the finishing step.

So, this one actually we are having.

So, now there is the branching.

Now, a creative case can have this
respective flow.

So define actor.

So, what is the actor?

Who is the initiator of the use case?

What is actor who is the initiator of the
use case?

It would be honor as the actor.

Then write scenario and complete template.

And this write scenario can be also a
parallel.

So, in this This way, you can have this
detailing of this create use cases.

So in this particular
video, we have discussed

that how these
requirements can be elicited.

So that is eliciting of our requirements
in our software development process.