[Top 80] Business Analyst Interview Questions and Answers

hello there

if you have a business analyst interview

coming up shortly

then this is the video for you over the

last two years

we have published several videos on

business analyst interview preparation

we have merged the key questions into

this single video

we have covered 80 plus questions

ranging from stakeholder management

requirements agile methodology sql to

testing in this video

this video is ideal for your preparation

just the day before your interview when

you are short of time for it

go over this video and attend the

interview with confidence

the video is split using chapters for

easy navigation to your interested

section

if you have not already subscribed to

our channel please go ahead and

subscribe to our channel

and hit the bell icon we have lots to

cover

so let's get started

do you have a business analyst interview

coming up shortly

if so this is one of the videos for you

in this video we are going to cover the

top eight interview questions

pertaining to stakeholders identifying

and

engaging stakeholders is the vital part

for the project's success

and one of the key activities for a

business analyst

and hence interviewer would be keen to

know the list of stakeholders you have

interacted with

how you identified them and also the

challenges you faced while interacting

with them

we are going to cover these questions in

this video so

stay tuned if you have not already

subscribed

please go ahead and click on the

subscribe button and the bell icon

so that you are notified when we post a

new video

and we post regularly on business

analysis interview preps skills and

techniques

okay we have got a lot to cover so let's

get started

as always we will use a simple case

study which will

make the concepts easy to grasp rahul is

a ba

working with a client running a

restaurant called wagon gardens

the client is looking for a mobile app

which will allow their customers to book

a table

let us use the simple case study and see

who the stakeholders for this project

are how to identify them and the

challenges faced while interacting with

them

question one who is a stakeholder

stakeholder can be defined in simple

terms

as a party who will be impacted with the

change

they can be classified under two

categories

who receives the benefit and who will

deliver the change

who receives the benefit these are the

end users

customers business unit managers

operation team manager and so on

and who will deliver the change this is

the project team

ranging from project managers developers

testers trainers and so on

moving on to question number two who are

the list of stakeholders you have worked

with

this question is asked by the

interviewer to know the depth of your

interactions

we can cover the various stakeholders

here again

look at from our classification earlier

for the first category who receives the

benefit

it comprises of business unit manager of

the unit which gets benefited

in our example it would be the sales

department manager

who would be benefited by this change as

it would help to streamline

and ease stable booking for the

customers which should result in

increase in the number of visitors

boosting sales

and also helping saving cost by reducing

the number of people

allocated for taking phone reservations

the next would be the customers in the

example again

the customers who have to call and wait

for making the table reservations can do

so

just with the touch of few buttons in

their mobile and can get a table booked

with

instant confirmation sent to them

this solution would also benefit the

staff at the hotel

who are also using the staff and of the

application

for viewing the customer reservations

all the manual tasks for

checking the availability and making the

list of reservations for the given day

have all been automated and this results

in

increased staff efficiency

subject matter expert they are usually

part of the business unit operations

team

who have been working on the current

system and process

for a considerable amount of time and

are usually

experts and can provide guidance on the

current state

and also help to identify problems and

provide

recommendations on the target state

the last category is regulators

they are regulating body who ensure

compliance in our example

they may not be appropriate but just

wanted to list

as they are also a key stakeholder

so as part of the requirement gathering

sessions

the above stakeholders are your key

people you need to engage

and gather the requirements as you would

be working to satisfy their needs and

objectives

coming to the next category who delivers

the change

this includes the business sponsor who

is responsible for funding

and delivering the change and is your

key stakeholder

to engage when you are stuck or you need

guidance

and also sponsor would help in

identifying the stakeholders

next we have the support business units

like legal and marketing units

they will also provide further guidance

on shaping the change

to ensure we are covered from all the

angles

the rest of the people are what is

generally termed as the project team

project managers can be one or more

based on the scale of the project

they ensure the project gets delivered

as per the deadline

and are responsible for the plan

then we have the developers and testers

to develop and test the software

in accordance with the functional

requirements

lastly the trainer who is responsible

for training the staff with a new system

in our example trainer can be a senior

person in the staff

who would be responsible for training

the staff with navigation and working of

the new system

and also creation of standard operating

procedures

ba works with them by providing working

screenshots of the system

and also help to draft the standard

operating procedures

this covers more or less the list of

stakeholders

and when you are explaining you can use

your project examples and go over

question number three how do you

identify stakeholders

this is another commonly asked question

the interviewer would ask once you join

the project

what would be your approach for

identifying the stakeholders

listed below are a few techniques first

one

contacting business sponsor you can get

a list of stakeholders

by contacting the business sponsor you

can also check with the project manager

who would be able to help you with the

stakeholder list

second one organization charts

you can use the organization charts of

the impacted business unit

to identify the stakeholder list

third one process models

in complex environment where the process

is handled by multiple teams

if you can look at the process models it

would have to identify the impacted

teams

fourth one document analysis

if you look at the existing documents of

your organization

you can get the stakeholder list from

there

fifth one also when you are meeting the

identified stakeholders

they will also provide some names during

the discussion

and that is another source of getting

the impacted stakeholders

in our case study since it is a small

team of people

the business sponsor in our example

would be the owner of the restaurant

chain

who would be able to provide the names

of the managers

from sales and operations teams and also

based on the discussion with them we can

get additional names

moving on to question 4 what would

happen if you miss a key stakeholder

the interviewer might ask since there

are a lot of stakeholders in a complex

program

and missing one of you is possible and

what do you think will happen if

we miss again it's a good question

which emphasizes on the stakeholder

management

the answer is the solution which we are

developing

may not go live until the requirement of

the missing stakeholder

is taken care of causing delays and it

may also result in development

and testing rework as it may have an

impact on the existing functionalities

let us take an example from our case

study

what if we did not engage the operations

team on the ground

who is involved in seating of the

customers

their requirement could have been to

have a screen which shows the list of

reservations for the given day and the

allocated table numbers

in case this is not built even though

everything is ready from a customer

perspective

we still cannot go live with the

solution until this is built

this would result in developing the

screen near to the goal life

causing delays and reworks hence it is

very

important to identify all the impacted

stakeholders at the beginning phase of

the project

question number five what is a racy

matrix

racy matrix stands for responsible

accountable

consulted and informed it provides a

view of the responsibilities of the

involved stakeholders

let us take the requirements task in the

table as an example to walk through

first one is r which is responsible

this indicates the person who will be

performing the task

as you're all aware business analyst is

a person

who will be gathering and documenting

the requirements

hence in the table if you can see under

the requirements task

it is marked as r for the business

analyst

next is a or accountable

this is a person who is accountable for

the task

in our example business analyst is

responsible for gathering and

documenting the requirements and the

project manager is accountable

to ensure it is done within the agreed

timelines

project manager is ultimately held

accountable and answerable for the

successful completion of the task

next in the line is c which stands for

consulted

this stands for the stakeholders who

will be asked to provide

information or guidance about the task

in our example sma group is marked as c

as they would be the participants of the

requirement gathering sessions

and the ones who provide the

requirements to the business analyst

next in the list is i which stands for

informed

this is the next group of stakeholders

who need to be informed

in our example i have marked the

