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.