This is Laura Brandenburg from Bridging The Gap.
Today we’re here to answer a question fromMonica.
She asked, “What are the top three to fivetechnical skills a business analyst with a business background needs to have?” Specifically, she asked this around wantingto be able to make sure she could have good conversations with the technical people onher project teams.
Here’s the thing about technical skills in BA jobs – you’veheard me say it before and you’re going to hear me say it again – you see them asjob requirements a lot of times in business analyst roles.
And a lot of times those requirements areextremely misleading.
You can, of course, to become more technicallyminded as a business analyst, learn how to write code.
You could go take an introduction to programmingand a sequel course and learn a bunch of technical skills that you may never, ever want to usein your career.
You could do that.
Or you could learn some requirements modelsthat allow you to have those very productive communications and conversations with technicalprofessionals and understand more about how the technology is structured and give youinsight into what questions to ask than the technical skills, themselves, actually do.
What I’m going to talk about here, in termsof technical skills, are three requirements models or three types of requirements modelsthat you might want to look at if you feel that you’re not “technical” enough tobe a business analyst.
I will finish with one closing bonus skillthat might catch you by surprise.
Let’s talk about these three models.
The first is use cases.
Use cases are a textual description of howa business user or a user of a software application interacts with a software system.
They force you to get really specific aboutwhat function or feature that system needs to have in order to meet the business needs.
Underlying that feature is often a piece ofcode that a developer has created, customized, or integrated to make that function work.
But what you need to be able to specify asa business analyst is what that software needs to do, and the condition under which it needsto do it.
A use case is the perfect model to get familiarwith that business user system interaction.
It’s much more detailed than a typical businessprocess model, and it’s much more specific.
You get into those specific technical requirementseven though you don’t know how to write the code that underlies it.
The second requirements model that can behelpful in expressing technical requirements like this is wireframes.
Wireframes are visual descriptions, or visualrenderings, of a user interface screen.
Essentially, when I go to a software applicationas a user, what does it look like to me? Not, specifically, what are the colors, whatare the buttons, and how are they; circle or square? That is important at a certain point of aproject, but a wireframe can be much less specific than that.
It can use general buttons and not be specificon colors.
You’re trying to show this is what the userinterface screen might look like to a potential user.
Again, you’re getting to that level of detailof what that software system needs to be able to do and look like, again, without havingto 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 thosefeatures into a wireframing tool so you can create them without having to know how tocode.
The third set of models are data models, suchas entity relationship diagrams, system context diagrams, data flow diagrams, data dictionaries.
There are a bunch of different models includedin the data modeling area.
Essentially, all those models allow you tounderstand how the database is structured, how information is stored, what informationneeds to be stored.
So, if you’re looking at a business processand 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 appliedwhen that information is stored? How do the different pieces of informationthat come in through different business processes, how do those relate together? Different data models allow you to look atthat information model in different ways.
This is how you, essentially, learn how tomodel a relational database or express data requirements without knowing SQL.
A not very well-kept secret is that I’venever learned how to write SQL.
I did learn how to do a little bit of codingin a very proprietary database language that was very specific at the very beginning ofmy career, but I’ve never learned SQL.
I’ve never used that skill to move forwardas a business analyst.
I’ve done a lot of work with data requirementsand data modeling and helped a lot of teams figure out what those data requirements anddatabases should look like by using some of the core data modeling skills.
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’reprobably already good at if you’re a business analyst, and that’s the ability to ask questions.
When it comes to technical questions, it’slike the ability to ask that question that you really feel like you should know.
You should know the answer to this and youdon’t.
It’s asking questions about how things areorganized, what are the capabilities of the technology, what are things that you mightnot think of.
You’re using that so you can understandthe possibilities of the technology and how the system is designed without knowing howto do it yourself.
In my experience, you could spend a lot oftime learning how to build these systems and write code.
That could have a measurable impact on yourcareer.
Or, you could spend time learning these coreskills that you’re going to use forever in your life-long career as a business analyst.
They’re going to give you a more advancedlevel of understanding of the potentials of technology than you would get from learninghow to line-by-line create the code because they’re going to enable you to work in anysort 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 experton 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 assumingyou probably don’t.
Again, use cases, wireframes, data models, and having the courage to ask questions and get the answers to those questions so thatyou really have a good technical understanding in your environment.
Those, to me, are the skills that you needto succeed as a business analyst with a business background in today’s technical environment.
They will take you far as a business analystwithout getting you lost in the weeds of learning specific technical coding skills.