technical lead and test leads as

informed as they have to be kept

informed about the completion of the

requirement gathering

question number six what is a

stakeholder matrix

stakeholder matrix is a list of

stakeholders

as you can see on the slide it has the

following details of the stakeholder

like

name role they contact details

impact to them due to the change and

also their influence to shape the change

let us look at the example matrix

created for our case study

we have john who is the restaurant owner

and sponsor for this project

who has high impact and high influence

you have to work closely with him and

ensure you have his agreement and

support on all aspects of the change

next we have jane who is the operations

manager

the change has high impact on her as she

and her team needs to adapt to the new

ways of looking

up at the reservations and using the

tool to seat the customers

but she does not have high influence

however she and her team are also key

end users of this

staff side of the application and rahul

rba from the case study

should engage and understand their needs

and interests

they can become the goodwill ambassadors

for the change

next up in the line we have sean who is

one of our

chefs and one who gave a tour of the

kitchen and

walked through of the menu when rahul

visited the restaurant

as there is a next change proposal to

enable online delivery

but from the current change there is not

much impact to sean

and hence from an impact perspective we

have

none and also he has low influence

he just have to be kept informed at the

most on what is happening on the change

then we have kelly who is the finance

manager

she has no impact directly due to the

change

but has high influence as she holds the

budget

the ba should meet and ensure she is

believed and

rally up her interest in this change

question number seven what are personas

personas are fictional characters which

represent your typical customers

they are helpful to understand the

customer's needs

and build the product accordingly first

off

personnels will be created based on the

brainstorming ideas by the internal team

and post that research is conducted with

the actual customers

to validate the team's assumptions using

a number of requirement gathering

techniques

identifying and validating the needs of

the personnel

are very important to ensure we are

building the product

which satisfies their need let us take

two personnels for example

first one the office manager

this is a typical manager who has number

of team members reporting to him

there would be quarterly or sometimes

monthly team outings

and the manager is responsible for

looking for the fun places

to have a team lunch or dinner their

needs

are quick snapshot of the service

offerings

and also a receipt of the bill emailed

to them

so that they can do claims for

reimbursement

as all the outings are built to the

company

second one is the family man who wants

to book on the weekends for a brunch

lunch or a dinner he does not care about

the digital copy of the bill

but is very keen on the services offered

for

the kits and the seating arrangements

if you see just going at the high level

we have got two requirements

first one soft copy of the bill to be

emailed as a pdf

second one the service offerings should

be shown in the booking app or the

website

again these two are just assumptions and

have to be validated

based on the actual customer research

moving to the last question in the

series question number eight

tell me about a time when you managed a

difficult stakeholder

this is a very common question and i

have just listed two of the common

scenarios i bet you would have faced one

of these in your project you have worked

on

the first one is the conflicting

stakeholders

this is very commonly faced where the

key stakeholders are not agreeing with a

decision or an approach

and without their agreement we cannot

move forward

one of the things which works in this

scenario is

meeting them separately and identifying

their concerns

and work on mitigating the same

in our case study let us consider a

scenario

where the sales department head wants to

only focus on having the website or the

application

for the customer to make the booking but

the operations head wants to have

a fully functional staff facing portal

to help the staff

for which the sales head feels is a

wasted effort

rahul rba can meet both and try to

facilitate an agreement

as you see both of them from their point

of view are right

here rakhi can meet them separately and

understand their concerns

and explain a workable approach which in

this case can be

in addition to the customer facing

website and application

a minimalistic staff facing portal with

only some two to three key functions can

be considered

this would be a win-win situation for

both the parties

second one is unavailability of

stakeholders

this is a very common problem you invite

the key stakeholders for meeting and

they don't turn up

they don't return your phone calls or

your emails

there are two approaches for working

through this situation

the first one can be in the

communication to the stakeholder

whether it is an email or a voicemail

you can explain the importance of the

project

and the impact and the benefit the

change will have on their department

this usually works by getting their

attention

second one can be approaching

to connect you with their deputy or any

other team member

who can help if they are busy at the

moment

this is a common issue when dealing with

senior stakeholders

and the about two approaches work like

charm

use your project experience and see if

you can link them to

these two categories while answering

hello there do you have a business

analyst interview coming up shortly

if so this is the video for you as you

know

a key responsibility or a skill for a

business analyst

is to elicit document and maintain

requirements and this video is going to

help you to discover the top

9 commonly asked questions in business

analyst interviews

on requirements so that you are well

prepared

to make it easier for grasping the

concepts and the answers

we're going to use a case study in this

case study uh

a movie theater chain called xyz cinemas

is looking to build a digital channel

for allowing the customers to book their

movie tickets online

rather than calling up the customer care

or standing in the long queues and

getting their tickets

at the ticket counter so we are going to

use this

example case study for answering all the

questions

question number one how do you define a

requirement

as per babblock version 3 a requirement

is defined as a usable representation

of a need to simply put a requirement is

articulation of a business need for

solving a problem or capitalizing on a

business opportunity

this representation is actually required

for the engineering team to develop the

solution

accordingly to meet the business need

i've listed few of the examples here so

these are

different types of requirements which

we'll be covering in this

video i just listed it here to

give you a view of the requirements so

number one

sales department needs a digital channel

for allowing customer

customers to book their movie tickets

online basically it's expanding on the

case study

then the system shall display the

available seats for a movie show

systems shall allow the customer

customers to select the available seats

a system should respond within two

seconds of a user's input

a customer can book a maximum of 10

tickets

at one time so these are all different

statements

as i was stating earlier you know these

are all different types of requirements

which we'll be

covering shortly the nature of the

representation may be a document or set

of documents and it

varies depending on the circumstances

and the methodology used in developing a

solution

we're going to cover this in question

number nine so

stay tuned

question number two what is the

difference between a

business and a functional requirement

this is one of the tricky question

which is asked in the interview i'll try

to simplify it

using the below two tables first off

business requirement business

requirements are

basically representation of a business

need

goal objective or outcomes it represents

the what

example sales department needs a digital

channel

for allowing customers to book their

movie tickets

it's very high level and it just

represents

what is required by the sales department

it doesn't give guidance on how it can

be achieved

it just represents the what functional

requirements

on the other side they describe what

a system must do to achieve the business

requirements

it represents the how example

the system shall display the available

seats

for a movie show the system shall allow

the customers to select the available

seat

ideally it talks more on how

to meet the business requirement and you

can see

it kind of ties back into the business

requirement

question number three what is a

non-functional requirement

so this is this question can be asked as

a standalone question

or it can be also stated as can you tell

the difference between a functional

and a non-functional requirement so

we're going to cover that in this slide

non-functional requirement is a quality

requirement or a constraint

to the solution so it covers the

following aspects

so first one is performance so what

should be the response time

for a system to respond to a user's

input so that is captured as part of a

non-functional requirement related to

performance second one would be security

how

secure the system or the solution should

be

third one would be the reliability so

there are a few applications or systems

which should be

up all the time so it can we can state

that the system

should be available 99 of the time

so this would be a reliability uh

non-functional requirement which can be

captured

then the next one would be usability how

uh how easy it is for the users to use

