The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Hi everybody and welcome back to
the Better Business Analysis podcast with Benjamin Walsh.
And this week we are going to be talking about detailed level
requirements analysis, sometimes just called detailed
requirements. This is a very important phase
throughout the Better Business analysis delivery journey.
That's an era that's I think a little bit misunderstood
especially with the development of Agile.
There is a I guess a good way or a way that I talk about detailed
level requirements analysis is that it is where the detailed
functional non functional requirements of the solution I
talked about I explained in a lot of detail and it follows on
from the high level requirements base.
And then generally you could think about that in terms of
epics and then being broken down into user stories.
And it's an interesting factor because it's it should be the
transition here. This should be done with the
solution provider. The development team should be
part of this June. So for me, a great transition
between a highly functional upfront project team and the
development team or the delivery team is at this point.
So before you start the detailed requirements analysis space, and
that is so you've done your high level requirements, you've
really worked out what scope is. You've got your chunky epics and
you may have a first kind of user stories.
And so this is all you know done on journey maps and you've got
your kind of story story mapping down to what you think is the
general idea about what net is required in order to deliver the
solution. And this is where you engage
with the vendor who you're working with, the vendors that
there's multiple and the development team.
So we're just going to call those people the development
team or the delivery team as opposed to you know, talking
about all the different use cases or different types of
delivery that we might have. I will say that if you're going
out to RFP, then some kind of tendering, then if you are not
just getting information. So RFI, which stands for Request
for Information, if you're asking for a proposal, it it is
your responsibility as BA to do some level of detailed analysis.
High level requirements aren't genuinely enough to go out to
RFP because there are, and we'll talk about it in a minute.
Some of those functions and some of those business rules are only
captured once you start your detailed requirements phase.
Now that doesn't mean you need to spend six months in a room by
yourself writing these requirements.
This is very much just a layer down.
If you think about it in terms of processes, you are getting
down to that kind of process of the three and you are talking
about specific functions you want your user or your customer
to experience. Now they need to be flexible.
Obviously how a customer is able to carry out those functions
could be quite different if the response was from what we call a
cost system, off the shelf software where you have this
commercial off the shelf software is what COT stands for
or a SAS solution which is effectively a cost system in the
cloud. Now they might come back and
say, well if you want to do it exactly the way that you've
specified in your detailed level of requirements, then that could
be a change. And so there is a negotiation
here. It is still agile in terms of
working out you know how many points, you know more dollars
and how much effort it's going to take to meet the requirement
and then when you see the solution.
So it's a two way conversation and they say, well you know
you've said here you want users to be able to add information on
a customer contact screen and they say, well now it's an
application we have that you know spread across two screens
and you could say well okay, the Y here for that requirement is
around being able to capture customer details.
And actually the fact that your solution does it over 2 screens,
we don't require you to customize that solution to have
it on one. We were just giving you an idea
about what that requirement was in terms of capturing
information. And so these are the kind of
conversations you have with vendors as you go through the
RFP process. And an RFP process, if you've
not been involved in tendering, I suggest that you do learn
about these different types of tenders is very robust.
And if you've been involved in an RFP process, either replying
to or issuing an RFP process, it is, you know, it is not a small
task. And there is a whole lot of
probity involved in that process where you have like a committee
of people who are voting on responses and you have a way in
which you great responses. And it all has to be fair and
you can't have any conflicts of interest here and you really
can't in some cases, I've been involved in one where we
couldn't have open dialogue with other members who were reviewing
responses. And so throughout that you might
have a stage where you're getting vendors presenting back
to you who you know your, your shortlist might present back to
you as part of that process and you can have these
conversations. And then you generally at the
end of the process you engage with one and then you can, you
know then you go into what I would consider a delivery phase,
what we call delivery and requirements management phase
here at a Better Business analysis institute, right.
So excluding this RFP, you know vendor selection process, let's
keep it really simple and pretend that we've got a
delivery team, development team which is in our organization or
you know our partner that we use and they run development really
well. So they take their input as
being high level requirements first cut user stories backlog
effectively we as a BA work there.
We're on behalf of the the, we are the customer if you like.
We've got a product owner who owns the outcome of this phase
for those products. And we we're facilitating in
terms of maybe we're helping the product owner elaborate on
requirements, maybe we're doing some of the lower level business
rule definitions and logic. And we have been the BA who has
worked out that there is a business need for this.
Let's just say it's a new product, OK.
And in the simple term we'll talk about a web application.
So we'll just talk about a very simple, maybe a mobile app and
we have a product owner who's come from the business, who's
going to own this product, which we are going to call diagnosis
card, diagnosis mobile app, which will diagnose faults for
your car. And not only will it do that
through a device that you plug into your car, it will tell you
what's wrong with your car and recommend solutions and provide
you with options in terms of what your, what garage you could
take it to and how much this might cost.
So effectively taking away the control of what's wrong with
your car to yourself as an individual and then you get
choices around how you can get your car fixed.
So this is a, you know, a business that could exist and we
have a product owner who's gonna, who's gonna own this,
this app which we'll call car diagnosis, just call it Car
diagnosis, very simple, it's not a very sexy name and we are now
they've been allocated and we've we've been involved with maybe a
product manager and we've tested the market.
We believe there is a market and now we're going.
Now we have our high level requirements which have already
been written. We've already had the business
case put together. We're now moving to the detailed
level requirements analysis. Now detailed level requirements
analysis is the process of analyzing and specifying that
detailed, like we said, detailed functional non functional
requirements of the solution. It involves taking the high
level requirements gathered during the requirements
gathering phase and breaking them down into specifics and
actionable requirements that can be used by the development team
and designers to build the solution.
OK, it involves effectively 6 steps.
You want to refine the one so the BA works with stakeholders
and the Product Owner to redefine and refine and get down
to the lower level of the requirements to shoot, to ensure
really that they are complete, they're correct and they're
testable. So they really it.
It does require going down to very much one step away for from
the house steps. So we need to be able to specify
the requirements such that the developer can read them and
understand. And the response being, this is
how I'm going to meet that requirement.
I understand Okay cool, You want a landing page where users can
read information around how the application works and they get
to sign up on that page or download the app and they can
then visualize how that might work or you know relate it to
other work they've done before and they can start to size that
work and they do that through story points most of the time.
It's a sizing technique which allows them to kind of
guesstimate how long things might take.
And I would say that that delivery cycle, so the
delivering requirements management phase we call it,
which is really a crossover with a with a PO running that phase.
That's where Scrum is a really good technique to use in the
agile world in terms of having developers using story points
and Kanban and sprints and breaking other work.
So you have an idea about how long things are going to take
and then you get one slice of the solution in the end in the
first release and then you keep you know working on those
features as they become a priority, ideally based on
customer feedback. But to start off with, you do
need when it comes to products and apps.
You do need to be able to somehow demonstrate the end to
end business flow for a user or customer.
Journey flow if you like. And so that's generally what it
focuses on your first Sprint, it refers 2 weeks.
What the BA does is one you refine the requirements.
And generally this is even if you have a very agile focused
team with a product owner. The Bas usually find a
subservient BA to a PO doing this work.
They're very good at doing that. You need to decompose the
requirements so the high level requirements are broken down
into more details. So not only do the effort
requirements, which are your high level requirements get
broken down into user stories. User stories can be broken down
into further user stories based on the feedback you get from the
development team. So if the user store is too high
level and it can't be completed in one Sprint then it needs to
be broken down into smaller work items if you like.
Also, what I would find is a good idea is that we start to
talk about acceptance criteria and I'll get to that in a
minute. We need to identify what we call
the use cases. So this is a word that used to
be associated with UML. Well, it still is and waterfall,
but it's still applicable no matter what environment you're
working in. Maybe you're working in an agile
environment or a waterfall environment or a mix.
Because to be honest, no one works really in a pure waterfall
environment anymore. You still need to know how to
write use cases and scenarios. So use cases and scenarios are
identify how the system will be used and it's used to validate
the requirements. So it's like, right, we've got
this function, how's a user going to actually use it
logically? And so your job as a BA is to
explain logically how that's going to work.
Not necessarily and even conceptually, but it's not your
job to specify the solution. It's your job to say like a
comic book strip and say okay. Well, a user will view this
landing page and they'll be able to navigate down to a sign up
button. And you didn't describe like a
story, which is where the word use case came from.
So these scenarios comic books are a really good way of
describing it, good technique for doing this as opposed to
stick figures and boxes, which you can do, which are
traditional use case diagrams. This is for you to see if
there's any holes in the requirement flow.
This is your job to make sure that, OK, well, I guess if we're
doing diagnosis, we need some business rules around connecting
to the device that connects into the car.
How long do we wait until the connection fails and we time out
and say we can't find it? Because if we keep connecting
through Wi-Fi, we're going to drain both the mobile app and
the car itself. And so these, these pieces of
logic are the Ba's responsibility.
And they do. I do find that when you work
with some pure Agile Ba's, they forget that that's their job and
these business rules aren't generally well talked about in
the agile world. But when we talk about use cases
and scenarios, these business rules aren't, you know, they
don't necessarily fit into a user story format.
So you generally find that they live in Excel or they're
referenced out. They can be specified as
acceptance criteria, which we'll talk about in a minute.
Okay, so you've helped refined the requirements probably with
the PO you've decomposed the requirements based on feedback
from the development team that they need to be broken down
further in the two chunky. You've kind of identified these
use cases and scenarios. So it's almost like how will
these functions be used? Not not in a conceptual way, not
necessarily the end design or solution that's going to be
there. And you can talk about it with
the development team and the designers that can give you
feedback. And then you need to analyze and
specify the functional requirements.
So the functional requirements are the detail around the
inputs, outputs, processes and user interfaces.
So you need to think about it from all those point of views.
The function could be with the system itself, so in this case
the mobile app or the device we plugged into the car, so the
users interface with those. So we need to, I don't know,
plug the device into the car. We need to be able to download
the app, we need to log in all those kind of interfaces.
If you like web page interfaces, then we need to think about the
processes that need to happen so they're not.
Like I said, the connection process to the device from our
mobile phone might connect to this device via Wi-Fi or
Bluetooth. And so that connection is
between two devices, it's not between us as a human or the
user, it's between two devices. And so those we call both the
systems and the humans, actors, regardless of the human
characters in this game. And so to outline how the mobile
app will be talking to the device we plug into the car, we
still need to talk about that process regardless of the fact
that there's a user interface or not and somebody else get a
little bit caught up and don't actually just thinking about the
user interface. Here.
The user experience behind the scenes, your job is to outline
through sequence diagrams maybe is a really good way of doing
it, or through these use case diagrams to show that the
systems need to talk to one another and how they might do
that in theoretical terms. And then work with the
development team on how that might actually happen.
Now you might hear with APIs and things like that.
And then as part of the functional requirements we also
need to talk about the inputs and outputs to the process,
which are generally things that aren't necessarily to do with
the application, but things that need to be true.
So for example, the final step on our card diagnosis that was
to e-mail out the results to our e-mail address.
Thinking about that output and defining how that might work is
definitely part of the functional requirements.
So anything that's functional in the greatest sense of the word,
not just the user functional and functions of the system is
functional requirements. Then we get down to non
functional requirements. Now non functional requirements
include things like performance and security and usability
actually at a high level, and there's actually a defined list.
Sometimes an architect can help very much with these things.
Usually people that are more attuned with how systems work
and their capabilities can help define what is the modern
standards for non functionals. These are incredibly important
and are done notoriously badly by BAS by the way.
So there is almost a checklist and you can go to New Zealand,
you can go to DIA, They actually have a cloud assessment
spreadsheet you can use, and it has a whole lot of nonfunctional
requirements you need to think about.
One simple example, if you don't know what a nonfunctional
requirement is, it might be the capacity that a website can
handle. So for example, there was a
common situation in New Zealand where there was they were
opening up the tickets to be able to come into New Zealand
through this kind of. During COVID they had a certain
amount of places for MIQ and the nonfunctional requirements for
how they would handle web traffic to the website wasn't
really thought about. So they had the functions
working really well. So the function that was working
but when a non functional requirement isn't met, and
sometimes that can affect users. And in this case they just had
too much traffic and they hadn't talked about capacity to manage
that. And of course the website
crashed and they had to come over come up with to change the
way the functions work in order to deal with that.
So non functional requirements are extremely important.
It is generally falls to the VA to do them or at least
coordinate getting them done. But like I said there's pretty
standard list these days and if you're working with a vendor
especially in the security space, there are some you know
minimum standards legislation that you have to make.
Finally the last step. So we've refine the
requirements, we've decomposed them, we've identified those
kind of scenarios and use cases and I would say business rules
there. We'll come back to what that
means in a minute. You've specified your functional
and you've specified your non functional requirements.
We then need to validate the requirements so the requirements
are validated with stakeholders. The product owner I would say is
a really good person who owns the requirements, makes the
decisions around whether or not they should be in and out and we
need to ensure that these requirements.
Will meet the needs or the objectives of the project and
that they're feasible to implement.
There can't be things that aren't feasible and and just not
possible. If not, not sorry.
They could be very difficult things that our development
teams say they need more resources.
Resources for which is fine, but then sometimes people just come
up with ideas that just aren't feasible to implement.
So the reason why that's important, and I've used kind of
more older terminology here, very irba terminology, is that
regardless of if you're working in an agile environment or a
waterfall environment or a mix between them, these are the
steps you have to carry out. Now you might not, you might
call your requirements, your final requirements, user
stories, and I think you should. But just be aware that you need
both functional and non functional user stories and you
might well have. You need a way of capturing both
how you're going to test these and this is where acceptance
criteria comes in. And you need to capture business
rules, so logic that needs to exist in order to meet that user
story and that is your job. And it's actually some of the
hardest parts of being a business analyst is working out
the business rules that are required in order to make a
system operate on the legislation.
So we'll start with the acceptance criteria.
When you write a user story, you'll see that you've got a
name of it and you use it right. You know as a I want to so that
I can. And then you've got a
description field. And the description field can be
used in multiple ways. For me personally, I don't
follow the book. Here I write, I use the
description field to write a story.
So use a story in the true sense of the word, which explains the
use cases and scenarios in which I want to be implemented.
So I tell a story and about how the user interfaces with the
application, and it's a system. I talk about how the system will
interface with other systems and so forth.
And I tell it in a comic book style, and I elaborate and allow
the developer to read that and then that gives them a better
sense of what's going on. Now that is one way to do it.
A lot of Bas, and actually I've seen this done extremely well by
BA Hype working for me a few years ago, is the description
field is used as the acceptance criteria.
So the acceptance criteria, if you like, are what led on to
test cases. So you state what has to be true
in order for this requirement to be met.
So if we're talking about a landing page for example, you
could say the user can see the landing page.
These are yes, no statements that can be that need to be true
and the ways in which the development team can check off
their work. So I do both, I do a description
and then acceptance criteria actually break down as almost
tasks or subtasks of the requirement now.
So so you can do both and I and I suggest that you at least do
acceptance criteria and if you do 1 technique, one good way of
doing that is to use these kind of subtasks on say a JIRA
ticket. And so you state all the things
that have to be true, so it's all the logical items that have
to be true. And then when a developer has
developed that they can check that all those things there are
true and therefore the user story is complete and they have
to complete all that for the user story to move across.
So they can't partially do the work if they get to a point when
they're thinking about what has to be true.
And the reason why it's good for Bas to specify or have a go at
like sentence criteria first is that that might give them an
idea that the user story in itself is too big to be
completed once Sprint. And therefore it suggests that
that user story should be broken down into many so, so and
sometimes when we write these user stories, they can be too
fluffy and then the acceptance criteria will bring you down to
earth and make them smart. And so if we were to about this
landing page which has, I don't know a log in sign up button and
that's effectively, you know, screen and that's it, it would
be quite it. We would say the user can
successfully navigate to the landing page, the user can see
the blah blah blah. The user can click on the sign
in screen, the user can click on the sign up screen, the sign on
form appears successfully, the user can enter the blah blah
blah. So you you know you're writing
down effectively very high level test cases that in the test it
will take. And then they'll break that down
into things like you know that this field has to be password
protected or that this has to be 100, can only be 100 characters
long. And you as a VA, you know could
feed into that as doing their, as they're doing their test
cases. So this is kind of detailed
requirements. That is detailed requirements.
And when we talk about like the size of fields and things like
that, we start dipping into what I call business roles.
Now you can imagine how big your user story would be if you
started putting all these bits and pieces together and this
should be a conversation. So you might add notes as you go
through. But if you did this up front,
you'd never get to a development team.
So you do this as you're working through the development team and
sometimes I actually literally have an excel spreadsheet or
something like that, or a Confluence page if I'm working
in JIRA when I might specify business rules.
What would be a good example of the business rule?
Say for example we were logging in as we've just talked about
there might be some checks around the fact that we know, we
know there's a non functional requirement, a security
requirement around multi factor authentication.
So two of that and that you know that's if you don't know what
that is, that is where you're verifying you are who you are
using two devices. So your e-mail for example,
which might be your computer and then on your computer your main
device and then your mobile phone as the other device.
And so these days it's pretty common when you sign up
somewhere it will send you a code on your mobile device which
is another device. It verifies who you are because
you need to have both devices in order to be able to verify who
you are and you get a code and you enter that in as well.
And so that two FA process, there are rules for that like it
runs in a certain way. And so by putting in you know
how you want that two FA experience to run.
You can have different user stories.
You would definitely have a user story around user needs.
The system needs to be able to kind of forward, you know 2FA
and you write a user story specific around how what their
experience is. And you say the user does this
and they enter this and they're making a text and they do a
thing. Now, if there's any logic behind
how that might work, it may be best that you just, you know,
point out to a bit of a another diagram or a confluence page or
an Excel spreadsheet which just shows all the business rules
that make that run. That's one example and it's
simplest terms. But when you think about things
like banking and you think about some really complicated
processes, there are a lot of business rules.
If this then that. Think about if statements and
all the things that need to be true and it will just it
wouldn't really make sense to have that detail will just
clogged up and use the story for the developer to see.
So they know they need to meet their requirement and they might
go off to the specific business page to read the logic behind
that. And that is where you find
relative Bas will play as in that space.
And it does cross over to architecture a little bit with
systems analysis in terms of how the system might actually make
this work. Usually find that those people
who play in that space, the Bas who play in that space don't
actually write the code, they just simply are outlining the
pseudo code about how something can work.
And there's, you know, there's definitely demand for that.
And I would say that a lot of Bas might find that they're in
that position, especially if they're in complicated business
role, kind of legislation, heavy environments.
So we come back to the whole point of the detailed level
requirements analysis phase. We are we are defining the next
level of requirement detail and we need to make it work with the
development team to make it really, really clear about, you
know, what needs to happen. And as I said up front, this
could be done before engaging with the development team,
depending on what type of delivery team you've got, or
otherwise it would be done in parallel with that.
So you might be fleshing out requirements.
You may be doing the detailed requirements analysis midway
through the development so it happens in parallel.
So in a true agile environment, you only elaborate the storage
you're working on for that Sprint.
So you as a BA may be going, OK, we're working on the next kind
of user story or the next item in the backlog.
We need more detail. And then a true BA would work on
term that would work elaborating that particular user story at
point in time only when they need to.
So you're not wasting your time doing detailed analysis across
the application. And that's true, true agile.
If we talk about a real example where we talk about our our car
diagnosis tool, then we need to diagnose how that works into
those kind of epic level, high level requirements which before
we start in terms of how they work, which could just be a
mobile app, could be a device plug into the car, it could be a
website. And then as we're breaking down
how that mobile app works, which could be screens and then
business rules below that, it needs to be written in such a
way in which a user can really understand do it.
In the simplest terms, I say that if you're if it's
completely, if it's complex or you're trying to explain it to
users like a product owner, then drawing a comic strip is a
really good way of doing it. It sounds really silly, but
visualizing those steps makes sense.
Definitely a process diagram. And the reason we use processes
is that processes, if you like, requirements can drop out of
processes. So if you, if you really think
about the steps in which that story, in which the user is
going through to log into this mobile, this car diagnosis app,
creating an account, you know, finding the device that's
connected to their car, starting to read that diagnosis
information, maybe making some changes, maybe you know, sending
that information back to their account on the website, seeing
the list of mechanics and the costs associated with their
faults and moving forward. All of that are steps in a
process. And when you talk about the
different levels of processes, the highest level is car
diagnosis kind of is the number one.
Number two is the steps like around acquiring a mobile app
and plugging it in and then receiving diagnosis information
and contacting mechanics. And then at Level 3, just before
the procedure level, you're breaking down those steps of how
they're interfacing with the the theoretical system which might
be, you know, viewing, navigating to the login page,
logging in with your account details.
And then below that is the procedure level which is now now
which is only should only be written once you've actually got
the solution because procedures involve how so down at process
level 4 which is procedure level within outline how that might
happen and a BA can effectively that is what exactly the same as
writing these detailed work ones.
So you're thinking about how this might function in theory
like a procedure level, think about like a Word document and
then the development team you're working with and they're saying,
well you know how you thought about the fact that you know
they could do this. And the designers like well
instead of having a web page, if we thought about this and all of
that works together to help elaborate the kind of procedure,
if you like the detailed level requirement that needs to exist
in order for the story or this end to end process work.
So I hope I have explained what detailed requirements analysis
is all about. It is.
It does either happen in parallel or lead into what we
call delivery and requirements management.
And delivery and requirements management is like I said, it
could be when you're working through that process where
you're selecting a solution. So you've done detailed
requirements, you've issued it out through tender and you're
now working with a vendor to select which solution is best
and you're evaluating it. Or it could be you supporting
the delivery team and requirements management
lifecycle, so that next step. So there is a transition here.
There's a certain amount of work that needs to happen, buy a BA
if you like or buy someone who's really focused on the detail and
then there's the actual doing. So there's the, the second part
of it is the development team now owning the process and
managing requirements. They kind of own the
requirements at this point. The delivery team including the
Product owner and they're kind of asking for more detail or
they're kind of sending off requests and now they kind of
own the requirements. And your job as a BA is you know
he's transitioned off to this development team and there are
Bas who will work in the development team.
It's kind of pseudo writers of requirements for the PO because
the PO doesn't have those skills.
But the true BA work is actually done generally before that in
the delivery and requires management phase that happens if
you like after the detailed requirements phase or these two.
As I've said, these two things could happen parallel of these
detail that needs to happen along the way.
This is where the PO and BA worlds can crossover.
So either you need to decide here if you're working in this
environment what roles you're playing.
The most common is that the BA will become part of the
development team and their job is simply just to elaborate and
explain what was the point of the requirement and to elaborate
on the requirements. The other role is when the
Product owner is outsourcing some of their responsibilities
to the the business headless. So that I kind of but more hands
back they might not know about technology and then letting the
BA run some of those discussions on their behalf and the BA is
advising them. And then there are other
examples where you just don't have a PO.
So the BA is running this with the development team running the
whole process of that just kind of make getting decisions from
the from the product sponsor, the sponsor, the project and it
is acting just as the PO would in the Scrum team.
So there's some examples about what happens next in the process
and that generally you know there are different models
there. You usually find that some of
the junior or intermediate Bas is a really good place for them
to start and then that technology is in the space and
usually find that senior Bas are not generally involved
necessarily once the development cycle starts and once the
detailed requirements are done. But there is a bridge, there is
a, there is a huge market for these for these types of Bas
that are really worrying about the logic and the and the
function and the how and working with architects on complicated
solutions. Actually I'm working on a
project now which involves me wearing that hat around data and
how that might work. And I'm also doing at the same
time enterprise and strategic analysis and working out, you
know, a data strategy. So you know usually find
yourself in more place, especially if you're in a senior
senior role and it's a great place for a junior BA or an
intermediate BA to play cool. So that's my spiel today about
detailed level requirements analysis, and I hope you've
learned something today.