Careers & Certification
Business analyst skills: 12 core skills and how to build them
The skills at a glance
Job adverts for business analysts often read like wish lists, so it is easy to feel you need fifty skills before you can start. In practice a smaller set carries most of the work. This guide groups twelve core skills into four families and explains for each what it is, why it matters and one way to practise.
| Family | Skills |
|---|---|
| Thinking | Analytical thinking, problem framing, prioritisation, a testing mindset |
| People | Listening and interviewing, facilitation, stakeholder management, communication |
| Making things clear | Requirements writing, process modelling, documentation |
| Technical literacy | Data and SQL, APIs and systems awareness |
You do not need to be excellent at all of them on day one. Most analysts are strongest in two or three families and deliberately build the others. The aim is to be solid across all four and good in at least one.
Thinking skills
1. Analytical thinking
What: breaking a messy situation into parts, looking for causes and checking claims against evidence. Why: stakeholders often describe symptoms or solutions; the analyst has to find the actual cause. Practise: next time you hear "customers are unhappy", ask what you could count, compare or observe to test it.
2. Problem framing
What: stating a problem clearly, with who is affected, evidence and impact, before choosing a solution. Why: a well-framed problem is half solved, and a badly framed one wastes the project. Practise: rewrite three requests you have received as problem statements without mentioning any tool or feature.
3. Prioritisation and decision support
What: helping people choose what to do first when everything seems urgent. Why: time and budget always run out. Practise: take a list of ten ideas and sort them with MoSCoW, writing a one-line reason for each placement. See also MoSCoW and SWOT.
4. A testing mindset
What: thinking about how something could fail, and how you would know. Why: requirements that cannot be tested are opinions. Practise: for any rule you read, write one passing example and two failing examples, including a boundary value.
People skills
5. Listening and interviewing
What: asking open questions, following up with "can you show me?", and summarising what you heard. Why: the quality of requirements depends on the quality of the conversations. Practise: interview a friend about how they plan their week and write down only what they actually do, not what they say they should do. The article on elicitation techniques has more ideas, and the interview technique entry gives the short version.
6. Facilitation
What: running a meeting or workshop so that the right people contribute and decisions are made. Why: analysts often convene the people who disagree. Practise: volunteer to run a short agenda-led meeting, send minutes the same day and note what you would change.
7. Stakeholder management
What: understanding who matters, what they want and how to keep them engaged. Why: a missed stakeholder can stall a release. Practise: list the people affected by a change at your workplace, rate their influence and interest, and decide how you would involve each. See stakeholder analysis and RACI.
8. Communication
What: explaining the same idea to a director, a developer and a user, each in suitable language. Why: misunderstandings between groups are the analyst's daily problem. Practise: explain one process in three sentences to someone outside your field and ask them to repeat it back.
Skills for making things clear
9. Requirements writing
What: turning needs into statements that are specific, consistent and testable, such as user stories with acceptance criteria. Why: this is the central deliverable of the role. Practise: take a vague line such as "the system should be fast" and rewrite it until a tester could say pass or fail. Our requirements practice example walks through this on fictional data, and how to write user stories covers the format.
10. Process modelling
What: drawing how work flows, using simple flowcharts or BPMN. Why: a picture reveals handoffs and delays that text hides. Practise: map a process you know, such as ordering lunch for the team, then look for the longest wait. See BPMN for beginners.
11. Documentation
What: keeping requirements, decisions and notes where the team can find them. Why: knowledge that lives in one head or one inbox disappears. Practise: write a one-page decision record for a choice you made recently: what, why, who, when and alternatives. Our guide on documentation for business analysts shows page structures.
Technical literacy
12. Data, SQL and systems awareness
What: reading tables, writing simple queries, understanding how systems exchange data through APIs, and knowing what a KPI or dashboard needs. Why: modern business questions are answered with data, and requirements often describe data and integrations. Practise: learn to read one small table, filter it, join it to another and count by group. Start with SQL for business analysts and try the SQL practice guide. Then read APIs for business analysts.
You do not need to be a developer. The goal is to understand enough to ask precise questions and to notice when an answer does not add up. If you are comparing roles, the article on business analyst versus data analyst explains how far the data side usually goes.
Alongside the twelve skills, domain knowledge multiplies your usefulness. Knowing how banks, insurers or clinics work lets you ask better questions sooner. See domain knowledge for business analysts.
The skills working together: a fictional example
Skills matter in combination, so here is a small story that shows several at once. At Tidewater Insurance, the claims manager says: "Customers keep phoning to ask where their claim is. We need a tracking page."
- Analytical thinking and problem framing. The analyst, Fatima, does not start with a page. She asks how many calls are about status and what other reasons people call. A two-week call log from the contact centre shows that status questions are common but not the only reason.
- Listening. She interviews two claims handlers and learns that status changes happen in three different systems, and handlers sometimes forget to update one of them.
- Process modelling. She maps the current flow and finds that the "assessor visit booked" step is only in an email, never in a system.
- Data. A short query shows that many claims have no recorded status change for ten days or more, so a tracking page built on the data would show stale information.
- Stakeholder management. She explains this to the claims manager using the map and the numbers, and they agree the first fix is to record the visit date, then show status.
- Requirements writing. She writes a story and acceptance criteria for recording the visit date, and a second story for the tracking page that depends on it.
- Prioritisation. Together they place the recording story first, since without it the page would mislead customers.
No single skill carried the outcome. The result was better than the request because several ordinary skills were used in sequence.
How to build the skills in a sensible order
If you are starting out, a sensible order keeps you motivated because early wins feed later ones.
- Weeks 1-2: vocabulary and the shape of the job. Read what business analysis is and browse the glossary.
- Weeks 3-5: problem framing, stakeholders and elicitation, practised on a real process.
- Weeks 6-8: requirements, stories and acceptance criteria. Write several and ask someone to find holes in them.
- Weeks 9-12: process models, then basic SQL and a simple dashboard concept.
- Ongoing: documentation habits, testing practice and domain reading.
These timings are an illustration, not a promise; people progress at different speeds. What matters is the cycle of learning, trying and getting feedback. For a fuller route, read how to become a business analyst with no experience. If you prefer a guided sequence through a simulated company project, the BA Lab is built around exactly these skills.
Finally, record your practice. A short folder of labelled examples, kept honestly as practice, becomes the core of a portfolio and a source of stories for interviews.
Frequently asked questions
What are the most important business analyst skills?
Analytical thinking, communication, requirements writing and stakeholder management usually matter most. Technical literacy such as SQL and understanding of data and APIs increasingly supports them.
Are soft skills or technical skills more important?
Both matter, and neither works alone. Interpersonal and writing skills decide whether needs are understood, while technical literacy lets you check data and talk precisely with developers.
Do business analysts need to know SQL?
Not always, but basic SQL is useful in many roles and a frequent request in job adverts. Being able to read and write simple queries helps you verify numbers yourself.
How can I show skills without job experience?
Practise on real or fictional problems, keep the outputs and describe them honestly as practice. A short portfolio with clear reasoning is more persuasive than a list of skills.
Which skill should I learn first?
Start with problem framing and listening, because they improve everything else. Then learn requirements writing, which is the central deliverable of the role.
This article is educational. All companies, people and numbers in the examples are fictional. BA Mentorship does not issue professional certifications and cannot guarantee any job or interview outcome.