the

system on the solution which we're

developing the next one would be

maintainability

how easy it can to maintain this

solution and on the last one would be

related to portability so these are some

few aspects which we are

going to document as part of as a non

nfr which is non-functional requirements

for the solution which is being

developed so let's

look at an example the system should

respond within

two seconds of a user's input so which

is a performance

nfr so as we discussed

uh in the previous slide regarding the

functional requirement

for the system to display the

available seats so if you try to put it

together

so a customer should be able to click on

a movie show and within two seconds the

system should

show them with a list of available seats

so that's how we are

you know tying it together to have a

great customer experience

question number four what is a business

rule

this is a question where most of the

people get it wrong

uh so let me try to simplify this

as per babblock version three a business

rule is a specific

testable directive that serves as a

criterion

for guiding behavior shaping judgments

or making

decisions that's a little complex

definition

but to simply put a business rule

is a criterion or a constraint which has

to be

followed by the solution or the system

which we are

building so for example the xyz cinemas

they had a business rule that a customer

can book only up to

a maximum of 10 tickets at a single time

while calling up the customer care or

standing

in the uh line at the ticket counter

so this ensured that you know there are

plenty of tickets available for

everyone so this business rule has to be

taken into consideration while uh

developing

this digital or solution digital channel

so this gives rise to a functional

requirement for restricting the number

of seats which a customer can book at a

single point of time

so for example it can be stated as such

like this the functional requirement

that

the system should not allow the

customers to select more than 10

available seats

so this is a restriction which we are

capturing as part of

a functional requirement which was

basically divide

sorry derived from a business rule

question number five what are the

requirement elicitation techniques you

have used in the past

i can bet you 100 percent that this

question

will be asked in each and every business

analyst

interview the reason as i stated earlier

elicitating requirement is one of the

key skill and query responsibility

of a ba and the interviewer would

definitely love to hear

how well you have done it in the past

and also what are the different

techniques which you have used

i've listed most of the commonly used

techniques in this slide and we're going

to cover

uh them one by one the first one is

the workshop this is one of the highly

recommended

technique for gathering high quality

requirements in a short span of time

i've already made a video on how to run

a successful workshop

and gather requirements in less than one

session

you can check out in the link below in

the description link below

so uh taking example of xyz cinemas if

you want to

uh perform a you know capture

requirement

so using workshop technique then you

have to invite all the key people or

smes from

the sales department you know customer

care department

ticket counter finance so all the key

people from different

departments who are involved in this

particular digital solution

so you can get everyone into a single

session

in a room it can be a few hours or even

it can be a day

if they are spread across it can be done

by a video conferencing or web

conferencing so you have all the

participants and you can get

the requirements uh on their views on

how the digital solution would be

and it can be captured and you know for

further

solution development second one is the

intro interview technique so in case if

you're not able to get

all these different people from

different departments

at a single session then you can

schedule separate interview sessions

with

each of them and try to gather the

requirements

which they need from this digital

solution so it can be done on an

individual basis and if that

two or more people available it can be

done as a group

interview as well so again this is also

one of the commonly used

technique for capturing uh requirement

or elicitating requirements

the top one would be observation uh it

can be passive or active so observation

if you take an example

uh you can walk down to the ticket

counter and and you can see how

the staff is getting the request from

the customer

and issuing the tickets like it can show

which seats they want

uh how the customers select so all these

things can be

observed and it can be translated

uh as a requirement for the digital

channel to kind of mimic this uh

process so there as i stated that two

types of pa

ah observation passive and active

passive is

you just stand there and observe and try

to gather as much information

or requirements and active as you stand

there

observe but now you can ask question to

the staff who's issuing the tickets or

who's doing it's

like why are you doing it this way is

there a reason

you know it provides more insight and it

can be

kind of translated to the requirements

for the digital

channel the fourth one would be the

document analysis so this can be

the documents which are available on the

process it can be the procedures

it can be the business rules so the

business rule which we kind of spoke

about in the previous question

would be uh you know would be found out

from this document analysis technique

and it can be translated to a functional

requirement

the next one would be the focus groups

and the brainstorming

they're more similar to workshops and

it's again

done in a similar way brainstorming is

more of

taking one item and trying to get

the ideas and the views from people and

kind of ranking it them

and then translating into requirements

and also the

priority of them the next one would be

the process analysis

so the process analysis is

looking at the looking at the end-to-end

process

if it's already one if it's already

there if not creating one and then

meeting up with the stakeholder and

showing them okay this is the process

flow

what all the uh things you need from a

digital solution which you are building

okay so this is also a good way of

capturing the requirements

looking at the end-to-end process so you

don't miss out

on anything the next one would be

prototyping again

if let's say if you want to look at the

detailing of the digital solution you

can do a mock-up

of the screen navigation flow and then

you can walk up to the stakeholders and

ask

okay in the screen what all the elements

do you need

is this better or do you need a

different color to kind of

sync up with your brand so all those

detailing uh

can be achieved using the prototype

technique the last one would be surveyor

questioner

this is again used only if you want to

collect

the response from a huge number of

stakeholders for example

if you want to get a view of which of a

feature would be beneficial

for the customer so you can just draft

few of the

questions and send it across to the

entire

sales department or customer care

department and then they can

select the options and then you can get

it back and that can be used

for framing the requirements and also

prioritization

so these are some few uh techniques

which i've covered

definitely this is a question which

would be uh coming up

so this can be used by

you know you can answer these questions

by using some experience from your

previous projects

question number six what is the

difference between verification

and validation of a requirement another

tricky question

so verification refers to ensuring that

the requirement meets the quality

standards

that is whether the requirement is clear

is it consistent with other requirements

there's no contradiction

whether the requirement is complete

whether it is

testable whether it is unambiguous

and also whether it's understandable to

all the stakeholders involved the

development team the

testing team so it ensures that the

the quality of the requirement is

is good enough for the uh the

engineering team to proceed with it

validation on the other hand refers to

whether the requirement

is kind of aligned to the business need

goal

or outcome and whether it really

supports

the needed value so let's say in our

example if we take a requirement which

talks about allowing the customers to

book refreshments

uh over a digital channel it's a good

requirement

and you know it it kind of

satisfies the verification criteria but

uh whether is it aligned to the

the business need or the goal of a

digital channel to low customers to book

tickets

no it's a good feature but it's not

really aligned to that particular high

level business

requirement hence you know when

the validation process takes place this

kind of requirement is

termed as low priority and can be

revisited once the

the key requirements are delivered

question number seven what is rtm or

requirement traceability matrix

so this is one of an important tool or

technique

which is used to trace requirements

so this provides backward and forward

traceability

as shown in this diagram and it helps

faster impact analysis and reliable

assessment

to ensure that all your business

requirements are covered

so if you look at this example uh rtm or

requirement disability matrix

so the business requirement uh will be

mapped to

the stakeholder requirements uh sql

requirement one and two

so in our example if you if you talk

about the digital channel for allowing

customers to book

tickets the stakeholder requirement

number one can be related to the

customer facing

screens and how they can how it allows

and the other stakeholders who can be

involved would be

the backend team or the back office

operations team

