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.