If you are reading a business analyst job description right now and trying to work out whether it matches what you can actually do, or what you need to develop, this article is for you. I have spent 25 years working as a BA across government, utilities, health, education, and enterprise, and the gap between what job postings say and what the role genuinely demands is wider than most people expect. What follows is an honest breakdown of the responsibilities, skills, and tools that define the business analyst job description in practice, not on paper.
What the Role Actually Involves
The BA sits between business stakeholders and delivery teams. That sounds straightforward until you are in a room where those two groups have fundamentally different ideas about what the project is supposed to achieve. Your job is not to relay messages between them. It is to uncover what is actually needed, challenge assumptions, document a clear picture of the problem and the proposed solution, and hold that picture steady when things get contested. The core roles and responsibilities of a business analyst span elicitation, documentation, analysis, and stakeholder engagement, often running in parallel rather than in sequence.
Core Responsibilities in Real Practice
Requirements Elicitation
Elicitation is the work of drawing out what stakeholders need, which is not the same as asking them what they want. I use interviews, workshops, observation, document review, and structured questioning techniques depending on what the project calls for. The range of elicitation techniques available is broad, and choosing the right one for the context is itself a skill. Getting requirements wrong at this stage costs everyone dearly later.
Data Analysis and Process Mapping
BAs examine data to identify patterns, gaps, and inefficiencies. This does not always mean running SQL queries, though familiarity with data tools helps considerably. It also means mapping current and future-state processes, creating flowcharts and swim-lane diagrams that make invisible workflows visible. Process mapping is one of the clearest ways to surface the problems no one has articulated yet.
Documentation
The BA is responsible for producing documentation that delivery teams can actually build from. That means business requirements documents, functional specifications, user stories, use cases, and acceptance criteria, depending on the methodology in use. In waterfall environments this documentation is formal and front-loaded. In agile environments it is iterative and maintained in the backlog. Either way, vague documentation produces vague solutions.
Stakeholder Communication and Facilitation
Most of what goes wrong on projects goes wrong because of communication failures. The BA is the person who prevents those failures by keeping stakeholders informed, managing expectations, running structured workshops, and translating between technical and non-technical language. This is not a soft skill in the dismissive sense. It is a precision discipline.
Testing and Validation
Before a solution goes live, the BA is typically involved in user acceptance testing (UAT). This means writing test cases, coordinating testers, capturing defects, and confirming that the delivered solution actually meets the requirements that were documented. I have been on projects where UAT revealed that the development team had built exactly what was written down, but what was written down turned out to be wrong. The validation stage is where that kind of disconnect surfaces.
A Worked Example: When Stakeholders Disagree on the Problem
On Project X, a mid-sized public sector organisation, I was brought in to support the replacement of a legacy case management system. The initial business analyst job description for the engagement talked about requirements gathering and process documentation. Straightforward enough, or so it seemed.
Within two weeks I had three different senior stakeholders giving me three incompatible accounts of what the system needed to do. The operations lead wanted the new system to mirror the old one as closely as possible to minimise retraining. The IT director wanted a clean break from the legacy architecture. The programme sponsor wanted functionality that had never existed in the old system and had not been budgeted for.
The friction point came when I produced a requirements summary that reflected all three positions honestly, rather than blending them into something that looked coherent but was not. The sponsor pushed back immediately, arguing that I was creating conflict rather than resolving it. I held the position. Blending contradictory requirements into a single document would have deferred the conflict until build or test, at which point the cost of resolving it would have been far higher. We ran a structured prioritisation workshop, brought all three stakeholders into the same room, and worked through the requirements against budget and timeline constraints. Three decisions that had been avoided for months got made in a single afternoon. The project delivered on time because we surfaced the friction early rather than papering over it.
Skills That Actually Matter
- Analytical thinking: You need to break complex problems into components, identify root causes rather than symptoms, and assess options against constraints before recommending a solution.
- Communication across audiences: The ability to explain a technical constraint to an operations manager, and a business priority to a developer, without losing accuracy in either direction, is non-negotiable.
- Structured documentation: Writing requirements that are unambiguous, testable, and complete is a craft. It takes practice and it is worth developing deliberately.
- Facilitation: Running a workshop where five stakeholders with competing priorities reach a workable conclusion requires skill in structuring the conversation, not just chairing it. The BA facilitation skills guide covers this in depth.
- Adaptability: Scope changes, priorities shift, and team dynamics evolve. The BA who gets thrown by change creates instability. The one who absorbs and reorients keeps the project moving.
- Technical literacy: You do not need to write code, but you need enough technical fluency to know when a proposed solution is feasible and when a developer is telling you something important.
Tools Commonly Used in the Role
| Tool | Primary Use | When You Will Use It |
|---|---|---|
| Microsoft Excel / Google Sheets | Data analysis, requirements tracking | Almost every project |
| JIRA / Azure DevOps | Backlog management, user stories, tracking | Agile and hybrid projects |
| Confluence / SharePoint | Documentation, collaboration, knowledge management | Most enterprise environments |
| Visio / Lucidchart / Miro | Process maps, flowcharts, workshop facilitation | Process analysis and design phases |
| SQL | Data querying, validation, root cause investigation | Data-heavy or system integration projects |
| Tableau / Power BI | Data visualisation, insight communication | Analytics and reporting projects |
| SurveyMonkey / Microsoft Forms | Stakeholder surveys, requirements gathering at scale | Large stakeholder groups or remote elicitation |
What a BA Job Description Does Not Tell You
Job postings tend to list responsibilities in isolation, as though requirements gathering happens, then analysis happens, then documentation happens, in a neat sequence. In practice these activities overlap, restart, and sometimes contradict each other. A requirement you thought was agreed gets reopened three weeks into build because a stakeholder who was absent from the workshop surfaces a conflict. A process map you completed gets invalidated when you discover the team has been running a workaround for two years that nobody mentioned. The role demands the ability to hold ambiguity, maintain structure, and keep the project moving even when the ground is shifting. If you want to understand where this role sits relative to adjacent roles, the comparison between a business analyst and a product owner is worth reading before you decide which direction suits you.
If you are early in your career and assessing whether this role fits, look at how comfortable you are with unresolved complexity. The BA who is most effective is not the one who eliminates ambiguity fastest. It is the one who knows how to work productively within it, document it honestly, and create conditions where the right people can resolve it. That combination of analytical rigour, communication skill, and tolerance for friction is what the business analyst job description is really asking for, even when it does not say so directly.
Frequently asked questions
What is a business analyst job description?
A business analyst job description typically covers requirements elicitation, process analysis, stakeholder communication, documentation, and involvement in testing. The specifics vary by industry and methodology, but those core activities appear across almost every BA role. In practice the work involves more negotiation and ambiguity management than most job postings suggest.
What skills do you need to be a business analyst?
The most important skills are analytical thinking, structured written communication, stakeholder facilitation, and the ability to translate between business and technical language. Technical literacy in tools like Excel, SQL, and JIRA is increasingly expected. Adaptability matters more than any single technical skill because project conditions change constantly.
What does a business analyst do day to day?
Day to day work includes running elicitation sessions with stakeholders, writing and refining requirements documentation, reviewing process maps, attending sprint ceremonies or project meetings, and resolving conflicts between competing stakeholder needs. No two projects are identical, and the balance between analysis, documentation, and communication shifts depending on the project phase.
Is business analysis a good career for someone early in their career?
Yes, because the role builds a genuinely transferable skill set across analysis, communication, and structured problem solving that applies in almost every industry. Early career BAs typically develop faster when they are placed on projects with real friction rather than smooth-running ones, because that is where the learning happens. The career path is also flexible, with routes into product ownership, business architecture, project management, and consulting.
What is the difference between a business analyst and a systems analyst?
A business analyst focuses on the business problem, the stakeholder needs, and the requirements for a solution, while a systems analyst focuses more specifically on how a technical system should behave to meet those requirements. In many organisations the roles overlap or are combined into a single position. The distinction matters more in large enterprise or government environments where specialisation is more defined.
Try Ash, Your Virtual BA
If you are working through what the BA role actually requires, or trying to build confidence in the skills listed in a job description you are targeting, Ash can help you close the gap. Ash is built specifically for business analysis work and covers everything from requirements elicitation techniques to glossary terms, documentation approaches, and career development questions. Ask it the things you would ask a senior BA on day one of a new project. Try Ash Virtual BA and get answers grounded in real practice.
Further reading
- What is a Business Analyst? | IIBA
- Business Analysis Blog | 3 Reasons Why Companies are Hiring Business Analysts | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.