and what are the requirements from their

side to process the

customers online booking so that's how

the different stakeholders will have a

different set of requirements so the

first level of mapping would be

with respect to the business requirement

and the stakeholder requirements

and then the stakeholder requirements

would be mapped to the functional

requirements

and also the non-functional requirements

which we spoke about

and then the functional requirements or

non-functional requirements in turn

would be mapped to this design component

okay in order to deliver this

functional requirement what are the

design components required

so if you take an example of the screen

to show the customers the list of

available seats

so the design would involve uh different

screens

and also the the the logic for

uh showing up the available seats so

so that all comes under the design and

then

the design component maps to the the

code

so in which a particular language

the the co the code is there it may be

java.net

or it can be any other new technologies

like python

so all of this programming comes under

the code and it is mapped to the

design component and once the code is

kind of completed and then it's maps to

the test case

so the test case would ensure that

the code which is developed works

accordingly to the

requirement so this kind of gives an

end-to-end

mapping to ensure that a business

requirement is

kind of developed and

tested so it's a very useful tool and

this is one of the key things which

also use on a day-to-day basis and it

can be

asked in an interview

hello there requirements prioritization

this has been a challenge for every

business analyst

and it is going to be a challenge in the

future as well

because the business stakeholders they

want

all the requirements delivered as soon

as possible immediately possibly

in the single release we know that's not

going to happen

if you're having trouble convincing the

business on the requirements

prioritization

or you would need a technique or a

guidance on

on the prioritization of the

requirements this is the video for you

in this video we're going to cover the

four key requirement prioritization

techniques

which will help you to communicate with

the business

and get the highest business value items

delivered

first so we are going to cover these

four key thing four key prioritization

techniques

so a lot of cover we can get started but

before i do

i just wanted to tell you that this is

one of the video

in the business analyst techniques video

series so i've listed the other videos

in the description box

so please feel free to go and check it

out and also

if you haven't already subscribed to our

youtube channel or you're seeing

the video for our video for the first

time i will request you to go and hit

the subscribe button and also

the bell icon so that you'll be notified

when we do a new video

we do a weekly video on business

analysis techniques

tools concepts and also the

interview questions so let's get started

on the requirement prioritization

techniques

as always we'll be using a case study

and

using the case study we'll be driving

the concepts of requirement

prioritization

again this is a case study which we have

used in several of our videos because

it's very simple and easy for everyone

to understand

but if you want me to use a different

case study open to suggestions

please feel free to comment your case

study idea in the comments

section and we will pick it up for the

next videos so

in this case study a movie chain named

xyz cinemas they're looking for a mobile

app

which will allow their customers to book

movie tickets online simple as that

they don't want the customers to stand

in the queue they just want

the customers to use their mobile app

book it and what

enjoy the the movie so the features of

the app which

which the client is looking for are

registration customer registration

login feature the ticket booking

booking ticket feature and seed

selection

so ability for the customers to select

the seats

in the theater online payment

and again number six is more of uh

ordering uh refreshments like popcorn

coke

if in the app itself so that they don't

have to stand in the

line for buying these and the seventh

feature they're looking for is

once the refreshments popcorn or coke

are ordered

it can be delivered to the seeds where

the customers are booked using this

particular

online app so it's a very good feature

set uh

making the customer's life easy so this

is the features

so let's say how how we will be using

the requirement prioritization

to deliver these features uh released by

release

i i know it's good to have everything at

one shot but again

we know it's not feasible so let's see

how we can use a different requirement

prioritization technique

to prioritize and deliver these in a

release wise

okay let's get started with the first

requirement

requirements prioritization technique

called moscow

it's one of the most commonly used

technique

worldwide the requirements are basically

classified into must

should could and would must are your

mandatory requirements

without which there is no point in even

having a release

so they are the highest priority items

which has to get in

the next comes the should they should

are basically they're also high priority

items

but even if they're not delivered in a

release

there are workarounds through which uh

you know

the same functionality can be uh can be

satisfied

and then we have the good and wood so

basically good and wood are

nice to haves it's it's good to get them

into release but if

you know if you're not able to make it

that's okay we can defer it to the next

release

so let's see how we can apply this

moscow to our example

case study so if we if we

prioritize the requirement requirements

so the registration the login

and the book tickets are the must you

know it's

the key key things like the purpose of

the app is

for the customers to book the tickets

online

and the registration and login

are a pretty precursor basically

in order to book the tickets right whom

are we booking against if they

generally build do you even create an

account and then

uh the seed selection and make payment

agree they're again high priority

requirements but without

the ability for the customer to select

the seats or make online payment

they can still book the seats uh online

right the seats will be randomly

assigned based on the

best possible uh you know fit for the

number of seats

and also the payment they can walk in

and pay the cash

i understand it's not a you know best

customer experience

but you can still go hard if you just

have the book ticket

feature and the registration login

working fine

seed selection and make payments can be

handled

as a workaround you know with the with

the cash as we just uh talked about

and then we have the buying of the

popcorn coke

and having them delivered to their seat

yeah it's really you know it's really

nice to have

but it won't stop the release because

the purpose of the app

is not to uh for the customer to order

refreshments

but it's basically booking the tickets

online

so that is the purpose that's the reason

this these two things will become

good so now if we have this list

sorted mastered and could it's better

when you have a discussion with the it

okay you know what these are are must

these are should could

and you know if if we have that clarity

it's it's both good for the from an idea

perspective to get the built-in also

it's good from a business perspective

because we are

uh highlighting to the business that the

higher value items are being

delivered first so it's a win-win in

either way

okay moving on to the next technique on

our list

the next technique is called ranking so

these are again another

commonly used technique basically this

comes into place

when let's say we have like 10 must

and then the problem again now comes is

it would have bandwidth only for let's

say

seven of them so again we are in a fix

as we have stated in the previous

technique

all the must should make it to the

release but now

we are going to prioritize further so

that is where this technique comes into

play which is called ranking

here you rank those requirements from a

scale of one two

two three four five six and so on and

the smallest rated requirements has to

go in

first so if we apply this technique to

our case study

it would look something like this so the

registration is first then the login

we have the book tickets functionalities

number three

then the seed selection make payment by

refreshment refreshment server to the

seat

so this is another another way or

another technique of basically ordering

uh ordering the the requirement

uh requirements or the product backlog

because sometimes what will happen is if

you go to the business and we still

explain them you know must should then

could

they will again tell you know what all

these tens are must

so it will be again a bottleneck will be

a difficult situation

so in that scenario you can use this

technique okay we understand these are

must

let's try to rank them when we rank them

they'll be much more clarity on the

highest value or higher value items

so that again this clarity will help to

get those higher value items

delivered again a very useful technique

and used again commonly worldwide

okay let's start to look at the

requirement prioritization number

technique number three the canon

analysis so again this is a different

view of looking at the requirements and

we're going to look at it

exclusively from the customer's

perspective who's going to use the

product

so here there are three factors one is

the basic factors

performance factors and excitement

factors

basic factors are something like if you

don't have the feature in the app then

the customers are straight off

disappointed they won't even use

the particular app or an application

and then we have the performance factors

so which are basically

