What a Business Analyst Actually DoesLesson 1
What a BA Actually Produces
10 minutes
A Business Analyst sits between people who have a problem and people who can build a solution. The role is older than software engineering, but every modern BA spends most of their week translating business needs into something engineers can build, and then validating that what got built actually solves the original problem.
The job is not to type code. It is not to project-manage. It is to make sure the right thing gets built for the right reason.
The one-line definition
A Business Analyst surfaces what the business actually needs, documents it in a form a delivery team can act on and verifies that the delivered solution meets the original need.
What a BA hands over in a typical week
Across most SA workplaces, the artefacts a BA produces fall into five categories. You will rarely produce all five in a single week, but every BA on every project produces at least three of them regularly.
1
Requirements documents
A Business Requirements Document (BRD), Functional Requirements Specification (FRS) or backlog of user stories. The form depends on whether the team is running Waterfall, Agile or somewhere in between.
2
Process models
BPMN diagrams showing how a business process works today (as-is) and how it should work after the change (to-be). Done in Lucidchart, draw.io or Visio. Used in workshops to get stakeholders to agree on reality before agreeing on the change.
3
Stakeholder analysis
A documented map of everyone who has a stake in the project, what they care about and how to engage them. RACI matrices, power-interest grids and engagement plans.
4
Acceptance criteria
Given/When/Then statements that tell QA exactly what passes and what fails. Without these, "done" becomes an argument every sprint.
5
Solution validation
After delivery, the BA verifies the solution actually solves the original business problem. This is the step most often skipped, and the step that separates a good BA from a great one.
What a BA does NOT do
Some confusion is worth clearing up early.
Not a project managerA PM owns scope, schedule and budget. A BA owns the answer to "what are we actually building". Big overlap on the day-to-day, but different accountabilities.
Not a developerA BA does not write production code. Reading SQL and understanding system diagrams is part of the job. Writing software is not.
Not a testerA BA defines what good looks like (acceptance criteria). QA verifies it. The line blurs in small teams, but the accountabilities are different.
Not a designerUX designers own the visual and interaction layer. A BA produces wireframes only when no designer exists, and even then they are throwaway artefacts to communicate intent, not final designs.
Why this matters in South Africa specifically
SA has a particular flavour of BA work that does not exist in the same way in the US or Europe.
Legacy systems plus rapid digitisation
Most SA enterprises run on a stack that has at least one component older than the BA themselves. Mainframes at banks. Policy admin systems at insurers. Custom-built systems at telcos that nobody fully understands anymore. Modernising these systems while keeping them running is the day job of most senior BAs in SA.
Regulator pressure
POPIA, FAIS, the Banks Act, FICA, the Cybercrimes Act and a long list of sector-specific regulations all require change at the system level. BAs are the people who translate "comply with section 19" into "here is what the system has to do differently". This is a growing share of BA work, not shrinking.
Scarcity multiplier
BA is on the MICT SETA Sector Skills Plan as a scarce skill. There are simply not enough experienced BAs in SA to meet demand. Most senior BAs we know turn down work weekly. That scarcity creates real career leverage for anyone who can do the job competently.
Key Takeaways
- The BA bridges business and delivery. Surface the need, document it in a usable form, verify the solution against it.
- Five typical artefacts. Requirements documents, process models, stakeholder maps, acceptance criteria and solution validation reports.
- Not a PM, not a developer, not a tester, not a designer. The overlaps are real but the accountability lives in a specific lane.
- SA context matters. Legacy systems, regulator pressure and skills scarcity shape what BAs spend their time on locally.