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

Requirement engineering process.

So, in this particular session,
we shall have this topic to discuss.

The process to gather the software
requirements from the client, analyze and

document them is known as the requirement
engineering.

That is from the client,
from the stakeholder,

we are supposed to
take the requirement list.

And those requirements are to be analyzed
and should be documented in a proper way.

And that is falling in this requirement
engineering.

So, the goal of requirement engineering is
to develop and maintain sophisticated and

descriptive system requirement
specification document.

So, that is the main purpose of this
requirement engineering.

So, it is a four step process,
which includes feasibility study,

requirement gathering, software
requirement specification, in short we

usually call it as SRS and then software
requirement validation.

So, let us go for the feasibility study,
then we shall go for requirement

gathering, then we shall go for software
requirement specification and then we

shall go for So, in this
way we shall have

our separate slides
on each and every topic.

We are going with starting with our
feasibility study.

When the client approaches the
organization for getting the desired

product developed, it comes up with a
rough idea about what all functions the

software must
perform, and what or which all features

are expected
from the software to get implemented.

So, in the initial discussion with the
client, with the initial discussion with

the customer, we shall be getting that the
rough idea regarding the what are the

functions
the software should do, and what are

the features the software
should implement.

So, referencing to this information,
the analysis do a detailed study about the.

About whether the desired system and its
functionality are feasible to develop.

And that will be done in our feasibility
study.

Next one, we are going for the next one
that is our requirement gathering.

So, if the feasibility report is positive
towards undertaking the project,

then the next phase starts with the
gathering requirements from the user.

So, analysts and engineers communicate
with the client and end users to know

their ideas on what the software should
provide.

And which features they want the software
to include.

So, now they are going for the further
detailing.

Doing further communication with the
users, with the client.

So, that they
can get the idea that after

doing the feasibility
study, we got the report.

Let it be positive that we will be taking
this particular project.

So, now this recommend gathering will be
done more into the details.

So, that the software can be developed.

We know that what are the functionalities
to be implemented and what are the

features will be there in the software.

Next one is our SRS that is the software
requirement specification.

So, SRS is a
document created by system analysts after

the requirements are
collected from various stakeholders.

We discussed this this stakeholder what is
the meaning of this stakeholder.

So, stakeholder means those persons who
are positively or negatively affected by

the execution of the project.

So, SRS defines how the intended software
will interact with the hardware,

external interfaces, speed of operation,
response time of the system, portability

of the software across different
platforms.

What is the platform?

Platform means the software that is the
operating system and the respective hardware.

In combination of them we can call it as
the platform.

And then maintainability, speed of
recovery after crashing, security,

quality, limitations, etc.

So, all these things will be kept in a
proper documentation and that is our SRS.

So, the recommends received from the
client are written in natural language.

So, whatever the language you are
considering.

So, that will be written that one.

It might be English or some other
languages also.

But it is not a programming language.

So, that I can assure you.

So, it is the responsibility
of the system analyst

to document
the recommends in technical language.

So, that they can be comprehended and they
have been comprehended and used by the

software development team.

So, in this particular case, we can also
use some technical language.

So, that it can be comprehended and can be
used by the software development team.

So, that is the language of this SRS.

So, SRS should come up with the following
feature.

So, what are the features it should have?

So, user recommends are expressed in
natural language.

Technical requirements are expressed
in structured

language
which is used inside the organization.

And then design description should be
written in some pseudo code.

That is in some algorithmic form it will
be written in some pseudo code.

We know that in case of pseudo code it is
language independent.

We are not maintaining any kind of syntax.

What is the meaning of the term syntax
means the grammar?

That means, here
we will be writing this

particular recommend in some technical
pseudo code.

So, that the developer can implement that
one when the phase will come.

So, it will be written in some syntax free
pseudo code.

And then format of the forms and the GY
screens, the prints will be made.

And then conditional and mathematical
notations for DFDs and etc.

So, DFD means data flow diagram.

So, we are having a separate video on the
DFDs.

You can easily go for that.

And we are also having a separate video on
the pseudo code and all.

So, these are the different the SRS should
contain all these things.

Now, we are going for the last phase that
is the software recommend validation.

So, that is the fourth one.

What were the earlier three one?

So, first one was feasibility study.

We discussed that one.

The next one was requirement gathering.

And the third one was software recommend
specification SRS.

And the fourth one is software recommend
validation.

So, all after arranging all these things
in the software recommend specification.

So, after recommend specifications are
developed, the requirements mentioned in

the document are
So, user might ask for legal impractical

solutions or experts
may interpret the recommends inaccurately.

So, this results in huge increase in cost
if not nipped in the butt.

So, that is why recommends can be checked
against following conditions.

So, whatever the recommends we had,
we have maintained that one in the

properly documented way in the form of
DFDs, in the form of some natural

language, in the form of some pseudo codes
in our SRS.

But here I should have to check whether
really they are validated or not.

So, if they can be practically
implemented.

So, then obviously, we will be considering
that one.

If they are valid and as per functionality
and domain of software.

If they are any,
if there are any ambiguities, if there

is no ambiguities,
then obviously, you can take that one.

The validation will be successful.

If they are complete and if they can be
demonstrated.

So, these are the main features of this
software requirement validation.

So, let us go for one diagram.

So, here we are having the software
requirements.

So, now, in the
scenario based models, we can use

the use cases
where the users stories can be mapped.

In case of class models, we can go for
the

class diagrams and
the collaboration diagrams.

So, in case of class diagrams.

So, in case of.

V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-V-

That one, because in this particular
tutorial, we have not included any UML

chapter, because we are having a separate
tutorial on this UML.

So, there you will be
getting this detailing

idea
that how this diagrams will look like.

And also this DFDs will be discussing that
one in the next video.

So, what is the DFD and how the diagram
has to be drawn?

So, these are the software requirements
and these are the different models for

which the different diagrams are
applicable.

So, we have discussed that is the elements
of software requirement analysis.

Thanks for watching this video.