the drawing factor for the customers to

use the

application or the app and then they are

the the next one is excitement feed

factors so these are basically your

differentiator from the competitors

and your usp or unique selling

proposition so customers will be like

very excited to use the app

or the application because of these

particular

features so let's try to apply the canon

analysis

to our case study so it looks something

like this

the registration login book tickets

pretty

basic without them there is no point

even even using the app because if

you're not able to book the tickets why

are we even using the app

and then seed selection and making

online payment

yep it would be a you know customers

would be really happy to use this

because

they have the ability to select the

seats and they don't have to stand

in us in a line again to pay for the

cash

so they'll be happy to make an online

payment just then

get onto the theater just walk in and

then

the refreshments and the refreshments

sir to the seat

that would be an excitement uh factor

basically

the the reason for uh uh you know the

the the reason for this is basically

well again there is a queue for buying

refreshments

so if you're able to do that using the

app then it's like

you just walk in after doing the booking

the you you've selected the seats you

made the online payments

and then when you arrive uh at the time

of your choosing

you're getting your popcorn coke you

don't have to stand anywhere

no line nothing everything is taken care

so that is basically

you know it the customers will be

excited to use this particular

feature and because of this there will

be more people

being driven into this particular cinema

so it

will increase the revenue so so these

are some things it's a basically a

different

lens of doing the prioritization so it's

called the canon analysis and it is used

it's looking mostly from the customer's

perspective

and the last technique we have on the

list is called

user story map so basically i've

i've covered thoroughly taking in

another case study in one more video

i'm going to link it in the description

box so please go and check it out

where you will be uh shown how to build

a story map from scratch

and then to do the prioritization so

it's basically a visual representation

of your entire product backlog from

the the activity sequence of a user so

in our example would be the customer

when they

order the book the tickets online

and the time they you know they walk

into the movie theater watch the movie

and then get out so this is a basically

a customer journey we call it

and there will be tasks below it

so those would be your you know the the

user stories so basically if you put

this in a map

like some somewhat we show this this is

a basically an example of

a online home delivery ordering service

so you will be able to visualize it

better and the business will be able to

visualize

it better because they will be able to

see the end-to-end picture rather than a

sequential list

and then we can go again and you know

check with the business okay this is how

it is

can can you please you know which would

be the highest benefit

we can put put put the put the

requirements

in so the release one as we see here

it's called the mvp or the minimum

viable product

so that is like without which you cannot

even you know go in and then similarly

the other requirements are prioritized

to release to release three

it's a similar to what we have seen uh

in you know in the previous techniques

but again this is more

visual and gives an end-to-end view for

the business

which the other techniques won't give so

again it's a very useful technique for

them to understand and provide the uh

you know the priorities

so you're basically assisting them to

see the end-to-end feature and which

will be really appreciated

so these are the four techniques and uh

what we are going to do is i provided a

link in the description

for kind of downloading a quick cheat

sheet so you can download it keep it for

your reference

and start using it in your day-to-day

job when you're dealing with the

requirements and prioritization

hello there in this video we are going

to cover questions

pertaining to requirement gathering or

elicitation

which is one of the key skills for a

business analyst

in the previous video we discussed

identification

and types of stakeholders which is the

first key step for business analyst

post onboarding to a project once the ba

has the list of stakeholders

the next step would be to engage them

using different requirement gathering

sessions

to gather the requirements we will cover

the techniques used for gathering

business requirements

in this video and will focus on

techniques for functional requirements

in the next

video so let's get started with the

video

as always we will use a simple case

study

which will make the concepts easy to

grasp

ravel is a ba working with a client

running a restaurant called

wagon gardens the client is looking for

a mobile app which will allow their

customers to book a table

moving on to question 1 what are the

requirement elicitation techniques

you have used in the past this is one of

the most commonly asked question

and listed below are the commonly used

requirement elicitation techniques

some of them are document analysis

workshops interviews

observation focus groups

brainstorming process analysis

prototyping survey or questionnaire

we will discuss these techniques in

detail in the upcoming

questions based on your answer

the interviewer will ask deep dive

questions on the techniques

which you would have mentioned that you

have used so make sure

you tell the technique which you have

used

question 2 what is the first elicitation

method you would use

the answer in my view would be document

analysis

this involves reading the existing

documents available

related to the project which you are

working on

this will help to provide context and

background while engaging with the

stakeholders

through other elicitation techniques

this will help you to identify the

current state and the problems faced in

the current business unit

process and others going back to our

case study

rahul our ba on the project can request

for

and look into the below documents before

engaging with the stakeholders

organization chart this would give the

background of the people

and business unit structure as vegan

garden restaurant has several branches

the organization chart would provide

information

on number of branches and names of the

key people in each branch

user manual and standard operating

procedures

this would give rahul a view of how the

current table booking process works and

which system is used by the staff

so rahul will be familiar with the

current systems and have a better

understanding

while speaking with the stakeholders

rahul can also look at design documents

technical documents

process flows problem reports

business rule documents or any

previously captured requirement

documents

which would help as stated earlier in

understanding the current state

and context of the new project

let us look at question number three in

your opinion

what you think is the best elicitation

method

there is no right or wrong answer you

can answer based on your experience

in my view the best elicitation method

is the workshop technique

as you can gather high quality business

requirements

in a short span of time with a variety

of stakeholders

the workshop technique involves getting

all the key impacted stakeholders

from different departments together for

an extended period of time

like a day or two to go over the project

details

and understanding from each of them what

they are looking for

as an outcome since we have the key

stakeholders present

any conflict can be resolved impacts can

be identified

and can easily gain agreement from all

the stakeholders at the same place

we will discuss this technique in depth

in the next question

question number four can you tell me

about a time when you conducted a

workshop

if you have answered that you have used

the workshop technique

then interviewer might ask this question

to get an insight into your experience

for every requirement elicitation

technique as mentioned in baboch version

3

it has three phases prepare

conduct and post the session

let us consider the workshop in context

with our case study

rahul rba is going to use the workshop

technique

for gathering the business requirements

for the online table reservation system

first off rahul needs to prepare for the

workshop which includes

setting a clear purpose which is to

gather business requirements for the

table reservation system

identifying the key stakeholders and

ensuring

they are available to attend the

workshop the key stakeholders would

include the sponsor who is the owner of

the restaurant

the business managers from different

branches and

senior operations staff who are involved

in the table booking process currently

once he has the list of the key

stakeholders he would schedule

a place and time convenient for all the

key stakeholders

usually workshop is a full day or two

days event

the venue should have all the facilities

like whiteboard projector

adequate seating etc and refreshments

like coffee snacks should also be

arranged rahu chooses his company's

conference room which has a seating

arrangement for 15 plus people

and invites the key stakeholders there

for a full day workshop

he has also arranged for lunch and other

refreshments

next off rahul would make and share the

agenda with the attendees

agenda will have sessions or activities

for that day

so that the stakeholders come prepared

sample full day agenda would be like

this

9 to 9 30 introductions can happen 9 30

to 11 15

walk through of the current process 11

15 to 12

break 11 30 to 1

discussion on the target process design

1-2 lunch break 2-4

