1 00:00:00,400 --> 00:00:04,400 The Better Business Analysis Institute presence, the Better 2 00:00:04,400 --> 00:00:14,440 Business Analysis Podcast with Hi everybody and welcome back to 3 00:00:14,440 --> 00:00:17,440 the Better Business Analysis podcast with Benjamin Walsh. 4 00:00:17,920 --> 00:00:21,880 And this week we are going to be talking about detailed level 5 00:00:22,000 --> 00:00:25,560 requirements analysis, sometimes just called detailed 6 00:00:25,560 --> 00:00:29,500 requirements. This is a very important phase 7 00:00:29,700 --> 00:00:32,460 throughout the Better Business analysis delivery journey. 8 00:00:33,500 --> 00:00:36,900 That's an era that's I think a little bit misunderstood 9 00:00:36,900 --> 00:00:39,300 especially with the development of Agile. 10 00:00:42,180 --> 00:00:46,940 There is a I guess a good way or a way that I talk about detailed 11 00:00:46,940 --> 00:00:51,500 level requirements analysis is that it is where the detailed 12 00:00:51,500 --> 00:00:55,150 functional non functional requirements of the solution I 13 00:00:55,150 --> 00:00:58,590 talked about I explained in a lot of detail and it follows on 14 00:00:58,590 --> 00:01:00,430 from the high level requirements base. 15 00:01:01,230 --> 00:01:04,069 And then generally you could think about that in terms of 16 00:01:04,190 --> 00:01:09,190 epics and then being broken down into user stories. 17 00:01:10,510 --> 00:01:15,310 And it's an interesting factor because it's it should be the 18 00:01:15,310 --> 00:01:18,950 transition here. This should be done with the 19 00:01:19,470 --> 00:01:25,680 solution provider. The development team should be 20 00:01:25,680 --> 00:01:29,760 part of this June. So for me, a great transition 21 00:01:29,760 --> 00:01:33,400 between a highly functional upfront project team and the 22 00:01:33,400 --> 00:01:37,640 development team or the delivery team is at this point. 23 00:01:37,920 --> 00:01:42,680 So before you start the detailed requirements analysis space, and 24 00:01:42,680 --> 00:01:45,200 that is so you've done your high level requirements, you've 25 00:01:45,200 --> 00:01:49,410 really worked out what scope is. You've got your chunky epics and 26 00:01:49,410 --> 00:01:51,170 you may have a first kind of user stories. 27 00:01:51,170 --> 00:01:54,290 And so this is all you know done on journey maps and you've got 28 00:01:54,290 --> 00:02:00,010 your kind of story story mapping down to what you think is the 29 00:02:00,050 --> 00:02:04,770 general idea about what net is required in order to deliver the 30 00:02:04,770 --> 00:02:06,970 solution. And this is where you engage 31 00:02:06,970 --> 00:02:10,050 with the vendor who you're working with, the vendors that 32 00:02:10,050 --> 00:02:12,330 there's multiple and the development team. 33 00:02:12,330 --> 00:02:16,220 So we're just going to call those people the development 34 00:02:16,220 --> 00:02:19,580 team or the delivery team as opposed to you know, talking 35 00:02:19,580 --> 00:02:23,020 about all the different use cases or different types of 36 00:02:23,340 --> 00:02:28,380 delivery that we might have. I will say that if you're going 37 00:02:28,420 --> 00:02:36,260 out to RFP, then some kind of tendering, then if you are not 38 00:02:36,260 --> 00:02:39,260 just getting information. So RFI, which stands for Request 39 00:02:39,260 --> 00:02:45,100 for Information, if you're asking for a proposal, it it is 40 00:02:45,640 --> 00:02:49,720 your responsibility as BA to do some level of detailed analysis. 41 00:02:50,760 --> 00:02:54,560 High level requirements aren't genuinely enough to go out to 42 00:02:54,560 --> 00:02:57,800 RFP because there are, and we'll talk about it in a minute. 43 00:02:58,400 --> 00:03:01,920 Some of those functions and some of those business rules are only 44 00:03:01,920 --> 00:03:05,480 captured once you start your detailed requirements phase. 45 00:03:05,720 --> 00:03:08,960 Now that doesn't mean you need to spend six months in a room by 46 00:03:08,960 --> 00:03:11,720 yourself writing these requirements. 47 00:03:11,960 --> 00:03:16,050 This is very much just a layer down. 48 00:03:16,050 --> 00:03:18,570 If you think about it in terms of processes, you are getting 49 00:03:18,570 --> 00:03:22,330 down to that kind of process of the three and you are talking 50 00:03:22,330 --> 00:03:25,250 about specific functions you want your user or your customer 51 00:03:25,250 --> 00:03:29,410 to experience. Now they need to be flexible. 52 00:03:29,490 --> 00:03:34,450 Obviously how a customer is able to carry out those functions 53 00:03:34,970 --> 00:03:40,450 could be quite different if the response was from what we call a 54 00:03:40,450 --> 00:03:45,190 cost system, off the shelf software where you have this 55 00:03:45,190 --> 00:03:49,510 commercial off the shelf software is what COT stands for 56 00:03:51,030 --> 00:03:54,510 or a SAS solution which is effectively a cost system in the 57 00:03:54,510 --> 00:03:57,710 cloud. Now they might come back and 58 00:03:57,710 --> 00:04:02,230 say, well if you want to do it exactly the way that you've 59 00:04:02,230 --> 00:04:05,270 specified in your detailed level of requirements, then that could 60 00:04:05,270 --> 00:04:07,910 be a change. And so there is a negotiation 61 00:04:07,910 --> 00:04:10,630 here. It is still agile in terms of 62 00:04:10,630 --> 00:04:14,310 working out you know how many points, you know more dollars 63 00:04:14,750 --> 00:04:17,110 and how much effort it's going to take to meet the requirement 64 00:04:17,390 --> 00:04:18,870 and then when you see the solution. 65 00:04:18,870 --> 00:04:21,870 So it's a two way conversation and they say, well you know 66 00:04:21,870 --> 00:04:27,550 you've said here you want users to be able to add information on 67 00:04:27,750 --> 00:04:32,430 a customer contact screen and they say, well now it's an 68 00:04:32,430 --> 00:04:35,750 application we have that you know spread across two screens 69 00:04:35,790 --> 00:04:40,190 and you could say well okay, the Y here for that requirement is 70 00:04:40,190 --> 00:04:42,930 around being able to capture customer details. 71 00:04:43,090 --> 00:04:46,650 And actually the fact that your solution does it over 2 screens, 72 00:04:46,650 --> 00:04:49,010 we don't require you to customize that solution to have 73 00:04:49,010 --> 00:04:51,250 it on one. We were just giving you an idea 74 00:04:51,250 --> 00:04:54,730 about what that requirement was in terms of capturing 75 00:04:54,730 --> 00:04:56,410 information. And so these are the kind of 76 00:04:56,410 --> 00:04:58,370 conversations you have with vendors as you go through the 77 00:04:58,370 --> 00:05:01,610 RFP process. And an RFP process, if you've 78 00:05:01,610 --> 00:05:06,410 not been involved in tendering, I suggest that you do learn 79 00:05:06,490 --> 00:05:10,910 about these different types of tenders is very robust. 80 00:05:10,910 --> 00:05:15,350 And if you've been involved in an RFP process, either replying 81 00:05:15,350 --> 00:05:19,830 to or issuing an RFP process, it is, you know, it is not a small 82 00:05:19,830 --> 00:05:22,950 task. And there is a whole lot of 83 00:05:23,230 --> 00:05:28,790 probity involved in that process where you have like a committee 84 00:05:28,790 --> 00:05:31,750 of people who are voting on responses and you have a way in 85 00:05:31,750 --> 00:05:34,890 which you great responses. And it all has to be fair and 86 00:05:34,890 --> 00:05:38,010 you can't have any conflicts of interest here and you really 87 00:05:38,010 --> 00:05:40,290 can't in some cases, I've been involved in one where we 88 00:05:40,290 --> 00:05:44,890 couldn't have open dialogue with other members who were reviewing 89 00:05:45,010 --> 00:05:49,130 responses. And so throughout that you might 90 00:05:49,130 --> 00:05:53,290 have a stage where you're getting vendors presenting back 91 00:05:53,290 --> 00:05:58,410 to you who you know your, your shortlist might present back to 92 00:05:58,410 --> 00:06:00,450 you as part of that process and you can have these 93 00:06:00,450 --> 00:06:02,990 conversations. And then you generally at the 94 00:06:02,990 --> 00:06:05,350 end of the process you engage with one and then you can, you 95 00:06:05,350 --> 00:06:09,550 know then you go into what I would consider a delivery phase, 96 00:06:10,550 --> 00:06:13,630 what we call delivery and requirements management phase 97 00:06:13,950 --> 00:06:17,870 here at a Better Business analysis institute, right. 98 00:06:17,870 --> 00:06:24,830 So excluding this RFP, you know vendor selection process, let's 99 00:06:24,830 --> 00:06:26,990 keep it really simple and pretend that we've got a 100 00:06:27,270 --> 00:06:32,310 delivery team, development team which is in our organization or 101 00:06:32,790 --> 00:06:38,390 you know our partner that we use and they run development really 102 00:06:38,390 --> 00:06:39,990 well. So they take their input as 103 00:06:39,990 --> 00:06:43,990 being high level requirements first cut user stories backlog 104 00:06:43,990 --> 00:06:48,430 effectively we as a BA work there. 105 00:06:48,830 --> 00:06:54,430 We're on behalf of the the, we are the customer if you like. 106 00:06:54,830 --> 00:06:58,830 We've got a product owner who owns the outcome of this phase 107 00:06:59,310 --> 00:07:03,370 for those products. And we we're facilitating in 108 00:07:03,370 --> 00:07:07,850 terms of maybe we're helping the product owner elaborate on 109 00:07:07,850 --> 00:07:12,370 requirements, maybe we're doing some of the lower level business 110 00:07:12,370 --> 00:07:18,450 rule definitions and logic. And we have been the BA who has 111 00:07:18,650 --> 00:07:21,090 worked out that there is a business need for this. 112 00:07:21,130 --> 00:07:24,570 Let's just say it's a new product, OK. 113 00:07:24,570 --> 00:07:27,730 And in the simple term we'll talk about a web application. 114 00:07:27,730 --> 00:07:32,000 So we'll just talk about a very simple, maybe a mobile app and 115 00:07:32,000 --> 00:07:34,240 we have a product owner who's come from the business, who's 116 00:07:34,240 --> 00:07:40,200 going to own this product, which we are going to call diagnosis 117 00:07:40,200 --> 00:07:45,080 card, diagnosis mobile app, which will diagnose faults for 118 00:07:45,080 --> 00:07:47,200 your car. And not only will it do that 119 00:07:47,200 --> 00:07:53,120 through a device that you plug into your car, it will tell you 120 00:07:53,120 --> 00:07:57,360 what's wrong with your car and recommend solutions and provide 121 00:07:57,360 --> 00:08:00,640 you with options in terms of what your, what garage you could 122 00:08:00,640 --> 00:08:02,480 take it to and how much this might cost. 123 00:08:02,600 --> 00:08:06,760 So effectively taking away the control of what's wrong with 124 00:08:06,760 --> 00:08:09,240 your car to yourself as an individual and then you get 125 00:08:09,240 --> 00:08:12,680 choices around how you can get your car fixed. 126 00:08:12,920 --> 00:08:17,550 So this is a, you know, a business that could exist and we 127 00:08:17,550 --> 00:08:19,710 have a product owner who's gonna, who's gonna own this, 128 00:08:19,790 --> 00:08:24,750 this app which we'll call car diagnosis, just call it Car 129 00:08:24,750 --> 00:08:29,790 diagnosis, very simple, it's not a very sexy name and we are now 130 00:08:30,590 --> 00:08:33,750 they've been allocated and we've we've been involved with maybe a 131 00:08:33,750 --> 00:08:36,669 product manager and we've tested the market. 132 00:08:36,669 --> 00:08:38,710 We believe there is a market and now we're going. 133 00:08:39,390 --> 00:08:42,870 Now we have our high level requirements which have already 134 00:08:42,870 --> 00:08:44,910 been written. We've already had the business 135 00:08:44,910 --> 00:08:48,350 case put together. We're now moving to the detailed 136 00:08:49,070 --> 00:08:54,870 level requirements analysis. Now detailed level requirements 137 00:08:54,870 --> 00:08:57,870 analysis is the process of analyzing and specifying that 138 00:08:57,870 --> 00:09:00,630 detailed, like we said, detailed functional non functional 139 00:09:00,630 --> 00:09:03,470 requirements of the solution. It involves taking the high 140 00:09:03,470 --> 00:09:05,510 level requirements gathered during the requirements 141 00:09:05,510 --> 00:09:08,710 gathering phase and breaking them down into specifics and 142 00:09:08,710 --> 00:09:12,670 actionable requirements that can be used by the development team 143 00:09:12,670 --> 00:09:14,110 and designers to build the solution. 144 00:09:14,230 --> 00:09:17,850 OK, it involves effectively 6 steps. 145 00:09:18,290 --> 00:09:21,850 You want to refine the one so the BA works with stakeholders 146 00:09:21,850 --> 00:09:27,130 and the Product Owner to redefine and refine and get down 147 00:09:27,130 --> 00:09:30,170 to the lower level of the requirements to shoot, to ensure 148 00:09:30,170 --> 00:09:33,490 really that they are complete, they're correct and they're 149 00:09:33,490 --> 00:09:35,210 testable. So they really it. 150 00:09:35,330 --> 00:09:43,110 It does require going down to very much one step away for from 151 00:09:43,110 --> 00:09:45,270 the house steps. So we need to be able to specify 152 00:09:45,270 --> 00:09:47,830 the requirements such that the developer can read them and 153 00:09:47,830 --> 00:09:50,150 understand. And the response being, this is 154 00:09:50,150 --> 00:09:52,670 how I'm going to meet that requirement. 155 00:09:52,670 --> 00:09:58,950 I understand Okay cool, You want a landing page where users can 156 00:09:58,950 --> 00:10:02,790 read information around how the application works and they get 157 00:10:02,790 --> 00:10:06,790 to sign up on that page or download the app and they can 158 00:10:06,790 --> 00:10:10,990 then visualize how that might work or you know relate it to 159 00:10:10,990 --> 00:10:15,190 other work they've done before and they can start to size that 160 00:10:15,190 --> 00:10:18,190 work and they do that through story points most of the time. 161 00:10:18,790 --> 00:10:21,070 It's a sizing technique which allows them to kind of 162 00:10:21,870 --> 00:10:23,550 guesstimate how long things might take. 163 00:10:24,350 --> 00:10:28,030 And I would say that that delivery cycle, so the 164 00:10:29,590 --> 00:10:31,710 delivering requirements management phase we call it, 165 00:10:33,110 --> 00:10:37,030 which is really a crossover with a with a PO running that phase. 166 00:10:37,580 --> 00:10:41,580 That's where Scrum is a really good technique to use in the 167 00:10:41,580 --> 00:10:45,420 agile world in terms of having developers using story points 168 00:10:45,580 --> 00:10:50,020 and Kanban and sprints and breaking other work. 169 00:10:50,020 --> 00:10:52,940 So you have an idea about how long things are going to take 170 00:10:53,300 --> 00:10:56,020 and then you get one slice of the solution in the end in the 171 00:10:56,020 --> 00:10:59,940 first release and then you keep you know working on those 172 00:10:59,940 --> 00:11:03,460 features as they become a priority, ideally based on 173 00:11:03,460 --> 00:11:06,580 customer feedback. But to start off with, you do 174 00:11:06,580 --> 00:11:10,430 need when it comes to products and apps. 175 00:11:10,430 --> 00:11:14,910 You do need to be able to somehow demonstrate the end to 176 00:11:14,950 --> 00:11:17,750 end business flow for a user or customer. 177 00:11:17,750 --> 00:11:21,230 Journey flow if you like. And so that's generally what it 178 00:11:21,230 --> 00:11:25,110 focuses on your first Sprint, it refers 2 weeks. 179 00:11:26,710 --> 00:11:30,470 What the BA does is one you refine the requirements. 180 00:11:30,790 --> 00:11:34,790 And generally this is even if you have a very agile focused 181 00:11:34,910 --> 00:11:39,060 team with a product owner. The Bas usually find a 182 00:11:39,060 --> 00:11:42,060 subservient BA to a PO doing this work. 183 00:11:42,060 --> 00:11:46,100 They're very good at doing that. You need to decompose the 184 00:11:46,100 --> 00:11:48,460 requirements so the high level requirements are broken down 185 00:11:48,460 --> 00:11:51,860 into more details. So not only do the effort 186 00:11:52,540 --> 00:11:54,580 requirements, which are your high level requirements get 187 00:11:54,580 --> 00:11:57,860 broken down into user stories. User stories can be broken down 188 00:11:57,860 --> 00:12:01,340 into further user stories based on the feedback you get from the 189 00:12:01,340 --> 00:12:04,000 development team. So if the user store is too high 190 00:12:04,000 --> 00:12:07,000 level and it can't be completed in one Sprint then it needs to 191 00:12:07,000 --> 00:12:09,480 be broken down into smaller work items if you like. 192 00:12:11,200 --> 00:12:15,360 Also, what I would find is a good idea is that we start to 193 00:12:15,360 --> 00:12:17,520 talk about acceptance criteria and I'll get to that in a 194 00:12:17,520 --> 00:12:20,800 minute. We need to identify what we call 195 00:12:20,800 --> 00:12:23,560 the use cases. So this is a word that used to 196 00:12:23,560 --> 00:12:28,480 be associated with UML. Well, it still is and waterfall, 197 00:12:29,110 --> 00:12:32,470 but it's still applicable no matter what environment you're 198 00:12:32,470 --> 00:12:34,430 working in. Maybe you're working in an agile 199 00:12:34,430 --> 00:12:37,430 environment or a waterfall environment or a mix. 200 00:12:37,430 --> 00:12:40,870 Because to be honest, no one works really in a pure waterfall 201 00:12:40,950 --> 00:12:43,590 environment anymore. You still need to know how to 202 00:12:43,590 --> 00:12:47,310 write use cases and scenarios. So use cases and scenarios are 203 00:12:47,950 --> 00:12:51,750 identify how the system will be used and it's used to validate 204 00:12:51,750 --> 00:12:53,750 the requirements. So it's like, right, we've got 205 00:12:53,750 --> 00:12:57,270 this function, how's a user going to actually use it 206 00:12:57,270 --> 00:13:00,080 logically? And so your job as a BA is to 207 00:13:00,080 --> 00:13:02,400 explain logically how that's going to work. 208 00:13:02,840 --> 00:13:05,840 Not necessarily and even conceptually, but it's not your 209 00:13:05,840 --> 00:13:10,280 job to specify the solution. It's your job to say like a 210 00:13:10,280 --> 00:13:15,680 comic book strip and say okay. Well, a user will view this 211 00:13:15,680 --> 00:13:19,840 landing page and they'll be able to navigate down to a sign up 212 00:13:19,960 --> 00:13:21,960 button. And you didn't describe like a 213 00:13:21,960 --> 00:13:24,400 story, which is where the word use case came from. 214 00:13:24,400 --> 00:13:27,720 So these scenarios comic books are a really good way of 215 00:13:27,720 --> 00:13:31,480 describing it, good technique for doing this as opposed to 216 00:13:31,480 --> 00:13:33,720 stick figures and boxes, which you can do, which are 217 00:13:34,720 --> 00:13:39,320 traditional use case diagrams. This is for you to see if 218 00:13:39,320 --> 00:13:41,480 there's any holes in the requirement flow. 219 00:13:41,480 --> 00:13:45,200 This is your job to make sure that, OK, well, I guess if we're 220 00:13:45,200 --> 00:13:49,760 doing diagnosis, we need some business rules around connecting 221 00:13:49,760 --> 00:13:53,040 to the device that connects into the car. 222 00:13:53,280 --> 00:13:58,560 How long do we wait until the connection fails and we time out 223 00:13:58,560 --> 00:14:01,120 and say we can't find it? Because if we keep connecting 224 00:14:01,120 --> 00:14:04,960 through Wi-Fi, we're going to drain both the mobile app and 225 00:14:05,080 --> 00:14:08,320 the car itself. And so these, these pieces of 226 00:14:08,320 --> 00:14:10,920 logic are the Ba's responsibility. 227 00:14:10,960 --> 00:14:13,400 And they do. I do find that when you work 228 00:14:13,400 --> 00:14:17,780 with some pure Agile Ba's, they forget that that's their job and 229 00:14:17,780 --> 00:14:22,820 these business rules aren't generally well talked about in 230 00:14:22,820 --> 00:14:27,460 the agile world. But when we talk about use cases 231 00:14:27,460 --> 00:14:31,460 and scenarios, these business rules aren't, you know, they 232 00:14:31,460 --> 00:14:36,500 don't necessarily fit into a user story format. 233 00:14:36,580 --> 00:14:39,700 So you generally find that they live in Excel or they're 234 00:14:39,900 --> 00:14:44,140 referenced out. They can be specified as 235 00:14:44,140 --> 00:14:46,540 acceptance criteria, which we'll talk about in a minute. 236 00:14:47,600 --> 00:14:51,160 Okay, so you've helped refined the requirements probably with 237 00:14:51,160 --> 00:14:55,920 the PO you've decomposed the requirements based on feedback 238 00:14:55,920 --> 00:14:58,360 from the development team that they need to be broken down 239 00:14:58,360 --> 00:15:01,720 further in the two chunky. You've kind of identified these 240 00:15:01,720 --> 00:15:05,040 use cases and scenarios. So it's almost like how will 241 00:15:05,040 --> 00:15:09,650 these functions be used? Not not in a conceptual way, not 242 00:15:09,650 --> 00:15:13,130 necessarily the end design or solution that's going to be 243 00:15:13,130 --> 00:15:14,730 there. And you can talk about it with 244 00:15:14,730 --> 00:15:17,130 the development team and the designers that can give you 245 00:15:17,130 --> 00:15:19,610 feedback. And then you need to analyze and 246 00:15:19,610 --> 00:15:21,210 specify the functional requirements. 247 00:15:21,650 --> 00:15:26,050 So the functional requirements are the detail around the 248 00:15:26,050 --> 00:15:28,690 inputs, outputs, processes and user interfaces. 249 00:15:29,010 --> 00:15:31,250 So you need to think about it from all those point of views. 250 00:15:31,290 --> 00:15:37,150 The function could be with the system itself, so in this case 251 00:15:37,150 --> 00:15:41,150 the mobile app or the device we plugged into the car, so the 252 00:15:41,150 --> 00:15:44,590 users interface with those. So we need to, I don't know, 253 00:15:45,230 --> 00:15:47,790 plug the device into the car. We need to be able to download 254 00:15:47,790 --> 00:15:51,430 the app, we need to log in all those kind of interfaces. 255 00:15:51,430 --> 00:15:54,870 If you like web page interfaces, then we need to think about the 256 00:15:54,870 --> 00:15:57,030 processes that need to happen so they're not. 257 00:15:57,830 --> 00:16:00,390 Like I said, the connection process to the device from our 258 00:16:00,390 --> 00:16:03,950 mobile phone might connect to this device via Wi-Fi or 259 00:16:03,950 --> 00:16:06,010 Bluetooth. And so that connection is 260 00:16:06,010 --> 00:16:10,570 between two devices, it's not between us as a human or the 261 00:16:10,570 --> 00:16:15,850 user, it's between two devices. And so those we call both the 262 00:16:15,850 --> 00:16:20,650 systems and the humans, actors, regardless of the human 263 00:16:20,650 --> 00:16:26,850 characters in this game. And so to outline how the mobile 264 00:16:26,850 --> 00:16:31,340 app will be talking to the device we plug into the car, we 265 00:16:31,340 --> 00:16:34,140 still need to talk about that process regardless of the fact 266 00:16:34,140 --> 00:16:37,500 that there's a user interface or not and somebody else get a 267 00:16:37,500 --> 00:16:40,940 little bit caught up and don't actually just thinking about the 268 00:16:40,980 --> 00:16:42,180 user interface. Here. 269 00:16:42,180 --> 00:16:46,940 The user experience behind the scenes, your job is to outline 270 00:16:47,180 --> 00:16:49,580 through sequence diagrams maybe is a really good way of doing 271 00:16:49,580 --> 00:16:53,020 it, or through these use case diagrams to show that the 272 00:16:53,340 --> 00:16:57,020 systems need to talk to one another and how they might do 273 00:16:57,020 --> 00:16:59,780 that in theoretical terms. And then work with the 274 00:16:59,780 --> 00:17:02,020 development team on how that might actually happen. 275 00:17:02,380 --> 00:17:06,099 Now you might hear with APIs and things like that. 276 00:17:06,780 --> 00:17:10,220 And then as part of the functional requirements we also 277 00:17:10,220 --> 00:17:13,500 need to talk about the inputs and outputs to the process, 278 00:17:14,619 --> 00:17:18,780 which are generally things that aren't necessarily to do with 279 00:17:18,859 --> 00:17:21,859 the application, but things that need to be true. 280 00:17:22,140 --> 00:17:26,470 So for example, the final step on our card diagnosis that was 281 00:17:26,470 --> 00:17:30,750 to e-mail out the results to our e-mail address. 282 00:17:31,630 --> 00:17:35,910 Thinking about that output and defining how that might work is 283 00:17:35,910 --> 00:17:37,630 definitely part of the functional requirements. 284 00:17:38,070 --> 00:17:40,430 So anything that's functional in the greatest sense of the word, 285 00:17:40,430 --> 00:17:44,150 not just the user functional and functions of the system is 286 00:17:44,150 --> 00:17:48,150 functional requirements. Then we get down to non 287 00:17:48,150 --> 00:17:50,990 functional requirements. Now non functional requirements 288 00:17:50,990 --> 00:17:54,990 include things like performance and security and usability 289 00:17:54,990 --> 00:17:59,590 actually at a high level, and there's actually a defined list. 290 00:18:00,310 --> 00:18:03,150 Sometimes an architect can help very much with these things. 291 00:18:03,710 --> 00:18:07,590 Usually people that are more attuned with how systems work 292 00:18:07,590 --> 00:18:11,710 and their capabilities can help define what is the modern 293 00:18:11,710 --> 00:18:16,710 standards for non functionals. These are incredibly important 294 00:18:16,790 --> 00:18:20,270 and are done notoriously badly by BAS by the way. 295 00:18:20,830 --> 00:18:23,390 So there is almost a checklist and you can go to New Zealand, 296 00:18:23,390 --> 00:18:26,630 you can go to DIA, They actually have a cloud assessment 297 00:18:26,870 --> 00:18:30,940 spreadsheet you can use, and it has a whole lot of nonfunctional 298 00:18:30,940 --> 00:18:32,060 requirements you need to think about. 299 00:18:32,580 --> 00:18:35,260 One simple example, if you don't know what a nonfunctional 300 00:18:35,260 --> 00:18:39,020 requirement is, it might be the capacity that a website can 301 00:18:39,140 --> 00:18:41,580 handle. So for example, there was a 302 00:18:41,580 --> 00:18:45,140 common situation in New Zealand where there was they were 303 00:18:45,140 --> 00:18:48,700 opening up the tickets to be able to come into New Zealand 304 00:18:48,700 --> 00:18:51,340 through this kind of. During COVID they had a certain 305 00:18:51,340 --> 00:18:57,660 amount of places for MIQ and the nonfunctional requirements for 306 00:18:57,660 --> 00:19:01,880 how they would handle web traffic to the website wasn't 307 00:19:01,880 --> 00:19:03,720 really thought about. So they had the functions 308 00:19:03,720 --> 00:19:06,600 working really well. So the function that was working 309 00:19:06,880 --> 00:19:09,520 but when a non functional requirement isn't met, and 310 00:19:09,520 --> 00:19:12,600 sometimes that can affect users. And in this case they just had 311 00:19:12,600 --> 00:19:15,600 too much traffic and they hadn't talked about capacity to manage 312 00:19:15,600 --> 00:19:17,680 that. And of course the website 313 00:19:17,680 --> 00:19:20,960 crashed and they had to come over come up with to change the 314 00:19:20,960 --> 00:19:23,160 way the functions work in order to deal with that. 315 00:19:23,750 --> 00:19:25,790 So non functional requirements are extremely important. 316 00:19:26,270 --> 00:19:29,710 It is generally falls to the VA to do them or at least 317 00:19:29,910 --> 00:19:32,910 coordinate getting them done. But like I said there's pretty 318 00:19:32,910 --> 00:19:35,750 standard list these days and if you're working with a vendor 319 00:19:36,510 --> 00:19:38,870 especially in the security space, there are some you know 320 00:19:38,870 --> 00:19:40,790 minimum standards legislation that you have to make. 321 00:19:41,990 --> 00:19:44,550 Finally the last step. So we've refine the 322 00:19:44,550 --> 00:19:47,470 requirements, we've decomposed them, we've identified those 323 00:19:47,830 --> 00:19:51,030 kind of scenarios and use cases and I would say business rules 324 00:19:51,030 --> 00:19:52,110 there. We'll come back to what that 325 00:19:52,110 --> 00:19:55,380 means in a minute. You've specified your functional 326 00:19:55,380 --> 00:19:57,500 and you've specified your non functional requirements. 327 00:19:57,860 --> 00:20:00,580 We then need to validate the requirements so the requirements 328 00:20:00,580 --> 00:20:03,620 are validated with stakeholders. The product owner I would say is 329 00:20:03,620 --> 00:20:06,300 a really good person who owns the requirements, makes the 330 00:20:06,300 --> 00:20:09,620 decisions around whether or not they should be in and out and we 331 00:20:09,620 --> 00:20:12,460 need to ensure that these requirements. 332 00:20:12,910 --> 00:20:16,630 Will meet the needs or the objectives of the project and 333 00:20:16,630 --> 00:20:18,150 that they're feasible to implement. 334 00:20:18,150 --> 00:20:21,350 There can't be things that aren't feasible and and just not 335 00:20:21,350 --> 00:20:24,710 possible. If not, not sorry. 336 00:20:24,910 --> 00:20:27,990 They could be very difficult things that our development 337 00:20:27,990 --> 00:20:29,550 teams say they need more resources. 338 00:20:29,870 --> 00:20:34,550 Resources for which is fine, but then sometimes people just come 339 00:20:34,550 --> 00:20:37,430 up with ideas that just aren't feasible to implement. 340 00:20:38,510 --> 00:20:42,820 So the reason why that's important, and I've used kind of 341 00:20:43,180 --> 00:20:47,660 more older terminology here, very irba terminology, is that 342 00:20:47,660 --> 00:20:52,580 regardless of if you're working in an agile environment or a 343 00:20:52,580 --> 00:20:56,020 waterfall environment or a mix between them, these are the 344 00:20:56,020 --> 00:20:58,620 steps you have to carry out. Now you might not, you might 345 00:20:58,620 --> 00:21:01,100 call your requirements, your final requirements, user 346 00:21:01,100 --> 00:21:04,700 stories, and I think you should. But just be aware that you need 347 00:21:04,700 --> 00:21:08,300 both functional and non functional user stories and you 348 00:21:08,300 --> 00:21:11,900 might well have. You need a way of capturing both 349 00:21:12,340 --> 00:21:15,180 how you're going to test these and this is where acceptance 350 00:21:15,180 --> 00:21:18,900 criteria comes in. And you need to capture business 351 00:21:18,900 --> 00:21:22,900 rules, so logic that needs to exist in order to meet that user 352 00:21:22,900 --> 00:21:25,020 story and that is your job. And it's actually some of the 353 00:21:26,220 --> 00:21:29,820 hardest parts of being a business analyst is working out 354 00:21:29,820 --> 00:21:32,300 the business rules that are required in order to make a 355 00:21:32,300 --> 00:21:34,420 system operate on the legislation. 356 00:21:35,060 --> 00:21:38,220 So we'll start with the acceptance criteria. 357 00:21:39,220 --> 00:21:41,140 When you write a user story, you'll see that you've got a 358 00:21:41,140 --> 00:21:45,060 name of it and you use it right. You know as a I want to so that 359 00:21:45,060 --> 00:21:47,820 I can. And then you've got a 360 00:21:47,820 --> 00:21:50,860 description field. And the description field can be 361 00:21:50,860 --> 00:21:55,140 used in multiple ways. For me personally, I don't 362 00:21:55,260 --> 00:21:57,220 follow the book. Here I write, I use the 363 00:21:57,220 --> 00:21:59,660 description field to write a story. 364 00:21:59,820 --> 00:22:03,220 So use a story in the true sense of the word, which explains the 365 00:22:03,220 --> 00:22:09,400 use cases and scenarios in which I want to be implemented. 366 00:22:09,400 --> 00:22:16,320 So I tell a story and about how the user interfaces with the 367 00:22:17,280 --> 00:22:20,360 application, and it's a system. I talk about how the system will 368 00:22:20,400 --> 00:22:22,840 interface with other systems and so forth. 369 00:22:23,120 --> 00:22:26,360 And I tell it in a comic book style, and I elaborate and allow 370 00:22:26,360 --> 00:22:29,320 the developer to read that and then that gives them a better 371 00:22:29,320 --> 00:22:33,720 sense of what's going on. Now that is one way to do it. 372 00:22:34,000 --> 00:22:38,210 A lot of Bas, and actually I've seen this done extremely well by 373 00:22:38,810 --> 00:22:43,570 BA Hype working for me a few years ago, is the description 374 00:22:43,570 --> 00:22:45,730 field is used as the acceptance criteria. 375 00:22:45,890 --> 00:22:48,970 So the acceptance criteria, if you like, are what led on to 376 00:22:48,970 --> 00:22:53,050 test cases. So you state what has to be true 377 00:22:53,050 --> 00:22:54,610 in order for this requirement to be met. 378 00:22:55,370 --> 00:22:58,130 So if we're talking about a landing page for example, you 379 00:22:58,130 --> 00:23:01,740 could say the user can see the landing page. 380 00:23:01,740 --> 00:23:05,580 These are yes, no statements that can be that need to be true 381 00:23:05,900 --> 00:23:08,540 and the ways in which the development team can check off 382 00:23:08,540 --> 00:23:12,340 their work. So I do both, I do a description 383 00:23:12,380 --> 00:23:15,100 and then acceptance criteria actually break down as almost 384 00:23:15,100 --> 00:23:18,260 tasks or subtasks of the requirement now. 385 00:23:18,300 --> 00:23:24,460 So so you can do both and I and I suggest that you at least do 386 00:23:24,460 --> 00:23:28,220 acceptance criteria and if you do 1 technique, one good way of 387 00:23:28,220 --> 00:23:32,810 doing that is to use these kind of subtasks on say a JIRA 388 00:23:32,810 --> 00:23:35,570 ticket. And so you state all the things 389 00:23:35,570 --> 00:23:38,370 that have to be true, so it's all the logical items that have 390 00:23:38,370 --> 00:23:40,450 to be true. And then when a developer has 391 00:23:40,450 --> 00:23:43,730 developed that they can check that all those things there are 392 00:23:44,050 --> 00:23:48,810 true and therefore the user story is complete and they have 393 00:23:48,810 --> 00:23:50,970 to complete all that for the user story to move across. 394 00:23:50,970 --> 00:23:55,530 So they can't partially do the work if they get to a point when 395 00:23:55,530 --> 00:23:57,290 they're thinking about what has to be true. 396 00:23:57,290 --> 00:24:00,530 And the reason why it's good for Bas to specify or have a go at 397 00:24:00,530 --> 00:24:03,810 like sentence criteria first is that that might give them an 398 00:24:03,810 --> 00:24:06,770 idea that the user story in itself is too big to be 399 00:24:06,770 --> 00:24:10,130 completed once Sprint. And therefore it suggests that 400 00:24:10,130 --> 00:24:15,090 that user story should be broken down into many so, so and 401 00:24:15,890 --> 00:24:18,610 sometimes when we write these user stories, they can be too 402 00:24:18,610 --> 00:24:22,720 fluffy and then the acceptance criteria will bring you down to 403 00:24:22,720 --> 00:24:26,080 earth and make them smart. And so if we were to about this 404 00:24:26,080 --> 00:24:30,080 landing page which has, I don't know a log in sign up button and 405 00:24:30,080 --> 00:24:34,080 that's effectively, you know, screen and that's it, it would 406 00:24:34,080 --> 00:24:36,440 be quite it. We would say the user can 407 00:24:36,440 --> 00:24:40,680 successfully navigate to the landing page, the user can see 408 00:24:40,680 --> 00:24:45,200 the blah blah blah. The user can click on the sign 409 00:24:45,200 --> 00:24:53,030 in screen, the user can click on the sign up screen, the sign on 410 00:24:53,110 --> 00:24:56,870 form appears successfully, the user can enter the blah blah 411 00:24:56,870 --> 00:24:58,630 blah. So you you know you're writing 412 00:24:58,630 --> 00:25:02,670 down effectively very high level test cases that in the test it 413 00:25:02,670 --> 00:25:04,230 will take. And then they'll break that down 414 00:25:04,230 --> 00:25:09,470 into things like you know that this field has to be password 415 00:25:09,470 --> 00:25:13,430 protected or that this has to be 100, can only be 100 characters 416 00:25:13,430 --> 00:25:15,710 long. And you as a VA, you know could 417 00:25:15,710 --> 00:25:19,490 feed into that as doing their, as they're doing their test 418 00:25:19,490 --> 00:25:21,970 cases. So this is kind of detailed 419 00:25:21,970 --> 00:25:23,610 requirements. That is detailed requirements. 420 00:25:24,090 --> 00:25:27,770 And when we talk about like the size of fields and things like 421 00:25:27,770 --> 00:25:30,090 that, we start dipping into what I call business roles. 422 00:25:30,450 --> 00:25:35,890 Now you can imagine how big your user story would be if you 423 00:25:35,890 --> 00:25:38,210 started putting all these bits and pieces together and this 424 00:25:38,210 --> 00:25:41,250 should be a conversation. So you might add notes as you go 425 00:25:41,250 --> 00:25:43,170 through. But if you did this up front, 426 00:25:43,170 --> 00:25:44,610 you'd never get to a development team. 427 00:25:44,650 --> 00:25:48,100 So you do this as you're working through the development team and 428 00:25:48,100 --> 00:25:50,540 sometimes I actually literally have an excel spreadsheet or 429 00:25:50,540 --> 00:25:52,980 something like that, or a Confluence page if I'm working 430 00:25:52,980 --> 00:25:57,940 in JIRA when I might specify business rules. 431 00:25:59,020 --> 00:26:01,260 What would be a good example of the business rule? 432 00:26:02,180 --> 00:26:05,860 Say for example we were logging in as we've just talked about 433 00:26:06,980 --> 00:26:11,900 there might be some checks around the fact that we know, we 434 00:26:11,900 --> 00:26:13,900 know there's a non functional requirement, a security 435 00:26:13,900 --> 00:26:17,570 requirement around multi factor authentication. 436 00:26:17,570 --> 00:26:21,210 So two of that and that you know that's if you don't know what 437 00:26:21,210 --> 00:26:25,330 that is, that is where you're verifying you are who you are 438 00:26:25,730 --> 00:26:30,370 using two devices. So your e-mail for example, 439 00:26:30,370 --> 00:26:33,490 which might be your computer and then on your computer your main 440 00:26:33,490 --> 00:26:37,330 device and then your mobile phone as the other device. 441 00:26:37,410 --> 00:26:40,900 And so these days it's pretty common when you sign up 442 00:26:40,900 --> 00:26:44,100 somewhere it will send you a code on your mobile device which 443 00:26:44,100 --> 00:26:47,060 is another device. It verifies who you are because 444 00:26:47,060 --> 00:26:50,180 you need to have both devices in order to be able to verify who 445 00:26:50,180 --> 00:26:52,700 you are and you get a code and you enter that in as well. 446 00:26:52,980 --> 00:26:56,980 And so that two FA process, there are rules for that like it 447 00:26:57,140 --> 00:27:00,530 runs in a certain way. And so by putting in you know 448 00:27:00,610 --> 00:27:04,130 how you want that two FA experience to run. 449 00:27:04,370 --> 00:27:05,690 You can have different user stories. 450 00:27:05,690 --> 00:27:08,090 You would definitely have a user story around user needs. 451 00:27:08,570 --> 00:27:11,930 The system needs to be able to kind of forward, you know 2FA 452 00:27:11,930 --> 00:27:14,770 and you write a user story specific around how what their 453 00:27:14,770 --> 00:27:17,090 experience is. And you say the user does this 454 00:27:17,130 --> 00:27:19,130 and they enter this and they're making a text and they do a 455 00:27:19,130 --> 00:27:21,850 thing. Now, if there's any logic behind 456 00:27:21,850 --> 00:27:26,370 how that might work, it may be best that you just, you know, 457 00:27:26,370 --> 00:27:30,040 point out to a bit of a another diagram or a confluence page or 458 00:27:30,040 --> 00:27:32,760 an Excel spreadsheet which just shows all the business rules 459 00:27:32,760 --> 00:27:35,960 that make that run. That's one example and it's 460 00:27:35,960 --> 00:27:38,360 simplest terms. But when you think about things 461 00:27:38,360 --> 00:27:42,400 like banking and you think about some really complicated 462 00:27:42,400 --> 00:27:44,440 processes, there are a lot of business rules. 463 00:27:44,480 --> 00:27:47,680 If this then that. Think about if statements and 464 00:27:48,240 --> 00:27:50,680 all the things that need to be true and it will just it 465 00:27:50,680 --> 00:27:54,930 wouldn't really make sense to have that detail will just 466 00:27:54,970 --> 00:27:57,410 clogged up and use the story for the developer to see. 467 00:27:57,810 --> 00:27:59,690 So they know they need to meet their requirement and they might 468 00:27:59,690 --> 00:28:04,730 go off to the specific business page to read the logic behind 469 00:28:05,170 --> 00:28:06,690 that. And that is where you find 470 00:28:06,690 --> 00:28:08,810 relative Bas will play as in that space. 471 00:28:08,850 --> 00:28:11,770 And it does cross over to architecture a little bit with 472 00:28:11,770 --> 00:28:15,300 systems analysis in terms of how the system might actually make 473 00:28:15,300 --> 00:28:17,900 this work. Usually find that those people 474 00:28:17,900 --> 00:28:20,460 who play in that space, the Bas who play in that space don't 475 00:28:20,460 --> 00:28:23,460 actually write the code, they just simply are outlining the 476 00:28:23,460 --> 00:28:25,260 pseudo code about how something can work. 477 00:28:25,260 --> 00:28:27,860 And there's, you know, there's definitely demand for that. 478 00:28:27,860 --> 00:28:30,340 And I would say that a lot of Bas might find that they're in 479 00:28:30,340 --> 00:28:34,380 that position, especially if they're in complicated business 480 00:28:34,380 --> 00:28:37,260 role, kind of legislation, heavy environments. 481 00:28:39,100 --> 00:28:42,900 So we come back to the whole point of the detailed level 482 00:28:42,900 --> 00:28:48,150 requirements analysis phase. We are we are defining the next 483 00:28:48,150 --> 00:28:55,070 level of requirement detail and we need to make it work with the 484 00:28:55,070 --> 00:28:58,230 development team to make it really, really clear about, you 485 00:28:58,230 --> 00:29:02,430 know, what needs to happen. And as I said up front, this 486 00:29:02,430 --> 00:29:05,990 could be done before engaging with the development team, 487 00:29:05,990 --> 00:29:09,700 depending on what type of delivery team you've got, or 488 00:29:09,700 --> 00:29:11,860 otherwise it would be done in parallel with that. 489 00:29:11,860 --> 00:29:15,140 So you might be fleshing out requirements. 490 00:29:15,140 --> 00:29:20,260 You may be doing the detailed requirements analysis midway 491 00:29:20,260 --> 00:29:22,180 through the development so it happens in parallel. 492 00:29:22,260 --> 00:29:25,620 So in a true agile environment, you only elaborate the storage 493 00:29:25,620 --> 00:29:27,020 you're working on for that Sprint. 494 00:29:27,460 --> 00:29:31,220 So you as a BA may be going, OK, we're working on the next kind 495 00:29:31,220 --> 00:29:33,820 of user story or the next item in the backlog. 496 00:29:34,020 --> 00:29:37,220 We need more detail. And then a true BA would work on 497 00:29:37,220 --> 00:29:43,740 term that would work elaborating that particular user story at 498 00:29:43,740 --> 00:29:45,220 point in time only when they need to. 499 00:29:45,700 --> 00:29:48,340 So you're not wasting your time doing detailed analysis across 500 00:29:48,340 --> 00:29:50,740 the application. And that's true, true agile. 501 00:29:51,700 --> 00:29:56,590 If we talk about a real example where we talk about our our car 502 00:29:56,590 --> 00:30:03,670 diagnosis tool, then we need to diagnose how that works into 503 00:30:04,510 --> 00:30:08,710 those kind of epic level, high level requirements which before 504 00:30:08,710 --> 00:30:11,230 we start in terms of how they work, which could just be a 505 00:30:11,230 --> 00:30:13,990 mobile app, could be a device plug into the car, it could be a 506 00:30:13,990 --> 00:30:16,630 website. And then as we're breaking down 507 00:30:16,630 --> 00:30:19,550 how that mobile app works, which could be screens and then 508 00:30:19,550 --> 00:30:24,600 business rules below that, it needs to be written in such a 509 00:30:24,600 --> 00:30:26,720 way in which a user can really understand do it. 510 00:30:26,720 --> 00:30:30,480 In the simplest terms, I say that if you're if it's 511 00:30:30,480 --> 00:30:32,960 completely, if it's complex or you're trying to explain it to 512 00:30:32,960 --> 00:30:36,360 users like a product owner, then drawing a comic strip is a 513 00:30:36,360 --> 00:30:38,880 really good way of doing it. It sounds really silly, but 514 00:30:39,120 --> 00:30:42,320 visualizing those steps makes sense. 515 00:30:42,720 --> 00:30:45,600 Definitely a process diagram. And the reason we use processes 516 00:30:46,160 --> 00:30:50,360 is that processes, if you like, requirements can drop out of 517 00:30:50,360 --> 00:30:53,590 processes. So if you, if you really think 518 00:30:53,590 --> 00:30:56,990 about the steps in which that story, in which the user is 519 00:30:56,990 --> 00:31:01,710 going through to log into this mobile, this car diagnosis app, 520 00:31:01,910 --> 00:31:05,670 creating an account, you know, finding the device that's 521 00:31:05,670 --> 00:31:08,230 connected to their car, starting to read that diagnosis 522 00:31:08,230 --> 00:31:12,030 information, maybe making some changes, maybe you know, sending 523 00:31:12,030 --> 00:31:15,750 that information back to their account on the website, seeing 524 00:31:15,750 --> 00:31:18,310 the list of mechanics and the costs associated with their 525 00:31:18,310 --> 00:31:21,950 faults and moving forward. All of that are steps in a 526 00:31:21,950 --> 00:31:25,190 process. And when you talk about the 527 00:31:25,630 --> 00:31:28,070 different levels of processes, the highest level is car 528 00:31:28,070 --> 00:31:30,870 diagnosis kind of is the number one. 529 00:31:31,390 --> 00:31:36,190 Number two is the steps like around acquiring a mobile app 530 00:31:36,430 --> 00:31:39,470 and plugging it in and then receiving diagnosis information 531 00:31:39,470 --> 00:31:43,380 and contacting mechanics. And then at Level 3, just before 532 00:31:43,380 --> 00:31:46,740 the procedure level, you're breaking down those steps of how 533 00:31:46,740 --> 00:31:50,580 they're interfacing with the the theoretical system which might 534 00:31:50,580 --> 00:31:55,180 be, you know, viewing, navigating to the login page, 535 00:31:55,580 --> 00:31:57,460 logging in with your account details. 536 00:31:57,780 --> 00:32:02,100 And then below that is the procedure level which is now now 537 00:32:02,100 --> 00:32:05,060 which is only should only be written once you've actually got 538 00:32:05,060 --> 00:32:09,380 the solution because procedures involve how so down at process 539 00:32:09,380 --> 00:32:14,060 level 4 which is procedure level within outline how that might 540 00:32:14,060 --> 00:32:19,220 happen and a BA can effectively that is what exactly the same as 541 00:32:19,220 --> 00:32:21,580 writing these detailed work ones. 542 00:32:21,980 --> 00:32:25,940 So you're thinking about how this might function in theory 543 00:32:26,100 --> 00:32:29,420 like a procedure level, think about like a Word document and 544 00:32:29,420 --> 00:32:31,620 then the development team you're working with and they're saying, 545 00:32:31,620 --> 00:32:33,620 well you know how you thought about the fact that you know 546 00:32:33,620 --> 00:32:35,780 they could do this. And the designers like well 547 00:32:36,290 --> 00:32:39,210 instead of having a web page, if we thought about this and all of 548 00:32:39,210 --> 00:32:43,370 that works together to help elaborate the kind of procedure, 549 00:32:43,370 --> 00:32:46,610 if you like the detailed level requirement that needs to exist 550 00:32:47,010 --> 00:32:50,610 in order for the story or this end to end process work. 551 00:32:51,250 --> 00:32:55,290 So I hope I have explained what detailed requirements analysis 552 00:32:55,290 --> 00:32:57,010 is all about. It is. 553 00:32:57,290 --> 00:33:00,410 It does either happen in parallel or lead into what we 554 00:33:00,410 --> 00:33:02,170 call delivery and requirements management. 555 00:33:02,850 --> 00:33:06,670 And delivery and requirements management is like I said, it 556 00:33:06,790 --> 00:33:10,310 could be when you're working through that process where 557 00:33:11,310 --> 00:33:13,470 you're selecting a solution. So you've done detailed 558 00:33:13,470 --> 00:33:15,910 requirements, you've issued it out through tender and you're 559 00:33:15,910 --> 00:33:19,190 now working with a vendor to select which solution is best 560 00:33:19,190 --> 00:33:22,390 and you're evaluating it. Or it could be you supporting 561 00:33:22,390 --> 00:33:26,590 the delivery team and requirements management 562 00:33:26,590 --> 00:33:31,310 lifecycle, so that next step. So there is a transition here. 563 00:33:31,310 --> 00:33:33,990 There's a certain amount of work that needs to happen, buy a BA 564 00:33:33,990 --> 00:33:37,590 if you like or buy someone who's really focused on the detail and 565 00:33:37,590 --> 00:33:40,350 then there's the actual doing. So there's the, the second part 566 00:33:40,350 --> 00:33:43,550 of it is the development team now owning the process and 567 00:33:43,550 --> 00:33:45,390 managing requirements. They kind of own the 568 00:33:45,390 --> 00:33:47,710 requirements at this point. The delivery team including the 569 00:33:48,150 --> 00:33:51,110 Product owner and they're kind of asking for more detail or 570 00:33:51,110 --> 00:33:53,870 they're kind of sending off requests and now they kind of 571 00:33:53,910 --> 00:33:57,200 own the requirements. And your job as a BA is you know 572 00:33:57,200 --> 00:34:00,120 he's transitioned off to this development team and there are 573 00:34:00,120 --> 00:34:02,200 Bas who will work in the development team. 574 00:34:02,680 --> 00:34:06,240 It's kind of pseudo writers of requirements for the PO because 575 00:34:06,240 --> 00:34:08,080 the PO doesn't have those skills. 576 00:34:08,440 --> 00:34:13,760 But the true BA work is actually done generally before that in 577 00:34:13,760 --> 00:34:17,000 the delivery and requires management phase that happens if 578 00:34:17,000 --> 00:34:20,639 you like after the detailed requirements phase or these two. 579 00:34:20,800 --> 00:34:23,239 As I've said, these two things could happen parallel of these 580 00:34:23,239 --> 00:34:25,480 detail that needs to happen along the way. 581 00:34:26,880 --> 00:34:32,000 This is where the PO and BA worlds can crossover. 582 00:34:32,040 --> 00:34:34,920 So either you need to decide here if you're working in this 583 00:34:34,920 --> 00:34:36,920 environment what roles you're playing. 584 00:34:37,880 --> 00:34:42,560 The most common is that the BA will become part of the 585 00:34:42,560 --> 00:34:45,600 development team and their job is simply just to elaborate and 586 00:34:45,600 --> 00:34:49,199 explain what was the point of the requirement and to elaborate 587 00:34:49,199 --> 00:34:53,760 on the requirements. The other role is when the 588 00:34:54,560 --> 00:34:58,760 Product owner is outsourcing some of their responsibilities 589 00:34:58,760 --> 00:35:02,840 to the the business headless. So that I kind of but more hands 590 00:35:02,840 --> 00:35:05,320 back they might not know about technology and then letting the 591 00:35:05,320 --> 00:35:08,280 BA run some of those discussions on their behalf and the BA is 592 00:35:08,280 --> 00:35:10,920 advising them. And then there are other 593 00:35:10,920 --> 00:35:12,920 examples where you just don't have a PO. 594 00:35:12,920 --> 00:35:16,760 So the BA is running this with the development team running the 595 00:35:16,760 --> 00:35:20,400 whole process of that just kind of make getting decisions from 596 00:35:20,400 --> 00:35:24,520 the from the product sponsor, the sponsor, the project and it 597 00:35:24,520 --> 00:35:28,440 is acting just as the PO would in the Scrum team. 598 00:35:29,760 --> 00:35:33,560 So there's some examples about what happens next in the process 599 00:35:34,800 --> 00:35:37,600 and that generally you know there are different models 600 00:35:37,600 --> 00:35:38,680 there. You usually find that some of 601 00:35:38,680 --> 00:35:42,120 the junior or intermediate Bas is a really good place for them 602 00:35:42,120 --> 00:35:44,920 to start and then that technology is in the space and 603 00:35:44,920 --> 00:35:48,920 usually find that senior Bas are not generally involved 604 00:35:49,160 --> 00:35:53,410 necessarily once the development cycle starts and once the 605 00:35:53,410 --> 00:35:56,170 detailed requirements are done. But there is a bridge, there is 606 00:35:56,170 --> 00:36:00,450 a, there is a huge market for these for these types of Bas 607 00:36:00,730 --> 00:36:03,490 that are really worrying about the logic and the and the 608 00:36:03,490 --> 00:36:06,690 function and the how and working with architects on complicated 609 00:36:06,690 --> 00:36:08,050 solutions. Actually I'm working on a 610 00:36:08,050 --> 00:36:12,050 project now which involves me wearing that hat around data and 611 00:36:12,050 --> 00:36:15,250 how that might work. And I'm also doing at the same 612 00:36:15,250 --> 00:36:18,130 time enterprise and strategic analysis and working out, you 613 00:36:18,130 --> 00:36:20,660 know, a data strategy. So you know usually find 614 00:36:20,660 --> 00:36:22,860 yourself in more place, especially if you're in a senior 615 00:36:22,900 --> 00:36:27,340 senior role and it's a great place for a junior BA or an 616 00:36:27,340 --> 00:36:33,540 intermediate BA to play cool. So that's my spiel today about 617 00:36:34,220 --> 00:36:38,020 detailed level requirements analysis, and I hope you've 618 00:36:38,020 --> 00:36:38,740 learned something today.