The Better Business Analysis Institute presence.
The Better Business Analysis podcast with Hinjman Walsh.
Hi everybody, it's Benjamin Walsh from the Better Business
Analysis Institute and welcome back to the Better Business
Analysis podcast. Now today we're going to get
into a topic which is something I usually teach Bas.
We're in the intermediate, moving to senior space.
It can be the key to unlock a hack, which a lot of Bas don't
really talk about or use. So I would say that this isn't a
beginner BA topic, but in saying so if you learn this technique
early on, and I didn't learn it until I was much into my senior
BA career, this could, you know, hack your growth.
It's a growth hack in terms of moving your career ahead a lot
of patients, you know, potentially a year to or three.
And it'll and this technique will allow you to steam ahead of
some other Bas who are lost down in the problem that we call
requirements management. And not just the management side
of requirements, but effectively where do they come from?
How do you know which requirements are important?
Which stakeholders may more be more important than others?
How do you know that this solution or this feature, this
user story is more important than something else?
So this I'm going to give you a scientific way.
I'm not going to give you all the answers, but I'm going to
give you a scientific way of applying this technique and it.
This technique is called the PTRT model.
Now, the PTRT model has been developed by the Better Business
Analysis Institute after a lot of thinking, and we're going to
talk about what that thinking is and why.
This is the conclusion we've come up with.
And I guess we should explain what PTRT stands for.
So PTRT is simply processed to requirements thinking.
OK, so we have design thinking in terms of how we design
solutions. We have different types of
hypothesis thinking. This specifically is for Bas and
it is around process to requirements thinking.
Now what is process to requirements thinking?
It's really about the process, how processes relate to
requirements. And at the end we'll talk about
how this model allows you to extract requirements, the right
requirements, the prioritized requirements, the must have
requirements of whatever change program you're working on.
Now there is a science is where we're trying to shove in science
to requirements gathering, elicitation.
And really where this PTRT has come from is like I said in
terms of design thinking and the desire for a customer to
complete a job. We use the term in product
management. We use the term job to be done.
So another way of looking at a job to be done is a set of
process steps that a user or a customer needs to complete in
order to get from A to B. They know the outcome B, the
outcome they want to achieve. They know A, which is their
starting point, but they don't necessarily know how to get from
A to B or they might do in a theoretical sense.
And really when we talk about solutions and two problems,
that's what we're solving. So you can either look at the
efficiency of that process, which is business improvement,
you can look at it establishing a new process, you can look at
establishing a new solution to solve a process problem.
And that's effectively what the discipline of business analysis
is all about. Now before I go into the PTRT
model in detail, I think we should agree upfront because
there is disagreement here by the way, on what types of
requirements exist in the world. And we'll start with what the I,
I BA, the International Business Analysis Association on how they
categorize different types of requirements and they list them
down into 5 categories. And I'll talk about what we here
at the BBAI think about that. There's nothing wrong with this
approach, but it is quite traditional in terms of how
we've grouped and how we name these different requirements
areas. And I'm going to explain what
that I think that there is some fundamental challenge to that
model and the fact that it doesn't help when we jump over
to an agile model cause a lot of this has fallen out of
traditional water for processes of what I would say as being
full blow and documentation business analysis and not Lean
BA which is where we are you know in 2023 or what you should
expect from your BA's in 2023. OK.
So what are these kind of areas or requirements type that we
talk about? The first are business
requirements and here at the institute, we agree business
requirements is a really good term and that these, you know,
these requirements are the highest level what that we need
to capture that we need to achieve in order to deliver on
the business objectives. So business objectives, how we
measure the success of a project and below business objectives we
have business requirements. So solving our business
requirements at the highest level allows us to solve the
business problem which we've defined in problem analysis.
All right. So we totally agree that we've
got business objectives which or strategic objectives of the
business which is the most important thing and I talk about
that and a couple of the other podcasts that we've talked
about. It's all about business strategy
and you know what, why we're doing this piece of work and how
we're going to measure success and below that we have business
requirements. So we start getting to the water
be out here business requirements which come out of
high level analysis. So totally agree that that is a
requirements type. It is the overarching container
of of requirement. Next, the I IBA talk about
stakeholder requirement. OK and stakeholder requirements
are the requirements that the stakeholder has.
It represents their needs, their expectations of the individuals
or group who have you know an interest in the project.
These requirements, you know, you can extract through
interviews or workshopping or surveys and they ensure that the
solution meets the needs of the stakeholder.
So it's it's, it's really important, it allows the
solution to not be driven by it. It allows the stakeholder to
have a voice and in essence we don't agree, disagree with that.
Thinking behind that of course or the fact that you don't talk,
you know you there is no reason to talk to customers about their
needs. Of course there are.
We actually take it even further to customer requirement.
This is where we drift away from the scientific method a little
bit and we can fall into a situation where we end up having
a shopping list and and and some Bas don't even challenge that
problem and they say that's the that's the job of the product
owner. And this is where I completely
disagree with that thinking or that attitude.
Next, so we've got stakeholder requirements, if you like, the
shopping list of things that stakeholders want.
And then and of course that is one way that you extract
requirements, but that isn't the solution or the method we're
talking about. But obviously you talk to
stakeholders, you ask them what they want.
And there's a whole science behind necessarily knowing who's
most, who's you know, who's most important in the zoo, which
stakeholders most important. And you can lead on your product
owner to help prioritize those. But ultimately these it's it's
really subjective at this point. Next on the list of requirements
type, there are solution requirements.
The IRBA explicitly has a category called Solution
requirements which is different to stakehold requirements.
So they jump to the solution side and they say that solution
requirements are the features and the functions and
characteristics of the solution that will address the business
problem. So they have, I guess you know,
derived those solution requirements from the highest
level business and stakeholder requirements and solution
requirements are supposed to provide a detailed description
of what the solution should do Okay.
And at this point again the the we do not believe in the concept
of solution requirements per se. We'll come back to that point in
a minute. However, we do agree that at
this point solution requirements generally in the concept term
can be broken down into functional and non functional
requirements. So functional requirements are
the behavior of the solution that the user's interacting with
and non functional requirements are the actually to the quality
of the solution. So the solution must possess
these things rather than behaviors.
So non functional requirements are things like performance and
security and usability and so on.
So, so you've got those two parts and I agree that that
we've got business that we have business requirements and then
we have these functional and nonfunctional requirements of
the solution. The IABA talks about those in
terms of stakeholder requirement separate to the solution
requirements and solution requirements and which under
solution requirements they have functional and nonfunctional
requirements. So in theory there's no problem
with that model. But here the BBAI we agree that
these that these things could be called solution requirements.
But but actually in a real world scenario all those things in the
solution bucket are called user stories.
When we move into an agile world that there's no distinct
difference between the fact therefore the solution or
stakeholders, they all need to be met.
But there is this difference. We've got these two buckets,
those that the user wants and those in which the solution will
deliver if you like the we'll hold that thought and we'll just
talk about the last category of requirements.
And and to be fair, this is a whole podcast in itself and
probably a book and it's transitional requirements and
these are not done well at all by Bas and are sometimes
completely amidst by agile teams.
Transitional requirements are activities, tasks and conditions
necessary to transition from the current future state.
And if actual tangible things like data migration, plan
training, you know, change management, implementation,
planning, and a lot of times B A's are very, very bad at
defining these, I wouldn't say I'm particularly that great, but
they're things that need to be done.
And so yes, I do agree that they are a set of requirements and
they usually never define and use the stories or backlogs, but
they could sometimes be sections within your requirements pack.
I think they should be. And that's how I do them today.
But they don't necessarily use the stories in themselves.
You could argue their tasks within the project that need to
be complete and they're usually owned by things like the change
manager or the trainer, or you know the project manager
themselves. And we as Bas would be a
subservient there and it would help on because those need to be
done and you know you all muck in.
Be a good ba mucks in. That might not be your primary
ownership or focus however okay. Cool.
So the BA separates, as I said, sorry, the IABA separates the
stakeholder requirements and solution requirements.
So what the user they they separate what the user wants
from what the solution effectively does.
OK. So that's that's the difference
there. At the Better Business Analysis
Institute, we believe that the solution only exists to help the
user or customer get their job to be done OK or get their job
done. So we talked about that before
for the truth that we believe that you know they're
intertwined. They're completely intertwined
with one another and they need to be treated in terms of the
statements, the user stories or the requirements.
They need to reflect both the stakeholders prioritization,
which is the so that I can and the why needs to represent the
stakeholders prioritization or how they see held.
This is important, but not only are they these stakeholder
requirements, a way to drive the prioritization of a solution
requirement, there's something else missing, which is the fact
that in order for a customer or a user to get their job done,
they have to actually follow a sequence.
They have to get from A to B, and there will be a number of
steps in which they need to follow an order in order to get
from A to B. Now, those steps could be
completely different depending on the analyst that's involved.
But the stakeholder requirements for what the IOB A calls the
stakeholder requirements, I'm going to say there is some truth
to the sequencing in which a user needs to interact with the
system or, you know, follow a process step from A to B, and
that is the size. So how do we define the A to B?
How do we define getting from A to B?
How do we actually do that as a business analyst?
OK, so we'll step back. The I I BA has defined different
requirement categorization with business requirements completely
on board with that. Then they define stakeholder and
solution requirements separately and under solution requirements,
they have functional and nonfunctional requirements.
And finally, if you like right down the bottom, there are
transitional requirements which are tasks that need to be done
in order to deliver a change. Quite happy with that and
conceptual world and an agile world.
I'm just going to restate those business requirements are at the
highest level. They can also be called Epics
and I'll get to that point in a minute.
And what I would say in an agile world solution requirements
regardless of functional, nonfunctional requirements, they
use the stories and generally transitional requirements are
tasks. So if you live in an agile
world, that is the name you give to those same areas.
And here the BBA I we don't disagree that there are that you
can break requirements down that way.
But what we say is that user stories, you know, leaning on
agile and we'll get there in a minute, that user stories that
solution require solution requirements aren't any
different or shouldn't be thought about as separately to
stakeholder requirements and they need to come together.
And now we're going to talk about how we make that happen.
All right. Now before I tell you all the
secrets about PTRT, we are going to go back in time.
We're going to go back and look where requirements modeling was
first standardized for software development because there was a
lot of signs back then. It was quite different to where
we are today. We're a little bit looser and
and that's good. That's given us flexibility,
that's given us, you know, excuse the pun agility, but
there was some science back then and I'm going to, I'm going to
lean on that and explain what that was back when I was at
university and explained A technique that's very useful in
the agile world for doing this. And then finally summarize what
we take that to the next level. You as a BA, what that means in
terms of process to requirements thinking.
OK, so I went to university in the 2000s that shows my age.
I did a computer science degree, actually, I I actually studied
programming, but I enjoyed the systems analysis papers the most
as well as the economics business papers and psychology
papers more so than I did any programming.
I wasn't particularly that interested in terms of that or
it just wasn't as good as everyone else in the class.
And maybe that's what sparked my interest in terms of other
areas. But either way, when we learned
what was called systems analysis back then, and when we had to do
analysis papers, we learned something called UML.
Now if you haven't heard of UML before, that's OK.
I'm sure those who are over 40 may have heard of UML.
Or if you haven't, and you're in the Agile world, I wouldn't
surprise if you just haven't heard of it.
It's really important to understand what UML is.
It stands for Universal Modeling Language and if you've ever used
tools like Rational Roads or Enterprise Architect or tools
like Visio or Draw dot io, you sometimes see names of stencils.
And this might be where you've heard some of the terms that
relate to UML. Not only that, you may have
heard the term that's used in language quite often, which is
called Use Case and Use case. Use Cases and Use case Modeling,
comes from UML. So what what you know what was
UML and what did it kind of what we we what do we used to use it
for And we still use it this way.
By the way, a lot of Bas who especially those in the
technical BA space, use UML. I still think it's fantastic to
do. I think especially if I'm doing
a new system project, I'll use all these techniques in one way
or another. Maybe not to the nth degree, but
definitely the the concepts behind it.
So UML is a standard visual modeling language.
OK, it is used in software engineering to design, visualize
and document software systems. But there was science behind it,
and the science can be used in your business analysis every
day. OK, so when you heard the word
systems analysis which was the precursor to business analysis,
effectively UML was used to outline the requirements of the
business. OK, so UML provided A graphical
set of notations for representing aspects of systems
or solutions effectively. OK, and you could use that for
non IT systems. In some ways it talked about the
structure, the behaviors and interactions of the systems and
Bas use UML or you know, those who are moving into the BA space
at this time for their requirements analysis to
effectively communicate and document system requirements or
solution requirement. And that's where the word
solution requirements has come from.
And I in my mind the IABA has evolved from the point to still
talk about it. The solution requirements, as
the IABA talks about this was a way of talking about it.
And there are a couple of. Diagrams for getting there OK
that are worth noting. I would say that number one is
what I talked about for which is the use case.
So the use case use the scenario use case Use Case Modeling is
the diagram that we use. But there's also almost a
reference sheet that goes along with this was use.
I'll just talk about the model to keep it simple.
Use case model I personally use. I still use them a lot, know a
lot of BA's don't do. It's usually associated with
waterfall or traditional requirements management, which
is probably why it isn't used these days.
But it's still a great technique.
So use case diagram is simply a stick figure of a person.
It has representations of a database or a system External
systems with arrows like 20 arrows to these round ellipse
circles, and in those circles are the function in which you
want the user to perform with whatever it's connected to.
And you can extend these use cases to talk about extensions
that can happen. You can show child use cases at
this point, and you can do and there's usually a little write
up for each use case which talks about what has to be true
beforehand, prerequisites and postrequisites of performing
that function. And so you might have seen these
diagrams before, they were not focused on sequence, so they
were just a brainstorm of all the functions that the user very
much called. The user back then wanted to
perform with the system and what that system would then
necessarily have to then communicate via just an arrow
back to the user or their response to the function.
So that was that's quite very useful for documenting the
functional requirements of a solution.
And because it was visual, you might start thinking Oh well,
what needs to be true in terms of timing and and and in terms
of security. And because it was visual, you
could, you know some non functional requirements would
drop out of that. So it was quite helpful in terms
of capturing the system's intended behavior.
And you know it was I guess useful in a very very simple way
of doing that. So you can still still use that
process and the next, I guess important function of your Now
one of the diagrams there is called the activity diagram and
so this was the flow of activities that the system
needed to perform, if you like, the processes within the system,
So what processes did the system need to do?
These diagrams helped in the understanding of the sequence of
actions and decisions and parallel activity.
So again, talk about those stencils.
Sometimes when you go to draw a flow diagram or a BPMM process
model, you may see an activity diagram as the name of the
stencil and so there are some you know, there were techniques
and notations and special, you know, depictions that you needed
to use. But effectively, if you can
think of an activity diagram, think of it just like a system
diagram. Sorry, process diagram, but very
much down at the system level. OK.
So that's kind of an activity diagram.
And then we had class diagrams and class diagrams were what I
talked about in terms of business entities.
So if you were doing creating a system for a mechanic, a class
diagram may be Car and Customer might be your two classes and
Cars might be associated with Wheels, which is another class
and class. Each class has attribute.
So for example a car could have an attribute like I said wheels
or color or make. And then each class has
functions and like actual system functions they need to perform
which might be create new car, update car details.
And that's how you started to get the system functions that
needed to exist. And so this was logically what
needed to actually happen. And so this logical diagram or
conceptual entity diagram, class diagram is where you differ with
programming and programmers could then take that and then
they could actually write classes with with you know in
code if you like. And then they also allowed you
to associate entities. So you knew you had to have a
car, there might be one car and a car has multiple wheels.
So we we have something called A1 to many relationship there.
And so it helped with database structures is well in the data
model. Next we had the sequence
diagram. So the sequence diagram was a
drawing of our of our people where little stick diagrams but
it was showing the sequence in which a transaction would take
place. So when I say transaction I mean
that broadly an interaction. So it would say for example, you
drop your car at the mechanic, the mechanic adds car to system
and it would have a little arrow showing sending the car name if
you like or the car details for the system and it might return a
message saying car added or then you're prompting you for the
next step. So it was a visual depiction of
the logic that needed to happen was system interactions down at
the, you know at an interaction system level.
And that was effectively showing when functions would be called
in what sequence again helping when you programmed and actually
in terms of seeing how a system would actually work and you
would and there were there are actually other diagrams that
there's some main ones there there there are others But the
idea was you were trying to effectively communicate system
requirements and show that used to actually show that to users
and show this is how it's going to work.
So they kind of had to understand your amount to a
certain degree. It was quite simple to
understand and and some some cases you know this would help
you write code. But equally then you could
visually show how the system was working and where you had
questions. So you were using that and so
customers were kind of having to interact at that level okay.
So that was that worked very well.
But it was very scientific and very close to the outcome in
terms of the solution outcome, but you could say it was in the
lens of the system, OK. And so and and so it allowed you
to not miss anything when programming.
So you knew that all these things, you knew exactly what
the critical items were. So back in that kind of
traditional way and I'm not saying that it's necessary.
We're throwing that out. That would allow you to make
sure that whatever you delivered, you got your customer
from A to B quite easily. OK.
But we've moved away from that a little bit and what we've done
and with the evolution of design thinking, I'm not even talking
about Agile, which is a little bit lower down.
We've started to think about the customer, right.
And we want to capture our clients at a customer level.
So we use things like now I guess 20-30 years later, we talk
to our customers in their language and the language they
understand and we use other techniques for doing that.
So we use what I would say is a top down technique and so first
we find out what they want to do and then we outline that in a
customer journey map which is which is a process diagram at
the highest, highest level. Service design if you like
what's even pre service design. So you're you're working out
what they need, what they need to perform and where their pain
points are at the highest level and that's what we use you know
design thinking to elicit what they're trying to achieve.
And so we're using their language.
OK, now that's great. But then we then get into, as
most teams are working in these days, some kind of agile
development method. So how do we then get down to
the next level if we're not using UML?
How do we make sure that the agile development team is
delivering the logic and making sure that whatever we deliver
actually gets us from A to B? Because what I would argue is
that in a backlog management these days, you have a whole
collection of things you could do which isn't necessary, the
linear path from A to B, the most efficient path.
And so therefore, and I'm not necessary to about the most
efficient, but literally the fact that the person wants to
achieve that that goal from getting from A to B in a pretty
damn good time. If you actually track the
success of the process they're trying to achieve and how how
that relates to your delivery or how that relates to the delivery
of most agile delivery teams, you would see that they are not
necessarily aligned. And that's because
prioritization of the backlog and what goes into the Sprint
can be relooked at every time you finish the Sprint and do
Sprint planning. So that doesn't naturally take
you necessarily back to the prioritization of what of the
job to be done. It prioritizes in terms of the
features and what you're focusing on now.
And that isn't there isn't anything within Scrum planning
for example, that says anywhere there that goes, OK, well are we
doing the most logical sequence, are we following the the most
logical sequence And are we filling all gaps in the customer
journey here? Are we actually, you know if we
released another way of saying that is if we released our
product tomorrow, would a user be able to achieve their goal
from getting A to B? There is no challenge or
particular I guess ceremony that asked that question.
What it says is that have you and there's a couple of 1 liners
about saying that when you do release the the the idea is that
it that it's at an MVP stage at each time it's a slice of the
solution and you can get from A to B right?
But there isn't necessarily a bite in method for allowing us
to do that. However, quite a few years back
there was something that was introduced in the Agile world
called User Story Mapping and this is fantastic.
User Story mapping is a visual tool primarily that came from I
guess from agile thinking. It's around making sure that
even though you should, you know, focus on what matters for
that Sprint and you know, don't just take things off the backlog
and work in a waterfall manner. It allows us to take something
from, I guess the same reason why UML exists and the same
reason why traditional requirements were done in the
way they were doing by making sure that there is a backbone.
It's literally called a backbone that the backbone requirements,
the must have requirements are done.
So regardless of where we then spend our attention or where we
decide to refine our requirements, we've still got a
backbone the user can get from A to B Okay.
Doesn't have to be the most prettiest way, but they can
achieve their job to be done. So if you if you don't know
about story user story mapping or story mapping for short, it's
fantastic. Okay, it's not.
User story mapping isn't about just throwing all the user story
map visually up on to a board. The purpose, the underlying
purpose is trying to show along the top.
So along horizontally along the top of this visual board you
show the customer journey. And the customer journey or user
journey is what we talked about in terms of job to be done.
They are the steps, the sequence of steps in a specific order
from getting from A to B. OK, so it's defined by, you
know, ideally it's been done by your human center design team or
just the logical steps that have to happen to move from A to B to
a point that if you don't know what those are, maybe you know,
applying a bit of UML, looking at a sequence diagram will soon
tell you what has to happen in order to send information back
and forth or interactions back and forth from, you know, the
various actors in the system. Okay.
So. So that's really important and
that this is where I think a replacement for the idea of
looking at stakeholder and solution requirements starts to
show itself. And I'll come back to the fact
that I don't think that solution and stakeholder requirements
should be different things. And I'll talk about how I think
those could be helped using this technique called User Story
Mapping. So a guy named Jeff Patton put
together a book called User Story Mapping.
I would suggest you check his book out.
It's a as As he says User Story Mapping is a dead simple idea
and it's the reason this is what User Story mapping can can
confuse some Vas or those in the agile spaces.
Along the top of your user story map you should have the high
level activities a user needs to achieve.
A customer needs to achieve to to get their job to be done Okay
or use the product or or or interact with the system.
Now they are epics. I'm going to say that again.
The top level of your user story map should be your epics.
Okay that's what User Story mapping talks about.
And below that you have story, okay, you have stories, user
stories that that fall under those categories.
So user story mapping allows us to categorize our user stories
into these very various horizontal categories, just
analyst. And then as you talk about what
you're going to release in terms of that Sprint, you would then I
guess circle which of those user stories horizontally in the user
story you're going to deliver on that Sprint.
So it dictate that that Sprint I call that iteration needs to
include our story or at least needs to needs to in the first
Sprint include our story from each part of that user journey.
So, so you know that at least something's been done in each
area of that each of those effects have been met.
So if the epics are being met, as we've just said, the job can
be done. So therefore if your spring
incorporates one, at least one user story from each of those
parent epics, then you can be sure that the end of your Sprint
or your integration will deliver the job to be done in some form.
It's not saying it's the best way.
It's saying that you know effectively you've done a slice
of the solution that will be the final solution.
And so it's a really good way of making sure that visually and
the team knows that they're delivering, that whatever
they're delivering is valuable straight away at the end of an
iteration. And reality that isn't, you
know, there are all sorts of different kind of sprints in
terms of we know we want to work on this one area, but to start
off with and to be true to Agile, that's exactly what it's
all about. But, so user story mapping,
please. Sorry, I'm going to say user
story mapping. Learn about it.
It's a fantastic technique if you're an agileist, if you're
working as a BA and an Agile team, If you actually care about
how traditional requirements map down to user stories, user story
mapping is the missing element in your life.
But I'm now going to talk to you about how if you incorporate
user story mapping, design thinking and what I talked about
earlier in terms of UML and going all the way up to our
requirements classifications, why it's important for us to
take that further if you're in the kind of intermediate senior
space. And this is where we we fall
into what the podcast is all about, which is processed to
requirements thinking. So what do we know before we get
into a bit of what do we know before we get into a conclusion
here? We know that a user story
mapping is a great technique and it solves many problems with the
agile teams delivering part of a solution and not an intense
solution. So it puts focus on the delivery
to make it logical. And it does that by introducing
epics along the top of the user story map, which is suggestive.
It's suggestive because it's suggesting as we've said earlier
that business requirements which I'm saying are what needs to be
done to reach our strategic objectives or the job to be done
is 1 and the same as our epics. So if all our epics are done,
then in theory our objectives are met.
So our business requirements are mapped are one the same as the
epics. And you might say that's not
new. We've talked about that before.
That's not a problem. But it also suggests that our
epics are the highest level steps or process steps that a
user needs to go through to complete the job to be done.
And this is the hack. This is the trick that
effectively meant that if we know the highest level steps
that a user needs to go through, our epics are our process model.
I'm going to say that again, our epics, our requirements are one
and the same as our process model at the highest level,
which means that our requirements can come directly
from the process model. So what does that mean for the
model when we talk about stakeholder and solution
requirement? Well, here at the Better
Business Analysis Institute, we write our process models such
that we are talking about the user, we're saying what they
want to achieve. We do that in a couple of way.
One, when we process model, we always depict who is carrying
out that activity. We have a little actually use
shapes and now a template for who is the actor, Who is the
person that needs to complete that step.
It can be a human or it can be a system of some description or
multiple humans. They're performing a process
step, right? So they're doing something.
So let's take our carton mechanic example.
You could say that the customer, the new customer because they
might not be an existing customer.
So you get down to some level, the new customer is takes their
car to the local mechanic and then I guess there's a note that
they haven't visited that place before.
So they can get their car serviced because it's due for
its service check. That's the kind of you know the
note behind the process step. Now that one step is could be
the first step in a sequence of getting their car serviced at
the mechanic, right? So you can you can imagine what
those steps might be along the way.
But let's say is our first step. You could argue there might be
steps beforehand, which is another process you go into
which is around finding out about this new place, knowing
that your car needed a service and you've got to this point.
So let's just say this this is our starting point.
But we know that in in in theory there could be steps beforehand
that process step. Can be one in the same as the
Epic, which is to take your car to the mechanic.
It doesn't relate to a system, but taking the car to the
mechanic, the local mechanic is your highest level epic.
You'd write that in a in a user story format of course.
So as a new customer, I would like to take my car to the new
mechanic so that I can get my car serviced and experience
their service for the first time.
Okay, there might be reasons around it that they got a deal.
So the so that is the stakeholder driver or motivation
for wanting the requirement. That's the prioritization.
They're wanting to test the service or see if it's cheaper
than the alternatives could be the so that and so that's really
important. But you would notice, you may
have noticed this. I did say it very quickly that
there are a couple of things that I said in that epic that
was very useful. One, I defined not as a user, I
defined as a new customer. And so that linked to the desire
of that stakeholder group, which is quite different from any
other user, a new customer, someone who hasn't experienced
this, this mechanics before. So if you're not lazy with your
requirements modeling and your process steps, then you've
actually defined those up and that's quite a specific use case
there. And you've talked about your
personas. So again you've incorporated the
stakeholder in the process step that you are modeling.
And secondly, I said at the local mechanics and I talked
about or at the local new mechanic, I talked about in the
user story or when you could say with the local mechanic I added
that to the user story. I didn't say I wanted to get my
car serviced so that my car could be serviced.
I said whether or at this particular location.
So by introducing the business entity or the thing in which I
wanted to interact with enhance the process step and actually
the requirement itself because we know if we look back at UML,
there's a sequence of interactions.
So being me taking my car to the local mechanic for the first
time as a new customer means that there would be a function
that needs to occur at the mechanics which is accepting me
or adding me to their database or you know, there's a response
to that. So in your our land you could
model that through the use cases but and also in terms of the
sequence. So that's quite interesting from
that land. But what I'm suggesting equally
is that that epoch, if you've would drop out of that process
model, you have all the attributes of that epoch in that
process step. So if you've done your process
modeling at that level and you've talked about it from the
customer journey that should fall, that should be your epoch.
So your process step if like I said done correctly drops down
to your requirement. Now we know that Epics get
elaborate. We know that in order for an
epic to be met, we talk about a mix between the what we want the
customer to do and the how. So and that example of taking
our car and maybe the new customer drives to the local
mechanic and drops their car off so that it could be serviced at
that on you know on that day for example that could be your user
story. So driving the car to the
mechanic now I'm I'm, I'm purposely keeping life from kind
of system requirements. You can think about it in a
process term, but that that could be our user story and will
say drive could be our first release.
We're just doing, we're just assuming Drive.
But in the future you could say, well you know, there's of
course, you know, you could take your car to the mechanic, but
you could potentially say that this app, I haven't talked about
what this app's about or this business, it could be about
concierge, it could be about someone else coming to your
house and taking your car to the mechanic.
And that could be the first, you know, the first enhancement we
start talking about if we've completed enter and customer
journey map. So if you think about the
requirement of driving, which is now a mix between driving, so
getting the action behind the epic, if you like, one of the
possible actions of achieving the Epic, that's how I use the
story and we might elaborate on that in terms of how we do that.
You could argue that that's a subset of a process step, right?
Taking as a new customer, taking our car to the new mechanic.
A process step is driving the car you know down the street to
the mechanic is a is a what how requirement down at the user
story level. You could argue that that is
just a sub process step as one permutation of a process step at
a lower level. So you could argue that there is
a very, very close relationship and I would say an exact
relationship between process modeling at a lower level and
your user story. And the science behind that is
that is exactly what you now was about when you broke down the
various functions and the functions within a use case
diagram and you started talking about steps within the use case
diagram. And then you talked about the
sequence in which it needed to happen and you talked about the
activities and the states in which you know things needed to
change into. And then of course, class
diagrams is the information and the functions in which those
entities needed to perform. If you think about that UML,
which is that pact for how to create systems and you And
there's the logic and science behind that.
If we then apply the logic and science of process modeling down
to requirements, let the requirements literally drop out
of the process, as in there is a one to one relationship.
If you know how to do that properly, then we start to have
a very easy way of knowing where requirements come from and that
that technique is process to requirements thinking.
In summary, with the evolution of user story mapping, knowing
that you know you don't just do random requirements in an agile
environment, or the other extreme back in traditional land
having solution and stakeholder requirements being separate,
which also didn't work, there was something missing.
If we think about modern requirements elicitation and
management, we use user story mapping to make sure that the
development team is delivering you know enough of the solution
such that the job can be done. So they've at least got 1 user
story and e.g. epic along their iteration.
We also then take that further and say we can go back and
instead of having a solution and stakeholder requirements, we can
just have epic and user stories. As long as we have very.
We use the process modeling technique to drop our
requirements out and such that in the process we are talking
about the user, we are talking about the personas, we are
talking about the various personas, same as stakeholder
groups. We are talking about why they
want to achieve that step. In the process we we have now
brought in their prioritization and we you know, as long as it's
adding to the sequence then we know that the requirements which
allow us to get from A to B in some form or at least logically
from A to B in the most logical way will be the priority.
Yes, of course that leaves you lots of freedom to prioritize
requirements which aren't necessarily must have
requirements and becomes should and could and using our Moscow
rating or then those requirements then are can be
prioritized and then falls on the product owner or the, you
know, BA working on the team. If you're not using an Azure
environment to prioritize what is next going to be the most
valuable to the end customer and you know that when you release
it and then you release your first iteration and then then
let them to go, OK, Rob, what's important now, you can now do
the job to be done. Which area now is the pain point
for you, The most important area for you.
So you use. So once you've got that you know
first release if you like, you're now using pain points.
From that point you're revising your pain points in the process
steps. You look at the process step you
had before, you're looking at the process step you're now
doing now and you're now re examining what is now the pain
point now that you have these new tools and techniques from
get or a new solution if you like, from getting A to B.
What is now the most pressing pain point And again that's done
in process modeling and again that drives which user story in
the backlog should be added to the next Sprint.
And that my friends, is process to requirements.
Thinking in a nutshell. If you enjoy that thought, if
you want to challenge me on any of that then please do and I
hope you enjoyed the podcast this week.