gathering the business requirements for

the target

4 state 4 30 they can have a short break

and again 4 30 to 5

they can have a playback session

the first stage is key if the

preparation is good then conducting the

workshop is pretty easy

moving to the second stage conducting

the workshop

the stakeholders meet at the venue on

the day of the workshop

and rahul uses the agenda shared earlier

to drive the workshop

and will try to adhere to the agenda as

close as possible

as the workshop progresses rahul

documents the discussions

requirements and actions if help is

available

one can also use them for documentation

during the workshop

they are referred to as crime

the last stage is post the workshop

which would

include activities like closing out any

open actions

raised during the workshop rahul can

then share the captured business

requirements for sign off to the

stakeholders

if required rahul can arrange a review

session with the stakeholders

to walk through the requirements

captured for obtaining a sign off

moving on to the next question question

number five

what are the challenges faced while

using the workshop technique

and how would you mitigate it this is

another follow-up question

asked on workshop the major challenge

would be non-availability of the key

stakeholders

getting all the required people together

for a day or two

is by far a difficult task

some mitigation would be the below

approaches

number one explaining the importance of

the workshop

and how it will help to shape the system

which they are trying to build

number two rescheduling to a suitable

time

so that everyone can attend number three

in case a key person is not available

then asking them to send their deputy

or a representative from their team

if still we are unable to get everyone

together then covering

off with the key stakeholders individual

interview is an

option which will cover in the next

slide next question

question number six can you tell me

about a time

when you conducted an interview if you

have answered that you have used the

interview technique

then interviewer might ask this question

to get to know more about your

experience

like we spoke for the workshop the

interview elicitation technique has

three phases prepare conduct post

decision

let us continue with our case study and

say one of the key stakeholder jim

who is the manager of customer support

could not attend the workshop

rahul would then use the interview

technique for sharing the outcome of the

workshop

and gather any missing business

requirements from the customer support

perspective

first off rahul needs to prepare for the

interview which includes

setting a clear purpose which is to

gather business requirements from a

customer support perspective

schedule a place in time convenient for

jim to attend

next off rahul would make a list of

questions

like what the customer support staff

would like to see in the new system for

answering the customer queries

what are the functionalities required in

case there is change required by the

customer

and so on and shared these questions in

the meeting invite to jim

so that he can speak to the team up

front and

have the answers ready as stated earlier

first stage preparation is always the

key if the prep is good

then conducting the interview is pretty

easy

moving to the second stage it was agreed

to have a discussion

on the conference call and both rahul

and jim

joined the call for the interview rahul

briefly touched upon the outcome of the

workshop

and then used the questions shared

earlier to drive the interview process

rahul used active listening techniques

and made notes

on the discussions requirements and open

actions

once all the questions were covered

rahul thanked jim for his time

and informed that he will share the

minutes of meeting and also the

requirements captured

for his review and sign off post the

workshop

rahul shared the minutes with open

actions

and also shared the requirements

captured for review

and sign off moving on to the next

question

question number seven can you tell me

about a time when you conducted an

observation session

if you have answered that you have used

observation technique

then interviewer might ask this question

to get to know more about your

experience

like we spoke for the previous two

techniques

the observation elicitation technique

also has three phases

prepare conduct and post the session

let us go back to our case study one of

the open actions in the workshop was for

rahul to capture a time and motion study

that is how much time does the current

reservation process take

and also document the current steps

taken by the staff to complete

the booking rahul is going to use the

observation technique for completing

these two actions

first off rahul needs to prepare for the

observation session

and he follows the following steps

setting a clear purpose which is to

document the detailed process

used by the staff now and do a time and

motion study

identifying the participants with the

help of one of the branch managers

and scheduling a convenient time for the

session

share the agenda with the participants

up front so that they are prepared for

the session

as always first stage is the key if the

prep is good the rest follows easily

moving to the second stage rahul meets

the participants at their workplace

at the scheduled time and briefs them

on the required outcome and the reason

for the same

rahul uses passive observation technique

he captures the start time when

a call is made by the customer and end

time when the booking is made

in the current system it is around 3

minutes

he then asks the branch manager for a

staff to make a note of the time

from today so that the average time can

be benchmarked

and used for presenting back to the

sponsor who wants to know

this he also observes couple of staff

and makes note on the steps taken by the

staff for making the booking from the

time when the customer

calls and the booking is done on the

system

once the staff completes the booking he

asks couple of clarifying questions on

the doubts he had on the process

he then thanks the participants for

their time and heads back to the office

the last stage is to ensure what he

captured is right

he converts the steps into process

diagram and

sends it to the staff for review

and also follows up on the open action

for the average time for booking process

from the manager

question number eight another follow-up

question on

observation what is the difference

between active

and passive observations there are two

types of observations

first one active observation when the

staff is performing the steps

in the process if you have any questions

you stop the staff

and ask clarifying questions when they

are performing that step

to gain insights point number two

passive observation you make a note of

all the questions

and wait for the staff to complete all

the steps in the process

and then ask your questions

active observation is used when you are

more interested

in specific part of the process whereas

passive is generally used to capture the

metrics of the time taken to complete

the process

and for benchmarking question number

nine what is focus group and how to

conduct one this is similar to the

workshop

you get the key people together at the

same place to get their thoughts and

opinions going back to our previous

video where we discussed about personas

which are fictional characters who

represent the typical customers

they are helpful to understand the

customer's need and build the product

accordingly

based on brainstorming with the internal

team the requirements would have been

locked on what these personnels would

need

identifying and validating the needs of

the personnels are very important to

ensure

we are building a product which

satisfies their need

focus group is one such technique to use

for that

let us take two personas as example

first one the office manager this is a

typical manager who has number of team

members reporting to him

there would be quarterly or sometimes

monthly team outings

and the manager is responsible for

looking for fun places

to have a team lunch or dinner their

needs are quick snapshot of the service

offerings

and also the receipt of the bill emailed

to them

so that they can do claims for

reimbursements as all the outings are

built to the company

second one family man one who wants to

book on weekends

for brunch lunch or dinner he does not

care about the digital copy of the bill

but is very keen on services offered for

the kids

and the seating arrangements

if you see just going at a high level we

have got two requirements

first one soft copy of the e bill to be

emailed as a pdf

second one service offerings should be

shown in the booking app or the website

again these are just assumptions and has

to be validated

focus group is one of the way to

validate the assumptions made

rahul can get the details of their

previous regular customers from both the

categories

office manager and family men and

arranged for a focus group session with

them

to go over the feature of the new online

booking system

he also provides perks for participating

in the session

by giving them free lunch or dinner

coupons at the restaurant

again similar to the workshop technique

agenda can be shared upfront to these

people

so that they are prepared during the

session

rahul uses the agenda and goes over the

list of business requirements captured

to get their thoughts on each one of

them

rahul makes a note of the participant's

feedback

once all the items in the agenda are

complete then rahul thanks the

participants

post the focus group session rahul

compiles the report

based on the insight received and shares

with the key stakeholders

this would help to understand which

business requirements are key to the

target audience and which can be

discarded or

be prioritized let us look at question

number 10

how can you gather requirements from a

