馃攳
What Documents Do Business Analysts Produce? What are a Business Analyst's Deliverables? - YouTube
Channel: Karaleise | Business Analyst Training
[0]
hello hello everyone come on in come on in i am聽
Karaleise and i'm your business analyst coach聽聽
[7]
and this is the place where you can come聽
to get information about business analysis聽聽
[12]
about product ownership about product management聽
project management just if you want to find out聽聽
[17]
about the career this is where you'll find videos聽
about that or if you're a new graduate or just聽聽
[23]
somebody who's curious to know how it is in the聽
working world or in the business world this could聽聽
[28]
be a great place for you as well so go check out聽
my other videos i have a bunch of videos here on聽聽
[33]
youtube that you can check out and it can be very聽
helpful for you and also if you like what you see聽聽
[39]
please subscribe please like the video please聽
leave a comment and that would be great for me to聽聽
[44]
be encouraged to keep giving out this information聽
okay so welcome welcome welcome i'm very happy聽聽
[50]
that you're watching this video and today we're聽
talking about a very important thing and that is聽聽
[55]
what are the documents that a business analyst聽
produces like you're working working working what聽聽
[61]
is your deliverable what do you produce what's聽
the artifact that's the result of all of your work聽聽
[67]
that is what we're going to be talking about today聽
but before we get into that i want to say that i聽聽
[72]
do have some free courses on business analysis聽
that's up on my website so go to carlease.com聽聽
[79]
go to free courses and you can see different聽
types of courses on different topics and you聽聽
[83]
can just go there and watch the courses and that聽
way it's structured for you it's organized for you聽聽
[90]
and you don't have to be jumping around in youtube聽
trying to figure out which video to watch next聽聽
[94]
you know just want to share that with you so聽
that if you need more information that's the聽聽
[98]
place that you should go to get it all right also聽
before i jump into the topic of today i want to聽聽
[105]
let you hear from our sponsors so let's聽
go check that out and come right back聽聽
[114]
i wanted to share with you a tool i've been using聽
that's really helped my productivity and that is聽聽
[119]
this thing right here called a cube timer so a聽
cube timer is actually this thing and it just has聽聽
[126]
all the numbers in each of the faces and as you're聽
working you can just turn it on and flip it and聽聽
[132]
flip it and flip it and whatever number is on the聽
face that's the number that you start accounting聽聽
[137]
for and when that time is up the alarm so you know聽
you need to stop what you're doing and move on to聽聽
[142]
the next task this has been immensely valuable for聽
you timing yourself and making sure you get things聽聽
[147]
done in a timely manner and i'm going to leave聽
the link to this in the description below it's聽聽
[151]
actually available on amazon i'll leave the link聽
below and if you click on that link and make this聽聽
[155]
purchase that would be supporting and helping聽
what we're doing here on youtube so go check it聽聽
[159]
out and get this wonderful little tool y'all to聽
help you manage your time and be more productive
[169]
so we're talking about you know what are the聽
documents that a business analyst produces聽聽
[175]
what's the business analyst deliverable聽
uh what's the artifacts that they create聽聽
[180]
and you know it's very important to know this聽
if you're going to be working in the space聽聽
[185]
right what are you expected to do and so there are聽
a number of documents that we produce and some of聽聽
[192]
them are formal some are informal i mean some are聽
structured some are not some you can come up with聽聽
[197]
by yourself some you have to follow a very strict聽
template so again every company is doing their聽聽
[201]
own thing but generally um as a business analyst聽
there's a few documents that you must must must聽聽
[209]
must know how to write and the number one聽
document would be your business requirements聽聽
[216]
document right so i do have a video of聽
how to write your business requirements聽聽
[221]
document and you can go check that out but聽
basically this is going to be a document that聽聽
[227]
lists out all of the requirements that you need聽
for the feature functional project that you're聽聽
[233]
working on sometimes we call it a functional聽
requirements document sometimes it could either聽聽
[239]
be the system requirements specifications srs聽
document they all have kind of slight little聽聽
[245]
differences but it's generally that document that聽
is the authority the authoritative document as聽聽
[251]
to what should be built in a system or what the聽
process is going to be like and so on so this is聽聽
[257]
the main deliverable that you have as a business聽
analyst the business requirements document or the聽聽
[264]
frd function requirements document or srs systems聽
requirements specifications are usually documents聽聽
[271]
that are produced in a waterfall environment so聽
if you're working under waterfall where you're聽聽
[276]
doing all of the requirements up front and you聽
write all the documentation up front for every聽聽
[281]
single thing to do with this feature then you聽
create this huge you know this big document聽聽
[286]
that is called the brd frdo srs and that would聽
be the authority for what they need to go off聽聽
[292]
and build um for software projects or if it's聽
a process or if it's just a you know a feature聽聽
[299]
or something like that you would um write this聽
document and it would be used as reference point聽聽
[306]
for the other teams that need to know about聽
what to build right so that's normally done聽聽
[310]
in a waterfall environment and so that's the聽
main deliverable if you're working in waterfall聽聽
[317]
now for the agile people in the room聽
right what is the deliverable for you聽聽
[322]
as an agile business analyst well mainly聽
it's going to be the user stories right聽聽
[326]
so the user stories is your main deliverable聽
uh when you're working in agile and this is聽聽
[331]
you know complete with your acceptance criteria聽
i do have a video on how to write user stories聽聽
[337]
and that goes through what makes you the story聽
good you know how to put one together normally聽聽
[342]
people write user stories in a tool called聽
jira but you can write with the stories in word聽聽
[347]
or in excel or any any other tool but in the聽
industry jira is the authority this is the聽聽
[354]
the most commonly used tool for writing user聽
stories and managing the whole entire agile聽聽
[360]
process i do also have a video on how to write聽
the acceptance criteria and so you can go and聽聽
[366]
check those videos out if you need some help as to聽
how to produce this deliverable of the user story聽聽
[374]
the other deliverable that you would聽
produce or deliver if your business analyst聽聽
[381]
will be your mockups and your聽
wireframes so this one is kind of聽聽
[385]
true in some cases and not true in聽
some cases because some companies hire聽聽
[390]
a ux designer who works hand-in-hand with聽
the product owner or the business analyst聽聽
[395]
or the product manager to actually come up with聽
the wireframes and mockups of what the software聽聽
[401]
needs to look like but in some cases they don't聽
have a ux designer and so the business analyst聽聽
[406]
creates these wireframes for talking points and聽
has a discussion around them you know change聽聽
[412]
them edit them based on what the feedback is and聽
then that produces um you know better markups for聽聽
[418]
the next session and iteratively doing this聽
you eventually come up with the best design聽聽
[423]
the business analyst is the one that's actually聽
doing the mockups and the wireframes to go with聽聽
[429]
their requirements and user stories now don't take聽
this as being oh my god i gotta go learn how to聽聽
[435]
how to be a designer i gotta go learn photoshop聽
i gotta go learn sketch gotta go learn zeppelin聽聽
[440]
and all these things no you don't need to know聽
all of those things um normally just doing basic聽聽
[445]
wireframing is enough you could do balsamic i have聽
a a video on the tools that you can use um so you聽聽
[453]
can go check that out as well it includes a tool聽
called balsamiq you could use paint you could use聽聽
[460]
word powerpoint it doesn't have to be perfect you聽
don't need to have a pixel perfect uh mock-up you聽聽
[466]
know there's other tools out there as well that聽
will be helpful for creating these these markups聽聽
[470]
that business analysts produce to go along with聽
their requirements the other thing that business聽聽
[477]
analysts produce would be like a scope document聽
so these can have different names some people聽聽
[482]
call it project scope you know feature scope you聽
know um you know all different names that they聽聽
[488]
named it but it's really just like a document聽
that highlights what will be done or what will聽聽
[494]
not be done right among other things but the聽
main purpose of it is to delimit what you're聽聽
[500]
going to actually produce for this time period聽
or for this feature for this function or for this聽聽
[505]
project so that there is clear understanding聽
as to what you're going to be delivering聽聽
[510]
when it is done right so there's another document聽
called a scope document that the business analyst聽聽
[516]
sometimes writes and produces other documents聽
that we produce include things like walk-through聽聽
[521]
presentations so sometimes you need to communicate聽
the ideas that you came up with with a different聽聽
[528]
team and so you produce these presentations that聽
kind of walk through the process explain how it聽聽
[534]
will work you know show the as is state and the to聽
be state sometimes if it's a software project then聽聽
[540]
you walk through the screenshots and you explain聽
how it will flow so you have your primary flow and聽聽
[546]
your secondary floor you walk through all of that聽
with maybe your dev team maybe with your customer聽聽
[551]
support team maybe with other teams that will be聽
interested in this so you create this thing as a聽聽
[556]
presentation tip typically although it doesn't聽
have to be um it could be just our document or聽聽
[562]
something else but you create this presentation聽
and then you you have that as reference for how聽聽
[568]
you have envisioned this new process another聽
important thing that we don't want to ever lose聽聽
[573]
sight of is your use cases so business analysts聽
actually do write documentation on use cases聽聽
[580]
and there is a little confusion about the use聽
case right now because one is you have the uml聽聽
[587]
use cases so uml has this structure for writing聽
use case descriptions and how to do use case聽聽
[594]
diagrams and so you have these ovals you have聽
little sick people and then you show how this聽聽
[598]
use case match to this person and blah blah聽
and that's great if you want to map it out聽聽
[604]
from an actor versus use case perspective and聽
that's great for documenting um your future聽聽
[611]
feature or future system and it's very system聽
related though you know it's very this is how聽聽
[618]
the system is going to work or these are how all聽
the actors interact with some kind of feature聽聽
[624]
and that's great for the uml perspective but when聽
you get into the real world you start to realize聽聽
[629]
that when they say use case they mean something聽
different right they don't always mean the uml聽聽
[636]
version of a use case so use case could also be聽
referring to how are people using this feature聽聽
[643]
or function or are they walking through this聽
process currently so the use case tends to be聽聽
[650]
from two perspective what it is today and how we聽
intend for people to use it in the future so the聽聽
[657]
use case is very tricky you got to be careful聽
about this because you might hear use case and聽聽
[661]
you go off thinking they want a uml diagram but聽
sometimes they don't they just want you to explain聽聽
[667]
what they're trying to do currently the聽
challenges they're having what they're聽聽
[671]
doing now and how they're you know what what聽
is impeding them and it could also be this聽聽
[677]
is how we're going to solve the problem and聽
this is how they're going to use the solution聽聽
[681]
right so the use case of how we're going to聽
use this new solution so you got to be careful聽聽
[685]
sometimes if you need to do the latter one it聽
just needs to be a document that's well laid out聽聽
[691]
and explains all these different things if they聽
meant the uml version then it needs to be the uml聽聽
[698]
description and the diagram that goes with it聽
right so just need to clarify most of the time聽聽
[704]
though i'm telling you most people don't even know聽
about the uml in the real world they don't really聽聽
[709]
know the uml version of a use case they're聽
thinking new skills i think how someone uses聽聽
[715]
the feature function or project or or process聽
there and they want you to document that so聽聽
[721]
it can be shared with other people so just be聽
careful about that when you think about use cases聽聽
[726]
the other thing that a business analyst produces聽
often is called a user acceptance test case so聽聽
[734]
your uat is user acceptance test cases and this聽
is what you will use to make sure that the user聽聽
[740]
will accept the feature function that you've just聽
created so what it is it's supposed to be written聽聽
[746]
from the perspective of the user and it's written聽
to test if the user would find this functionality聽聽
[753]
you know usable or friendly or useful and so聽
you need to know how to write those kinds of聽聽
[758]
test cases it's different from your acceptance聽
criteria it's not the same sometimes people think聽聽
[764]
that the acceptance criteria in agile will be used聽
directly for the uat and it's not true because the聽聽
[771]
acceptance criteria is written for developers and聽
it's written specifically so they can understand聽聽
[775]
what to go and build but the uit is written for聽
the user and they need to understand to break down聽聽
[781]
terms into group things you need to make it user聽
friendly so they can understand what you intend聽聽
[786]
for them to do and you're also trying to gauge if聽
what you've built from a technology perspective if聽聽
[791]
it's usable if it has good user experience and so聽
you don't want to tell them every single step you聽聽
[796]
want to know if they can figure it out on their聽
own because you're not going to be sitting beside聽聽
[800]
them in the real world to tell them exactly what聽
to do so the system needs to be user friendly that聽聽
[805]
needs to have good ux design and so you write your聽
uat to cover some of those things right to give聽聽
[811]
them scenarios that they can then go try and solve聽
with your tool and see how they struggle with it聽聽
[816]
and where you need to improve or if it's really聽
easy for them to fly through then you're like wow聽聽
[820]
yeah we got this so things like that is what聽
you try to get when you do your uat testing聽聽
[826]
so just to recap the documents that a business聽
analyst produces the business requirements聽聽
[832]
document or the brd or the frd or the systems聽
requirements specifications srs so that's the main聽聽
[839]
document in a waterfall environment if you're into聽
an actual environment you're going to be producing聽聽
[844]
user stories that's the main document in a user聽
store and it's not really a document because we聽聽
[848]
think of document like some big file you know聽
the the user stories are going to be small聽聽
[853]
stories that are going to be a part of whatever聽
tool you're using normally jira and they include聽聽
[858]
their acceptance criteria so that's the second聽
thing that you produce um you're also producing聽聽
[862]
mock-ups and wireframes um and it doesn't have to聽
be pixel perfect doesn't have to be exact it just聽聽
[869]
needs to represent what you're trying to build聽
scope document so you create a scope document to聽聽
[876]
delimit what you will build and what you want or聽
what the process will have and what you won't have聽聽
[881]
so you can make sure you set the right聽
expectations walk through presentations聽聽
[886]
so you're doing your walkthrough presentations聽
because um you want to document the process and聽聽
[892]
how it's going to go and normally you're doing聽
this before you're finished so you're doing聽聽
[895]
it to kind of evaluate and to let you know get聽
feedback from the people who can make decisions so聽聽
[900]
that's your walkthrough document you're doing a聽
uat test so the uat test is going to be helpful聽聽
[905]
to make sure the user can understand what you've聽
done to make sure it's user friendly enough for聽聽
[909]
them so you're doing a uat testing you're going聽
to write your t test cases for that and you're聽聽
[914]
also going to be writing um use case use cases聽
so you're going to be writing use cases and it聽聽
[920]
depends on your environment whether it's going聽
to be a use case such as a uml kind of use case聽聽
[926]
or just a use case being a document that explains聽
how something is going to be used or is being used聽聽
[931]
okay so those are the eight documents that i think聽
every business analyst need to know how to write聽聽
[937]
okay this is imperative this is important this聽
is how you define yourself as a business analyst聽聽
[943]
right so this is going to be very very vital for聽
you to know and again go check out my videos on聽聽
[949]
how to do this and i hope to see you guys next聽
time please check out my website karaleise.com聽聽
[955]
please check out the sponsors of this video聽
like and subscribe to the video y'all like and聽聽
[960]
subscribe and show me some support okay i'm giving聽
you some free information you're going to give聽聽
[964]
me some support by subscribing all right so i'll聽
see you guys in the next video we talk about more聽聽
[970]
interesting and important and career advancing聽
topics to do with business analysis technology聽聽
[977]
product management and all of that stuff okay聽
i will see you guys next time take care bye bye
Most Recent Videos:
You can go back to the homepage right here: Homepage