How To Gather Requirements | Agile Methodology

Summary

In 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

00:00

📝 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.

05:02

🗣️ 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.

10:02

📊 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.

15:03

🔍 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.

20:03

🔄 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.

Keywords

💡Business Analyst

A business analyst is a professional who specializes in gathering and analyzing business requirements, bridging the gap between IT and business stakeholders. In the video, the role of a business analyst is central, with the speaker discussing their core responsibilities, such as working with stakeholders to understand their needs and documenting business processes or system enhancements.

💡Gathering Requirements

Gathering requirements is a critical process in which a business analyst collects information about what stakeholders need from a system or process. This involves understanding their day-to-day roles, how they currently use or could use systems, and what their expectations are for improvements. The video emphasizes the importance of this process in the role of a business analyst.

💡Stakeholders

Stakeholders are individuals or groups who have a vested interest in the project's outcome. In the context of the video, stakeholders could be business owners, end-users, or decision-makers who provide input on system needs and requirements. The business analyst engages with these stakeholders to gather and analyze the information necessary for project success.

💡Interviews

Interviews are a common technique used by business analysts to gather information directly from stakeholders. This involves asking structured or unstructured questions to understand the stakeholders' needs, roles, and how they interact with existing systems. Interviews can be conducted individually or in groups, such as in joint application development (JAD) sessions.

💡Workflow Diagrams

Workflow diagrams are visual representations of a process or system, showing the steps involved and the interactions between different components. They are used by business analysts to document and analyze the flow of work, identify inefficiencies, and plan improvements. These diagrams help stakeholders understand the current state and envision the future state of processes.

💡Agile Environment

An agile environment refers to a project management approach that emphasizes flexibility, collaboration, and iterative progress. In the context of the video, business analysts working in an agile environment often interface with product owners and stakeholders to gather requirements and create user stories, which are small, manageable units of work that can be implemented in short development cycles.

💡User Stories

User stories are a tool used in agile software development to capture requirements from a user's perspective. They are short, simple descriptions of features told from the point of view of an end-user or stakeholder. User stories typically follow a template such as 'As a [role], I want [feature], so that [benefit].' They help guide development by focusing on the value provided to the user.

💡Change Management

Change management is the process of preparing, supporting, and helping individuals, teams, and organizations transition and adapt to new processes, systems, or technologies. In the video, the speaker alludes to a future topic on how business analysts handle changes in requirements, both in waterfall and agile environments, which is a critical aspect of change management.

💡Joint Application Development (JAD)

Joint Application Development (JAD) is a facilitated workshop approach to software development that brings together users and developers to improve communication, define requirements, and design system features. JAD sessions are often used in the gathering requirements process to ensure that decisions about the system or software solution are made collaboratively and with input from all relevant stakeholders.

💡Use Case Diagrams

Use case diagrams are a type of UML (Unified Modeling Language) diagram that visualizes a system's functionality and shows the relationships between actors and the system's use cases. They are used to capture the requirements of a system from the user's perspective, helping to ensure that the system meets the needs of its users.

💡Data Flow Diagrams

Data flow diagrams (DFDs) are graphical representations that show the flow of data through a system, illustrating how data moves from input to processing to output. DFDs are used by business analysts to understand and document the data requirements of a system, ensuring that all data interactions are accounted for and that the system design supports the necessary data flows.

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

google

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