The. Better Business analysis Institute. Presence the Better Business Analysis podcast with Benjamin. Walsh. Welcome back everyone. I'm your host, Benjamin Walsh. And today? We will continue on our BA byte series. And we'll jump right into 10 essential techniques. For technical business analysts. Now. I've already made. Comments around? Technical business analysis. And I believe it fits. In more the. System or solution? Analysis side so.
This is still a. Bit of a Gray area and a lot of BAS plan the space. Or have to. And this is actually. Where I first started doing BA, however. It isn't. Business analysis we're. Talking about here. It's more around the. Solution. OK, so. Just want to clarify that before we dive in, however, it's always good to know. And by having. Some technical skills. You understand how? The solution may be put in. Place and it helps. So some of these. Things like I said. Are in the.
Twilight Zone between what may be an. Architect A junior. Architect would do or a solution. Designer would do. But let's jump straight in. Number one. Is understanding the system requirements, not business requirements. So first and foremost is essential to kind of understand what those. System requirements are. Before delving into. Business rules. Or pseudo code. You need to really familiarize. Yourself. With the technical needs of your project. For example, if you're upgrading an E.
Commerce platform. You need. To make sure that it can handle. Thousands of concurrent users so. How do we? Do that from a traditional. BA point of view and. Then from a. Technical business analysis point of view or a systems analyst point of view? So #1 for that is around the fact. That there will should be a non. Functional requirement around that. OK, so that's the BA. Side. The traditional BA, the business side. And the. TBA side technical business analyst.
Side or systems analysis? Side and maybe I'll just use. The terms BA and. Essay So essay when I'm talking. About technical analysis. Their job would be OK. Well, what does that? Mean for the solution. How are we going to make that? What is the analysis I need to? Do to make sure that can be met so. For example, if you're. Using say WooCommerce or Shopify there will be stats on that. So this is. The the the. System. Requirement here is then what? Can the system? Meet that. OK.
So if you're buying a product. You need to do some analysis on that and if you're building a product. You need to. Make that clear. To the build. Team that, that's. Really important of all the. Requirements. That's really important. So that's number. One understanding the. System or solution? Requirements there. OK. So it's really taking the business requirement and then. Looking at the next step down. Detailed analysis. In the technical sense, to the hell. #2.
And again this. Is on the border. It's defining the. Business rules. Clearly, so the business rules capital B is this this? Word is used all over the play, all over the show to mean things. That are baked into the system to what someone wants business. Rules the B. Again, aligns with. Business analysis It. Is the BAS job to define. The business rules. However, they translate sometimes to validation and system rules. In the system. So. When the BA has defined the
rules. In business terms? The technical BA or SBA should be looking. At the rules as. Things like validation, so. We need a rule and the. Solution to make sure that. When someone enters. Their e-mail address it's a valid. E-mail so it has the at. Symbol. You can actually use pinging. There's ways of checking whether. Or not the e-mail is valid. Before you allow someone to sign up. And so that. Sys that that. Business rule around valid e-mail addresses. The business requirements.
The system. Rule is around. Validating that and specifying that it needs to have an AT symbol and you know you. Need to confirm e-mail links. So those that's around. How you're going to do it now, the BA may not know. Technically how that works? So the essay or the technical. Designer. Will need to specify that in a bit more detail by writing that up. OK. So that's number two. That's the. Business rules, clearly. And then mapping. Those down to system rules. #3 is.
If there is, it's around. Using decision tables for complex business rules. So our third. Technique is around using. Decision tables for. Complex business rules. So these. Around different scenarios, OK. So say if I say I want. There's a business requirement or. About applying a. Discount. For a loyalty program. On purchase amounts. The systems analysis. Side would actually specify maybe what the table looks like in terms of translating. You know if I said if you're tier?
1 you get 20%. Tier 2. You get 7. .5 and then you get 5% for example. For tier 3. It might be specifying what that looks like in a table. For example, literally. Not just specifying it in written. Terms. And by showing that you know. If someone spent this, you go to. The you. You. Get this so it's. Outlining that and. And and lots. Of details. And even to a point of even writing. Some pseudo code. So we'll get to that point. Soon, so decision tables are important.
And it's explaining. It's by. Having that document and by providing. That to the technical team. #4 is around flow diagrams. And flow charts. So you do this in business analysis? But this might actually. Be the system logic OK. So you're doing things like doing just using a. Visual aid. To understand the. System. Logic and the interaction. She might use it for. User registration. Process maybe? We've made it, really. Clear that we want. The user to be out of. Register, for example.
That's the business requirement, the system. Requirement might talk about that whole e-mail registration and that what happens when they sign up. This is really low. Level kind of kind of stuff here, almost procedure level, but. Stating it for the. System Designer. So it's around saying. Like you know that they have to enter a valid e-mail. If they don't, then this is what happens and. Drawing that up. Like technically what's happening is.
The system returning something. Is the backing returning something? Does the backing need to? Send the notification out the e-mail notification, Do we? Need to. Have some kind of mail server that allows us to do. That and. And when they click on the link, is it going to another secure location? What web page does it? Return to. So you're really. Getting into the design side here. OK, so that's. What we mean by that? So it's not process design, it's more the flows.
Of how the system's going to work sequence. Diagrams are used in. UML as well for this. Number. Five, which we talked about earlier. Is about writing pseudocode. So what does that mean? This bridges the gap. Between business. Logic and actual. Code so you keep. Instructions straightforward it. Doesn't have to be correct. But. Say for the login. Process you might write down. If username and password incorrect allow access else show error. You're literally.
Writing really low level pseudo, what we call pseudo go fake like code if you like and then whatever language. The developer is. Writing and they can write that same Python or whatever the technique. They're using so that is that's. What we call. Pseudocode, it's something. That a system designer would do or a systems analyst would do. Number six is around the. Fact that. Once we've defined. Our business. Rules and then the system rules. It's making sure that we. Actually validate those.
With stakeholders. OK, so if you're. If there are two roles, a business. Analyst and a systems analyst once the systems. Analyst has created how? The business rule will be implemented. And the. Technical feasibility. Of that might be. Quite different to what the. Business asks for the business need. So you need to review the resetting of password. Technique with maybe IT and customer. Service around security and user experience, and you might go back to stakeholders and explain
to them how it's. Going to be implemented. So it's validating the actual. Business rules implementation with stakeholders #6. It's really important. I've had that recently. Where the business? Thought one thing. And then the system was. Implementing it another. Way OK and. They didn't think about the. Stakeholders that would. All be affected by the. Design of the solution. #7 is about maintaining a glossary of terms. So we can't sometimes do this in pure business analysis.
But if you've introduced new. Terms as part of the design. Then you. Need to define maybe what user means and. Admin Admin. 'S a common one. What does admin mean? System admin. Does that mean full rights? Maybe session timeout? What does that mean? So that's again if you ever introduced new terminology. In the solution. Design you. Need to help clarify. What that means? And that's something that the business.
Probably needs to. Understand because when you deliver the solution, you go. Log them as admin. What does that mean in terms? Of the rights of the solution. So it's #7. #8 is around implementing error handling. This is something that gets lost between business requirements. And the developer because developers. That's why we have. Testers that are. Always thinking about what's important. In terms of error handling and. Also, what the? User wants to see. If they do do error.
Handling and maybe. For their own. Purposes and logging. But it may not be in. Terms of showing the error message to the user. For example, so with. Implementing error handling. You can do that through pseudocode and. Business rules. And you might say if payment. Fails show an error to the. User log default. In the logging. Technique. There's all. Things. That the BA may not have. Thought of but from a system design. Point of view. You can think about how error handling.
Might be best handled. Does it need to? Create an alert. In your. Service management system to follow up things like that. #9. Is again your job when you're doing the system. Design. Is to document the. Assumptions and constraints. You're making. So if you've got an. Assumption and constraint you. Should be talking to the. BA and the business, right? But ideally the BA if you've got one. But. There are. Cases where? If you're. Depending on the context. It helps.
Everyone if you document the limitations of the project. And the solution? So you might write down an. Assumption, say. All users have a. Valid e-mail. Address the system. Can process payments in. 5 seconds, so this isn't the requirement. Side. This could be. What? The system requires OK. So it's almost. Say for example, I've written a. Business requirement that says. That the response time of the website. Needs to be within 2 seconds, right?
That's what I want. That's pretty standardized. Now the. System constraint. Because we're building it on a complicated content management. System that's doing lots of things. It may actually take up. To three seconds. So we just say the. Constraint is that the the content management system that we've decided? To implement as. Part of the solution will actually load in three. Seconds, so that's. The job, That's the reply. #10. Is making sure that you.
Continuously review and improve. OK, So what does that mean? Technical analysis is an. Ongoing process. OK, after you deploy the. Solution. You need to gather. Feedback. You need to analyze the data regularly, and you need to. Be you might need to. Optimize the system. And the business? Processing might change as a. Result of whatever solution you put in place. It's about. You know, it's a, it is a bit of a Yang and a Yang here. So for example. If you're running. Stats.
Around. How many people have like not checked out so it's called cart abandonment on your. Website right? You might. Tell people. That so then the business knows. So this is around technical business analysis, systems analysis, solution design. There are 10. Essential things you need to know when. You delve into that and if you've been. Forced to do that and you're. Come from the business side. You need. To learn about this this. Isn't just. A hack job It needs to be.
Done properly and. Yes, it comes more from the. Solution World. And it's not what I would. Say is business. Business Analysis. But we've all had to do. This in some. Shape or form, So I hope you learned something. Today and I'll. See you next week.