Synonyms:Â BA, requirements analyst, functional analyst, IT business analyst, product analyst
Do not index
Definition
A business analyst (BA) bridges business needs and technical solutions, turning stakeholders' vague, sometimes shifting problems into clear, documented requirements a team can build.
The work runs across eliciting requirements, mapping processes, managing stakeholders, and checking that what ships matches what was asked for. On product teams the role overlaps with product management and UX, though a BA's loyalty sits with the business, where a designer's sits with the user, and it leans on the same comfort with ambiguity as design for uncertainty.
Use cases
A BA is the insurance against building the wrong thing. Skip the role or do it badly, and the team ships exactly what was asked for, which turns out to be exactly what nobody needed.
A stakeholder asks for "a new report." A good BA digs into why and finds the real need is a different decision entirely. A rushed one just documents the report, and the team builds something no one opens.
Requirements live in three people's heads and none of them agree. Without a BA to pin them down and get sign-off, developers build to guesses and rework eats the sprint.
A BA gathers requirements but never loops back to check the built feature against them. It ships "done," and the mismatch only surfaces when users complain.
How the role works in practice
Elicit, don't just collect: run interviews and workshops, and keep asking "why" until the real problem surfaces under the stated request.
Write requirements someone can act on, split into functional (what it does) and non-functional (how well it performs).
Trace requirements from source to shipped feature so nothing quietly drops out of scope.
Stay in the loop through build and testing to resolve the edge cases the original spec never covered.
🪄
Pro tip:Â On a UX team, the sharpest tension is whose problem you're solving. A BA's job is the business case, a designer's is the user, and the best products come from keeping both honest. Treat the BA as a partner who pressure-tests feasibility, not a gatekeeper who owns "the requirements."
Â
Challenges & limitations
The role is loosely defined. What a BA actually does shifts by company, from pure requirements work to product-owner duties, so the title tells you little about the real job.
Heavy documentation can slow agile teams. Done badly, requirements docs become a bottleneck instead of a shared understanding.
