What a Business Analyst Does in a Software Project
Basics4 minInnovialabs editorial team
In short
A business analyst translates business problems into requirements developers can build from: they find out what is needed and why, map the processes and make sure the team builds what actually solves the problem.
Who a business analyst is
A business analyst (BA) is the person who figures out which business problem a system must solve and turns that into clear, testable requirements for the development team.
An owner says: "Our managers lose leads." A developer needs something else: where leads come from, what fields they have, who assigns them, what counts as a "lost" lead, which notifications are needed. The analyst is the one who gets from the first sentence to the second list.
What a business analyst does
Gathers and clarifies requirements
- interviews the owner, department heads and front-line staff;
- studies existing documents, spreadsheets and procedures;
- separates the real need from a proposed solution ("we need a button" often means "we need less manual work");
- sets priorities: what goes into the first version and what can wait.
Models processes
The analyst describes how work happens now (as-is) and how it will happen with the new system (to-be). Process diagrams are used for this, for example in BPMN notation, along with scenario diagrams and simple flowcharts. Often it turns out at this stage that some problems are solved by changing the process, not by writing code.
Writes documentation
Typical artefacts:
- user stories with acceptance criteria;
- use cases;
- roles and access rights;
- a data model: which entities exist and how they relate;
- requirements for integrations and reports.
Bridges business and development
During the project, the analyst answers developers' and testers' questions, clarifies details with the client, assesses the impact of changes and checks that the result matches the original goal.
Business analyst, systems analyst and project manager
| Role | Main question | Output |
|---|---|---|
| Business analyst | What does the business need and why? | Business requirements, process models |
| Systems analyst | How will the system implement it? | APIs, data schemas, technical specs |
| Project manager | How do we deliver on time and budget? | Plan, timeline, risk control |
| Product manager | What should we build next and why? | Product strategy, priorities |
In small teams these roles are often combined: an analyst may cover both business and systems work, and a manager may take on requirements gathering.
When you can do without an analyst
- A simple project with a clear scope: a landing page, a brochure site, a small bot with a couple of scenarios.
- The client writes requirements well and can dedicate time to the project.
- A standard solution: configuring an off-the-shelf CRM for a typical sales process.
- A quick prototype meant to test an idea rather than build a system.
When skipping an analyst is risky
- Process automation across several departments with different interests.
- Integrations between accounting, CRM, website and external services.
- Complex rules: pricing, calculations, discounts, access rights.
- No single person knows the whole process end to end.
- A regulated industry where formal requirements matter: finance, healthcare, government.
In these projects the most expensive mistake is building the wrong thing. Reworking a finished module costs noticeably more than clarifying a requirement before development starts.
How to work with an analyst as a client
- Give access to the people who actually do the work, not just managers.
- Appoint a decision-maker on your side.
- Read and approve the documents; they are your main control tool.
- Talk about problems, not solutions. A good analyst will propose options.