How To Gather Requirements | Agile Methodology
Summary
TLDRIn this informative session, Sir Jeep, an experienced business analyst, discusses the crucial skill of gathering requirements in the business analysis field. He explains that the primary role involves working closely with stakeholders to understand their needs and document processes, whether for building or enhancing systems. Sir Jeep outlines various techniques for gathering requirements, such as interviews, chat sessions, interface analysis, observation, brainstorming, surveys, and reviewing past documentation. He emphasizes the importance of analyzing these requirements to ensure they align with the project scope and deliver value. The session concludes with a teaser for the next topic on handling changes in requirements in both waterfall and agile environments.
Takeaways
- 📝 Business analysts play a crucial role in gathering and understanding requirements from stakeholders to enhance or build systems and document business processes.
- 💡 The core responsibility of a business analyst includes working with stakeholders to identify their needs and how they utilize or could utilize systems.
- 🗣️ Communication with business partners and IT teams is key in the requirement gathering process.
- 📋 Requirement gathering techniques include interviews, chat sessions, interface analysis, observation, brainstorming, surveys, and reviewing past documentation.
- 🤝 Interviews are the most widely used technique, allowing for one-on-one or group discussions with stakeholders to understand their system usage and needs.
- 🤔 Analyzing requirements involves sifting through the input from stakeholders to ensure that the deliverables provide value and fit within the project scope.
- 📈 Tools like use case diagrams, workflow diagrams, data flow diagrams, sequence diagrams, and user stories help in visualizing and understanding the requirements.
- 🔄 Stakeholders' input must be analyzed to ensure that the system changes or enhancements align with the overall business value.
- 🌐 Surveys are useful for gathering feedback from a wide range of stakeholders, especially when they are geographically dispersed.
- 📚 Reviewing past documentation is essential to understand the historical context and evolution of the system or process being analyzed.
- 🚀 The next topic for discussion will be about handling changes in requirements in both waterfall and agile environments.
Q & A
What is the core responsibility of a business analyst?
-The core responsibility of a business analyst is to work with stakeholders to gather requirements, which involves understanding their needs and how they interact with systems or processes.
What are the two main areas a business analyst typically works on?
-A business analyst typically works on building or enhancing information systems and documenting business processes for business owners or stakeholders.
What are some common systems a business analyst might work on?
-A business analyst may work on internal systems within a company or on software solutions purchased by the company, such as Salesforce or other systems provided by various software and service providers.
What are the different techniques used to gather requirements?
-The techniques for gathering requirements include interviews, chat sessions, interface analysis, observation, brainstorming, surveys, and reviewing past documentation.
Why are interviews considered the most widely used technique for gathering requirements?
-Interviews are widely used because they allow for direct one-on-one communication, enabling the business analyst to ask detailed questions and gain a deeper understanding of the stakeholders' needs and system usage.
In what scenarios might a business analyst use chat sessions or joint application development (JAD) sessions?
-Chat sessions or JAD sessions are typically used in environments with fast-paced projects where multiple stakeholders from different departments are involved, and decisions about the system or software solution need to be made quickly.
How can a business analyst benefit from observing stakeholders using a system?
-Observing stakeholders provides the business analyst with a user perspective, allowing them to understand how the system is currently being used and identify areas for improvement or enhancement.
What is the purpose of using surveys to gather requirements?
-Surveys are a useful method for collecting feedback from a wide range of stakeholders, especially when they are geographically dispersed. They can help gauge user satisfaction and identify potential areas for system enhancement.
How does a business analyst analyze the requirements gathered from stakeholders?
-A business analyst analyzes requirements by ensuring they fit within the project scope and provide value to the stakeholders and the company. Techniques such as use case diagrams, workflow diagrams, data flow diagrams, sequence diagrams, and user stories can be used to understand and document the requirements effectively.
What is the significance of creating workflow diagrams in the requirements gathering process?
-Workflow diagrams help the business analyst visualize the current and future state of processes, enabling them to understand the gap between the two and ask intelligent questions that lead to well-documented requirements.
What shapes are commonly used in diagrams to represent different elements of a process, and what do they signify?
-Ovals are used to represent the start or end of a process, rectangles represent processes or actions, and diamonds represent decision points. These basic shapes help in creating clear and understandable workflow diagrams.
Outlines
📝 Introduction to Gathering Business Requirements
This paragraph introduces the topic of gathering business requirements, emphasizing its importance as a core responsibility for business analysts. Sir Jeep explains that business analysts work with stakeholders to understand their needs and how they interact with systems or processes. The goal is to document and comprehend the stakeholders' objectives and daily operations, whether it involves building or enhancing systems or defining business processes. The paragraph also touches on the different contexts in which a business analyst might operate, such as working on internal systems, purchased software, or supporting business partners with solutions bought by the company.
🗣️ Techniques for Gathering Requirements
In this paragraph, Sir Jeep discusses various techniques used to gather business requirements. These include interviews, chat sessions, interface analysis, observation, brainstorming, surveys, and reviewing past documentation. Each technique is briefly explained, highlighting their purpose and how they contribute to understanding system needs and stakeholder utilization. For instance, interviews allow for one-on-one engagement with stakeholders, while JAD sessions involve decision-makers in a fast-paced environment. Observation involves watching stakeholders interact with systems, and brainstorming is used at the project's onset to jot down ideas. Surveys are helpful for gathering feedback from a wide range of stakeholders, and reviewing past documentation can provide insights into previous enhancements or the initial building of the system.
📊 Analyzing and Documenting Requirements
This paragraph delves into the process of analyzing and documenting the requirements gathered from stakeholders. Sir Jeep explains that business analysts must sift through the numerous ideas and suggestions from stakeholders to ensure that the final deliverables are in scope and provide value. The paragraph outlines various tools and diagrams such as use case diagrams, workflow diagrams, data flow diagrams, sequence diagrams, and user stories that can be used to understand and document the requirements. The focus is on bridging the gap between the current state and the desired future state, highlighting the importance of asking intelligent questions and creating diagrams that help in understanding the system's operation and the stakeholders' needs.
🔍 Mapping Out System Workflows
Sir Jeep continues the discussion on understanding and documenting requirements by emphasizing the importance of mapping out system workflows. He suggests using basic flowcharting techniques to create diagrams that illustrate processes, such as making a cup of tea or coffee, as a way to practice analyzing requirements. The paragraph also addresses the use of specific shapes in diagrams, such as ovals for start or end points, rectangles for processes, and diamonds for decision points. Sir Jeep encourages business analysts to become familiar with these basic shapes to better comprehend and create workflow diagrams, which are crucial for understanding and documenting system requirements effectively.
🔄 Dealing with Changing Requirements
In the final paragraph, Sir Jeep teases the next topic of discussion, which is about handling changes in requirements. He mentions that as business analysts, dealing with change is a common aspect of the role, whether it involves changing systems or processes. The upcoming session will cover how to manage changes in requirements in both waterfall and agile environments. Sir Jeep encourages group members to ask questions and suggest training topics, promoting an active learning environment where sharing questions and ideas can benefit everyone in the group.
Mindmap
Keywords
💡Business Analyst
💡Gathering Requirements
💡Stakeholders
💡Interviews
💡Workflow Diagrams
💡Agile Environment
💡User Stories
💡Change Management
💡Joint Application Development (JAD)
💡Use Case Diagrams
💡Data Flow Diagrams
Highlights
Introduction to the essential role of gathering requirements as a core responsibility of a business analyst.
Explanation of a business analyst's role in working with IT systems and defining business processes.
Details on the use of various systems like Salesforce and how business analysts interact with purchased solutions.
Overview of several techniques for gathering requirements, including interviews, interface analysis, and observation.
Importance of interviews in gathering detailed and specific information from stakeholders.
Joint Application Development (JAD) sessions and their role in decision-making in requirement gathering.
The role of interface analysis in gaining practical experience with the systems being evaluated or enhanced.
Use of observation to understand stakeholder interactions with systems, providing insights into user behavior and system usability.
The utility of brainstorming sessions at the beginning of projects to generate ideas and outline potential enhancements.
Surveys as a tool to gather widespread feedback, especially useful in global teams.
Reviewing past documentation to leverage existing knowledge and avoid redundant work.
The significance of analyzing requirements to ensure they align with project scope and provide stakeholder value.
Discussion on how to use diagrams like use case, workflow, and data flow diagrams to visualize and analyze requirements.
Recommendations on creating user stories and requirement documents based on the information gathered from various techniques.
The importance of understanding both current and future states to identify the gap in requirements effectively.
Transcripts
[Music]
hi everyone i am sir jeep
you are in the in-demand business
business analyst in demand facebook
group you may also be watching this on
youtube
um
at least um twice a month if not more
week i come on here and i provide live
training for you guys um and the
opportunity to ask questions if you're
watching this on a replay or after the
fact please leave your questions if you
have any
in the comments area
and i will get back to you
um so today's topic is how do you gather
requirements okay so let me
typically when you're looking at job
descriptions or transitioning into a
business analyst role
lots of times you'll see in the job
description you know have the ability to
gather requirements and that's the core
responsibility as a business analyst
that you'll have is to work with your
stakeholders to gather those
requirements so you guys may be
wondering what does gathering
requirements even mean right so if you
think step back and think of a business
analyst role
primarily we're working on it systems
we're sometimes also working on defining
processes for our business owners or
stakeholders if you step back and think
about what it is that you're doing as a
business analyst right you're
either building or enhancing systems or
documenting business processes
all you're doing is gathering
information from your business folks who
know the systems and the business
they may not know the systems but at
least they know their business inside
and out so your goal as a business
analyst is always to document and
understand
what your stakeholders or your business
partners are trying to do right what is
their day-to-day role
how are they utilizing systems or how
could they be utilizing systems so
lots of times
as a business analyst you'll be working
on internal systems and then you may
also be working on systems that have
been purchased by the company
systems for example like salesforce and
you know there's many other uh systems
out there many companies that provide
software and so uh services and
solutions for companies to purchase so
if you're working as a business analyst
you may be working on enhancing existing
systems or building you know new systems
in-house for the company that you're
working for you may also be supporting
your business partners on a software or
a solution that has been purchased by
the company to support them okay i'll
pause there to see if there's any
questions and let me know if you guys
can hear me okay
any questions so far
no
okay
thank you ravi
so then let me share my screen i've
created a small powerpoint presentation
for you guys
so uh let's talk about uh you know how
do you gather requirements
so
what i just talked about is
in a nutshell as a business analyst what
you're doing is you're communicating
with your business partners most of the
time and also your it teams in
understanding what the system needs to
provide and what functionality will be
used
and how will
our stakeholders be utilizing some of
this functionality right
let me just minimize this okay
so the techniques in gathering
requirements there's many there's
typically
seven or eight
techniques that you can use as
to gather these requirements
some of these are listed here interviews
are the most widely used then we have
chat sessions interface analysis
observation
brainstorming surveys or review past
documentation and what that means is
these are different ways that you will
be going to your business stakeholders
or your you know key stakeholders and
trying to understand how they'll be
utilizing systems or processes right as
i mentioned interviews are the top most
widely used
mode of
us
gathering and working with our
stakeholders just because it allows you
to ask questions one-on-one right
often times
if you're working in the waterfall
environment you'll have a group of
stakeholders that you'll be working with
to gather these requirements right
and then if you're
working in the agile environment you're
typically interfacing with your product
owner and you may also be working with
stakeholders
as you know depending on the project
that you're working on
depending on how
your product owner is interacting with
the project team for example sometimes
if the product owner is not
widely available you may
be interfacing with stakeholders even in
the actual environment
so interviewing is
a process where you're meeting with your
stakeholders
sometimes in grip sessions sometimes
one-on-one and talking to them about the
system itself what are their daily needs
right how are they
using the system today is there a system
today that they're using how are they um
intent on using it what is their role
and after they're done using you know
performing their job function who's the
next person in line to use the system so
these are some of the questions that are
typically asked there's um i think in
our group there's a list of
interview questions for stakeholders
that you can find
but typically that's generally how
interviews go
interviewing your stakeholders and then
the second thing we have listed is chat
sessions typically as a joint
application development is what jazz
stands for and typically dad sessions
are bigger meetings where you're
including stakeholders from each
different maybe each of the departments
and typically the people that attend
jazz sessions are
are decision makers people that can make
a decision about the system software
solution and those decisions are
documented and we move forward jazz
sessions are typically in an environment
where um
there's lots of uh fast paced moving
projects um just so um and that's the
whole purpose you're inviting a lot of
your stakeholders in one room to make
those decisions
the next um way that you can gather
requirements is called interface
analysis which means that you're under
you you get access to the system you're
trying to understand and work
you may get a dummy account or you may
work in get access to the test
environment where you can
play around with the system and
understand how it's working today
that's a very powerful way of learning
the system every time even when i am
working and i'm getting introduced to
new systems or projects i always want to
get test access
or access to the test environments so i
can play around with it and understand
how the system's operating so
that's another way for you to gather
requirements observation is another
method which
lots of time people miss
in observation what you can do is ask
your stakeholders to just you know watch
to have
extra stakeholders if you can watch them
you know working in the system so for
example for working on enhancing system
x ask them if you know you could come
over or even on zoom um watch how they
work
in system x or y whatever the system is
um and that way you'll get to learn the
user perspective and how they're working
and interacting with the system okay
brainstorming is
another approach of gathering
requirements it's typically done at the
beginning of a project so typically you
know if
you're starting a brand new projects and
you're thinking about functionality or
things to include
you may be using you could use
brainstorming to jot down ideas
and that way
another way to
start your requirements process
surveys
is another popular method surveys are
used when you have stakeholders across
the globe and you want to know just
you know at the onset um very simple
things about the system like is it
user-friendly um if you were to make
enhancements what type of enhancements
you would make and i'm sure throughout
the course of your
professional or personal you know life
you've taken many many surveys right um
after you take a course you'll sometimes
have to take a survey after you
um you know when you purchase a product
they typically want to
have a survey to understand you know
how the systems you know or anything you
know to gather user feedback
so
you could use surveys
for example if you have teams across the
world and you know they're using the
system you just to get a gauge of how
they're feeling um and the usability of
the system you could use surveys for
and the last item i have is to review
past documentation
i can't tell you how many times people
miss this typically what you're working
on is a system or a solution that's been
in place for a while
there's been past enhancements or even
when they you know started building it
so there's lots of past documentation
that you can go back and review so i'll
pause there for a minute
to see if you guys have any questions
okay
so what do you do right um so uh you're
on a project you're working as a
business analyst you're you know trying
to understand and document
um your you know let's say you're
working on an enhancement
you go through one or two you don't have
to do all of these techniques right
if you're gonna pick at least one or two
you know at least one at the bare
minimum
but you could have two of these
techniques
so
you're
enhancing a system you're talking to
your stakeholders you're interviewing
them or you're looking at
i guess past documentation
how
the next thing that you want to do is um
analyze requirements so typically
um when we're working with stakeholders
they'll throw lots of things at you you
know like they'll say i want the system
to do this and this and this and that
and as a business analyst right you're
there to document the business need but
then you also have to make sure that
what you're delivering um provides value
and is in scope for what we're doing on
the project so what that means is when
you're working with your stakeholders
you're going to analyze what they're
saying to you and make sure that it fits
in
to into the project scope as well as
providing value to your stakeholders and
to your to the company as a whole right
so what does that mean
that means that there's different
techniques as i have on the screen here
use case diagrams or workflow diagrams
or data flow diagrams sequence diagrams
and even user stories to understand what
it is
and how the users will be
you know
interfacing so for example if your
stakeholders say that i want
i don't know
the system to
allow me to generate these types of
reports for example
you have to understand and make sure
that that report is a in scope and b
will provide value not just to that one
stakeholder or um but to many
stakeholders across the company
so just because your stakeholders are
saying that they want
some features what i typically do is
when i start a project i try to do
i use workflow diagrams pretty heavily
so i try to document what they're doing
today
and what their future state
functionality will look like
to be able to understand
the the desired functionality they want
where does it fit into the to the big
picture or the the future state
functionality
does that make sense you guys
yes yes okay and only when you guys can
do these you know analyzer requirements
only then can you put it in a brd if
you're working in the waterfall
environment
or if you're working in the agile
environment
you can then create user stories which
is
user stories are nothing more than
documenting requirements from a
user-centric approach
okay so just as a recap
as a business analyst
oftentimes you're asked to document
requirements how do you document those
requirements you um you know there's
different techniques as we talked about
interviews surveys
jazz sessions depending on
how your project team is set up what the
goals and objectives of
your project is you'll
pick to one to two of those techniques
to gather those requirements
gathering requirements is nothing more
than talking to your stakeholders about
their wants and needs so it's not like
um
something that's like a scary event in
your professional career it's just you
know talking to
your business folks and saying hey help
me understand how you do this and what
it is that you're looking to do in the
system
and after you understand what they're
trying to do go back and create workflow
diagrams which will help you understand
and acts even so once you create those
diagrams you know even if it's a
sequence flow diagram or data flow or
even workflow process flow diagrams
those will help you understand a how the
system works and also be
go back to your stakeholders with very
intelligent questions like
um what needs to happen next who does
this data need to go to
how will this you know
um
what what's the input coming where is
you know where is this data coming from
where does it need to go
so unless you try to map it out
right
you won't know what questions to ask and
if you're not asking the right questions
you're not documenting them properly and
then you're missing requirements and
that's the gist of it you can't expect
your stakeholders to answer every you
know question or you know tell you what
you need to document
that's your role as a business analyst
to understand
what their future state looks like and
in understanding their future state and
their current state you're documenting
that gap
from current state to future state
okay
have i confused you guys
uh sort of one request from my hand so
if you have a sample
with you if you can please show us that
will be really helpful
um
i can't show you samples just because um
i'm not privy to to disclose my
um
you know work documents but then every
document will be different so it's not
that i can talk to you about you know
show you a brd
um and show you how those requirements
were gathered because it's a process
right
it's not like you can take a template
and copy and paste it because every
system is different every need is
different every company is different
so um for that reason i
can't
you know that's not going to be
beneficial to you
yeah
yeah
yeah
okay
um but um if you understand how
to so um
the best way i can recommend is um
try to create workflow diagrams um like
you know how you make tea or a cup of
tea or a cup of coffee and try to doc
you know using you know
the basic techniques
uh of a decision point or process flow
like the rectangle shape and the diamond
shape
if you can
create a workflow diagram on how you
make coffee or something and then from
once you create that workflow diagram
try to write requirements on that so the
user shall get a cup or something
you know just think of it
turn it around and make it seem as if
you're writing requirements for
for making a cup of tea or making a cup
of coffee
that's the best way
to help you analyze
requirements
does that make sense
yeah thanks
and if you're looking for samples just
business requirements document and
you'll find lots of samples what that
will do is at least it'll give you the
different sections that are in the
requirements
so at least you know what sections that
you you know you need to document when
you're working on your brd
if you're working in the agile
environment
okay
whatever
i have a question
when we draw diagrams we use certain
shapes like circle or rectangular or
triangle do they have some uh meaning
like uh yes
yes
so um usually an oval
is either a start or an end shape
the rectangle is for a process
the diamond is a decision point and
when you create diagrams
these are these are the most three or
four are the most basic shapes that
you'll be um looking at and again
um
there's many more like bpmn has lots of
very detailed um and very specific
things that they use in diagrams but if
you can understand just the very basic
ones which is the oval the rectangle and
the diamond
you should be good to at least
understand when you look at a workflow
diagram and also start creating them on
your own
okay so diamond represents decision
rectangle goes for process and over is
for start or end
okay yeah
that's a great question
okay any other questions you guys
okay
awesome
all right so i think um in our group we
said that the next um
uh topic is uh
i believe we said that we there was um
change in requirements how do we deal
with
change and requirements so i think um
probably not next week the week after
we'll talk about
what you do when you have change in
requirements
in the waterfall scenario as well as in
the agile environment how do you deal
with change
and
as a business analyst all you're doing
is changing either systems or processes
so
you guys should be very very comfortable
and
familiar with
how change happens so that's another
that's the next topic that we'll talk
about
again this group is for you guys
if you have questions um or if you want
something doesn't make sense let me know
and we can create that into a training
topic because most likely if you guys
have questions on something
other people are in the similar
situation
and want to know so feel free to give me
training topics uh post your questions
in the group the more active you are in
the group the more that you learn so
uh please be active let me know what
other training topics you'd like me to
talk about
okay
with that said i hope you guys have a
great rest of your weekend thank you
everyone
bye
bye
you
تصفح المزيد من مقاطع الفيديو ذات الصلة
3 - Peran dari Business Analyst
Requirement Classification - 4 different types of requirements you need to know!
How to Document Requirements - How to write better requirements [Business Analyst Training]
1 - Pengenalan Analisis dan Spesifikasi Rekayasa kebutuhan
Data Science Life Cycle | Life Cycle Of A Data Science Project | Data Science Tutorial | Simplilearn
Software Testing Tutorial #7 - Software Testing Life Cycle (STLC)
5.0 / 5 (0 votes)