large number of people

or they can ask you to tell about a time

when you used

survey or questionnaire technique

answer is survey or questionnaire

technique

we cannot use any of the techniques we

spoke about earlier

due to the sheer volume continuing with

our case study

rahul wants to get a view on the

thoughts of the vegan gardens existing

customers

on the new online booking system before

starting the bill to ensure their

requirements are satisfied

going back to our three stages in

prepare stage

rahul would compile a list of question

and answer options to send out to the

participants

it is important to have options for each

question

and not have a free text field as it

will be difficult to interpret the

answers

sample questions can be like do you

prefer a mobile app or a web app for

making the booking

do you want to receive reminders on your

reservation

using the questions rahul will create an

online survey

and get the survey link in conduct stage

rahul sends an email to thousand plus

existing customers of the restaurant

to help to take the survey he can also

provide

perks to the customers like discounts

for participating in the survey and it

is very important to give a deadline for

the customers to complete the survey

otherwise we cannot close the activity

post the deadline date rahul can review

the results of the survey

and compile insights and log them as

business requirements

hello there do you have a business

analyst interview coming up shortly

if so this is the video for you in this

video we're going to look at the top

9 interview questions asked related to

the requirement documents

as you're already aware eliciting and

documenting the requirements

are one of the key aspects of a ba role

so the

interviewer would be definitely

interested in understanding

the requirement documents which you have

created in your past

projects we have a lot to cover so let's

get started

i can assure you that they're going to

be couple of questions

from this video which will be asked in

your next business analyst interview

we're going to look at the brd frds

their contents and structure we're going

to also discuss

on rtm epic user stories their format

and also the acceptance criteria so it's

going to be a

informative video so make sure you watch

it till the end

and also if you have not already

subscribed to our channel

please go ahead and subscribe to our

channel right now so that

you will be notified and you won't miss

out on any

of our future videos

to make it easier for grasping the

concepts and the answers

we're going to use a case study with

this case study

a movie theater chain called xyz cinemas

is looking to build a digital channel

for allowing the customers to book their

movie tickets online

rather than calling up the customer care

or standing in the long queues and

getting their tickets

at the ticket counter so we are going to

use this

uh example case study for

answering all the questions

okay let's get started question number

one what are the different documents you

are prepared for capturing requirements

this question i would say is a sure

short one

and it is asked in almost all the

business analyst

interviews i've listed the majorly used

documents it varies from company to

company

but these are the common ones so the

first one is the brd

which is the business requirement

document the purpose of this document

is to capture the business requirements

and the core business context

of a particular change initiative the

second one is the

functional requirement document which is

the frd the purpose is to capture the

functional and non-functional

requirements

and it kind of maps back into the

business requirements

then we have the use case document again

the purpose would be to document

the use cases uh which details the

interaction between

an actor and the system or the solution

which we are trying to build

and then we have the activity diagrams

so this

uh documents the flow of events uh the

in

the interactions uh between the

user and the system and also the

detailed step-by-step

flow which basically which will help the

it team

to build the solution which we're

looking for and then we have the

wireframes

so the wireframes are basically used uh

to provide

a view of how the screen should

should be looking for the customer so it

will be the look and feel the colors

and also the various user interface

items so all these things would be

mocked up

into the wireframes and then we have

the epics and user stories so all the

documents which we just spoke about

are used in the traditional waterfall

model

but in case if a project is using agile

the requirements are captured

in epics which is again the high level

requirements and then

the user stories which are epics are

broken down into user stories

so and all the use cases activity

diagram wireframes are all

you know converted into supporting

models and they are

basically attached to the user stories

for the epics to provide more context

and a better understanding of what is

required to the it team so that they can

build it accordingly

and the last one common one which is

used is the rtm

which is the requirement traceability

matrix it is basically used to

trace the requirements backward and

forward right from the business

requirements to the test case and vice

versa

we're going to talk about all of these

in details in the further slides

moving on question number two what are

the contents of

brd or the business requirement document

again this is a

a question asked to

gauge your depth of experience of

preparing

such kind of documents so you you can

use example

to provide the contents of the brd

and i've listed few of the uh

components here but again it varies from

company to company project to project

but these are the few

uh common uh building blocks so the

first one would be the executive summary

so if you looking at our example

this would summary would state that the

business

xyz cinemas is looking for a digital

channel

for the customers to book their movie

tickets and the business context will

provide why they are looking for this

change initiative

well here in this context it's just to

make it more convenient for the customer

to book online rather than standing up

in the long queues or calling up

uh other customer care and you know

waiting for it to be confirmed

so that is the customer convenience and

also if you look it from

at the staff perspective uh this can

help to free up

for some of these steps were doing these

rules and they can be allocated to

uh you know other priorities other

opportunities

and then there will be a current state

and target state current state will be a

basic business process flow like what's

happening now when the customer comes in

uh goes to the ticket counter and

similarly what happens when they call up

the uh customer care

and the target state will be how the

customer with the

the target state process flow will show

the

how the customer will be using this

digital solution

to book the tickets and how they will be

permitted into the cinema halls

you know the end-to-end business process

flow how the target state would be

so this will give more contacts to all

the

stakeholders involved and also to the

engineering team

i.t and the testing team uh the

development testing team to understand

what is being done and why is why it is

being

done and then the scope the scope

section would

actually have uh what are the things

which are in scope for now so let's say

if you're looking for the solution

whether we wanted to be limited only to

you know the web web app or a web login

or

do we want to also develop a mobile app

where the customer can book their ticket

so this would be

the scope and it should be pretty clear

what is in scope and what is out of

scope

and then comes the business and you know

the stakeholder requirements so these

are the requirements

which are are you know needed to achieve

the target state so this

talks about this can talk about the

requirements related to

the customers uh able to book their

tickets online

and also uh the cancellations uh what

are the things the customer can do with

the

online channel and also similarly on the

staff side it can be like how

the staff can identify these book

tickets how they can let the customer

into the hall so all of these

requirements would be

under these sections and then the next

one would be the assumption so what are

the

assumptions for this initiative so one

of the assumption i can think of is

once this channel is available the

customers will start using it

you know that's a basic assumption and

then the dependencies what are some

things which have to be in place

for this thing to work and then the

business rules

if there's any rules for example like

the they might have a rule that

only a maximum of 10 tickets can be

booked at

one time so this is a business rule this

can be translated and documented

uh for a functional requirement and you

know

ensure that the digital solution also uh

withhold like holds

this business rule true and then the

last section would be a glossary which

will just summarize

all the abbreviation acronyms used in

the whole document so just to give a

view of the person who is reading the

document understand it

better so these are some common sections

in a brd

moving on question number three what are

the contents of a functional requirement

document or frd so this is similar to

our previous question

again uh they want to understand your

depth of knowledge in preparing such

documents

so quickly gonna list out all the common

sections which is

uh you know used in drafting uh frd

so first one would be the purpose again

what is the purpose of this particular

document

uh how it's how it you can borrow

some context from the brd to put it here

similarly the scope section again can be

borrowed from the brd what

is in scope what is out of scope so it's

very clear and then

comes these functional and

non-functional requirements

