Today we’re going to answer a question that comes up quite often, and that’s what technical skills a business analyst needs to be well-positioned in the job market and to be able to have detailed discussions with technical professionals.
While it’s important that a business analyst has a conceptual technical understanding as it helps you analyze the problem to be solved and communicate with technical stakeholders, you don’t need to be able to write code or run database queries.
In this video, I share the technical skills you do need to know and how they will help you position yourself more strongly in the job market and hold up your side of the conversation with developers.
For those who like to read instead of watch, here’s the full text of the video:
Today we’re here to answer a question from Monica. She asked, “What are the top three to five technical skills a business analyst with a business background needs to have?” Specifically, she asked this around wanting to be able to make sure she could have good conversations with the technical people on her project teams.
Here’s the thing about technical skills in BA jobs – you’ve heard me say it before and you’re going to hear me say it again – you see them as job requirements a lot of times in business analyst roles. And a lot of times those requirements are extremely misleading.
You can, of course, to become more technically minded as a business analyst, learn how to write code. You could go take an introduction to programming and a sequel course and learn a bunch of technical skills that you may never, ever want to use in your career. You could do that. Or you could learn some requirements models that allow you to have those very productive communications and conversations with technical professionals and understand more about how the technology is structured and give you insight into what questions to ask than the technical skills, themselves, actually do.
What I’m going to talk about here, in terms of technical skills, are three requirements models or three types of requirements models that you might want to look at if you feel that you’re not “technical” enough to be a business analyst. I will finish with one closing bonus skill that might catch you by surprise.
Let’s talk about these three models.
Technical Skill 1: Use Cases for Functional Requirements
The first is use cases. Use cases are a textual description of how a business user or a user of a software application interacts with a software system. They force you to get really specific about what function or feature that system needs to have in order to meet the business needs. Underlying that feature is often a piece of code that a developer has created, customized, or integrated to make that function work.
But what you need to be able to specify as a business analyst is what that software needs to do, and the condition under which it needs to do it. A use case is the perfect model to get familiar with that business user system interaction. It’s much more detailed than a typical business process model, and it’s much more specific. You get into those specific technical requirements even though you don’t know how to write the code that underlies it.
Technical Skill 2: Wireframes for Visual Requirements
The second requirements model that can be helpful in expressing technical requirements like this is wireframes. Wireframes are visual descriptions, or visual renderings, of a user interface screen. Essentially, when I go to a software application as a user, what does it look like to me?
Not, specifically, what are the colors, what are the buttons, and how are they; circle or square? That is important at a certain point of a project, but a wireframe can be much less specific than that. It can use general buttons and not be specific on colors. Use grayscale. You’re trying to show this is what the user interface screen might look like to a potential user.
Again, you’re getting to that level of detail of what that software system needs to be able to do and look like, again, without having to write the code behind it. There are a lot of tools today that people, like me, who don’t have coding backgrounds, are able to use that just drag and drop those features into a wireframing tool so you can create them without having to know how to code.
Technical Skill 3: Data Models for Data Requirements
The third set of models are data models, such as entity relationship diagrams, system context diagrams, data flow diagrams, data dictionaries. There are a bunch of different models included in the data modeling area.
Essentially, all those models allow you to understand how the database is structured, how information is stored, what information needs to be stored. So, if you’re looking at a business process and there are different fields on a form coming in through some sort of an input:
- How is that information stored in your software system?
- What are the rules that need to be applied when that information is stored?
- How do the different pieces of information that come in through different business processes, how do those relate together?
Different data models allow you to look at that information model in different ways. This is how you, essentially, learn how to model a relational database or express data requirements without knowing SQL.
A not very well-kept secret is that I’ve never learned how to write SQL. I did learn how to do a little bit of coding in a very proprietary database language that was very specific at the very beginning of my career, but I’ve never learned SQL. I’ve never used that skill to move forward as a business analyst. I’ve done a lot of work with data requirements and data modeling and helped a lot of teams figure out what those data requirements and databases should look like by using some of the core data modeling skills.
And One Bonus Technical Skill…Asking Questions
I promised you one bonus. Our three models are use cases, wireframes, and data models. What’s that bonus skill? The bonus skill is something that you’re probably already good at if you’re a business analyst, and that’s the ability to ask questions.
When it comes to technical questions, it’s like the ability to ask that question that you really feel like you should know. You should know the answer to this and you don’t. It’s asking questions about how things are organized, what are the capabilities of the technology, what are things that you might not think of. You’re using that so you can understand the possibilities of the technology and how the system is designed without knowing how to do it yourself.
In my experience, you could spend a lot of time learning how to build these systems and write code. That could have a measurable impact on your career. Or, you could spend time learning these core skills that you’re going to use forever in your life-long career as a business analyst.
They’re going to give you a more advanced level of understanding of the potentials of technology than you would get from learning how to line-by-line create the code because they’re going to enable you to work in any sort of situation as opposed to just the coding language that maybe you learned. There are dozens of coding languages out there, dozens of different technical environments. So, you’re never going to become the expert on all of them unless you want to be the expert and the doer of that kind of thing. If you’re a business analyst, I’m assuming you probably don’t.
Again, use cases, wireframes, data models, and having the courage to ask questions and get the answers to those questions so that you really have a good technical understanding in your environment. Those, to me, are the skills that you need to succeed as a business analyst with a business background in today’s technical environment. They will take you far as a business analyst without getting you lost in the weeds of learning specific technical coding skills.
>>How to learn these key technical business analyst skills
When you join The Business Analyst Blueprint® training program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.
>> Click here for more information about The Blueprint <<