so these are the system related

requirements and

here you'll be document documenting what

the system should do

in our example if we take this would

talk about

how the customer should be able to see

the list of shows

the list of seats which are available

for on each show

and where they can select the seats and

also make an online payment

so these are basically a translation of

the business requirements

uh into this is the functional

requirements which

which basically again what you want the

system to do

and these are all linked back to the

business requirements

similarly a business rule which we spoke

about the maximum of 10 seats can be

booked that also can be translated to a

functional requirement ensuring only 10

seats can be booked online and then we

come to the non-functional requirements

so these are the

requirements related to the performance

the security stability of this online

solution

so one such example is responsiveness uh

we want the solution

the system to respond within two seconds

of the user's input so for example user

selects a date

within two seconds we should be the

customer should be able to see the next

screen so that's one example of it then

the assumptions

we just spoke about and then the major

chunk of this

document would be the supporting models

which will provide

more context to the engineering team

and helping them to understand how we

want the solution to work so that they

can build it accordingly and you know

tested it

as well so this is about the use case

diagrams activity diagrams mockups which

we just spoke about

earlier so all of these would comprise

a you know will be part of a vr sorry

frd

and then the last one is a glossary

again just to provide more context on

the

acronyms and of the abbreviations used

question number four what is the format

and contents of an epic

so far we discussed about the waterfall

methodology and the documents used

when you come to agile it's very

document light

and all the requirements are captured in

the form of epic

or user stories epics are tileable and

then they

are broken down into detail user stories

so i've listed

uh this down the key components of an

epic

in this slide ideally in essence what an

epic

has is who what and why who requires it

what is required why is it required so

this is kind of a format

which is you know used to capture the

requirements

so a template which are provided which

is a commonly industry-wide

format which is used across as a who

requires it

i want what is required so that why is

it required

so that's a format if you look at an

example

as a customer i want to pay for my movie

tickets online

so that i don't have to stand in queue

to pay cash at the movie theater

so this is a again a customer convenient

convenience

requirement where we're talking about

the ability for the customer to pay

online for the movie tickets which they

have booked

so it captures the requirement in this

particular format and it also has some

additional information like priority

what is the priority of the requirement

is it a must should or record

or if you're using ranking it can be ra

you know prioritizes one two three four

etcetera etcetera so it all uh helps in

the prioritization of the backlog so

that the highest value item is delivered

first

and then this has the business contacts

so it provides more context on

why this particular requirement is uh

you know listed in first place so all

the things which we spoke about in brd

so those things

can be added here as a business context

and then it has

links to the detailed user stories so

if you look at an epic it gives a

high level requirement of what is

required

in the next slide we will speak about

the detailed user stories

question number five what is the format

and contents of an user story

so we are building upon from the

previous question which

you know which is epic and these are the

detailed user stories

so the format of a user story is very

similar to the

epic who what and why so what

i try to provide as an example is the

epics the epic spoke about how the

customer should be able to pay online

and in these two user stories we are

breaking down it further

so if you look at the first one as a

customer i want to pay online using

my debit or credit card for my movie

tickets again

he wants to avoid standing in queue the

second user story talks about

customers ability to pay online using

the online banking portal so for example

they don't use a

credit card they want to use their

online banking net banking portal

so this breaks down the epic

into more details of the channel which

the customer wants to use

we can still have more user stories like

the mobile

valids paypal etc etc

so this kind of gives you a view how an

epic is kind of linked to the user story

and what is the

format and the user story also has like

additional information like the priority

similarly must should could or high

medium low again one two three four

ranking

and then it will also have the epic

which is linked to

and then the acceptance criteria which

will uh we speak about

uh in the next slide and also the

supporting models

so the use cases activity diagrams the

mockups which we spoke earlier

all of them would be created and

attached to

the user story as a supporting model to

provide more

context and more information to the

engineering team to build the solution

question number six what is an

acceptance criteria

and its former as discussed in the

previous question

acceptance criteria is a for is a part

of our user story

and it's a very important part it

basically

uh states the condition or outcome which

has to be satisfied in order for a re

uh for a solution to be acceptable to

the business stakeholders

so it's very key in terms of coming up

with the

qa test scripts and also the uat test

scripts

so so it's a very vital component of a

user story when we look at the

template or the format so usually

the acceptance criterias are also given

as a one line statement

in an example demonstrate that the

customer is able to

pay using their debit or credit card

but that is there is high level

statement on in order to make it

more robust and ensure that everybody

gets

a clear understanding this is the format

which you see on the screen it's

based off bdd behavior driven

development

so the format is given a context

when an event happens then what is the

outcome

which is expected if we translate that

to an example

based on the user story which we just

discussed given customer has selected

the show

and selected their seats when they are

on the payment

page of the digital solution then

they should be able to pay online using

their debit or credit card

so it clearly spells out what are the

uh what is the context what is the event

and then what should

happen so it's very clear to everyone

the developers and also the testing team

what the outcome we are looking for in

what condition

and it ensures that we build a solution

according to the

uh business requirements

question number seven what is rtm or

requirement traceability matrix so this

is one of an

important tool or technique which is

used to trace requirements

so this provides backward and forward

traceability

as shown in this diagram and it helps

faster impact analysis and reliable

assessment

to ensure that all your business

requirements are covered

so if you look at this example rtm or

requirement traceability matrix

so the business requirement will be

mapped to

the stakeholder requirements uh sql

requirement one and two

so in our example if you if you talk

about the digital channel for allowing

customers to book

uh tickets the stakeholder requirement

number one can be related to the

customer facing

screens and how they can how it allows

and the other stakeholders who can be

involved would be

the backend team or the back office

operations team

and what are the requirements from their

side to process the

customers online booking so that's how

the different stakeholders will have a

different set of requirements so the

first level of mapping would be

with respect to the business requirement

and the stakeholder requirements

and then the stakeholder requirements

would be mapped to the functional

requirements

and also the non-functional requirements

which we spoke about

and then the functional requirements or

non-functional requirements in turn

would be mapped to this design component

okay

in order to deliver this functional

requirement

what are the design components required

so

if you take an example of the screen

to show the customers the list of

available seats

so the design would involve different

screens

and also the the the logic for

showing up the available seats so so

that

all comes under the design and then the

design

component maps to the the code so

in which a particular language

the the co the code is there it may be

java.net

or it can be uh any other new

technologies like python

so all of this programming comes under

the code and it is mapped to the

design component and once the code is

kind of completed and then it's

maps to the test case so the test case

would ensure that

um the code which is developed

works accordingly to the requirement so

this

kind of gives an end-to-end mapping

to ensure that a business requirement is

kind of

test developed and tested

so it's a very useful tool and this is

one of the key things which

also use on a day-to-day basis and it

can be

asked in an interview

moving on question number eight what are

the different visual models

you created for documenting requirements

so this is another key questions which

keeps

getting repeated in the business analyst

interview

so i've listed the major ones used but

there are

much more uh visual models uh

which have been used so i'll be creating

another video only

dedicated to this but in this video i'm

just going to quickly cover of the

commonly used ones the first one is the

use case diagram

which uh kind of documents the

interactions between the