The business analyst is the person who ensures that what the development team builds is actually what the business needs. That sounds simple. In practice, it is one of the most challenging and underappreciated roles in software delivery. At Pepla, our BAs form the White Team -- a dedicated unit whose entire purpose is bridging the gap between business intent and technical execution. Understanding what this role entails, and how it differs from adjacent roles, is essential for anyone involved in software projects.
BA vs PM vs PO -- Drawing the Boundaries
Three roles in software delivery regularly overlap and cause confusion: the Business Analyst, the Project Manager, and the Product Owner. All three work with stakeholders. All three influence what gets built. But their focus is fundamentally different.
The Project Manager owns the plan. They are responsible for scope, schedule, budget, and risk. They answer the question: "Will we deliver on time and within budget?" They coordinate resources, manage dependencies, escalate blockers, and report progress to sponsors. Their concern is the how and when of delivery.
The Product Owner owns the vision. In agile frameworks, the PO decides what gets built and in what order. They manage the product backlog, prioritise features based on business value, and make trade-off decisions when time or resources are constrained. Their concern is the what and why at a strategic level.
The Business Analyst owns the detail. They take the PO's high-level priorities and decompose them into specific, unambiguous, implementable requirements. They model existing processes to understand the current state, define the future state, and document the gap between them. Their concern is the what at a granular level -- precise enough that developers can build it, testers can verify it, and stakeholders can confirm it matches their intent.
In smaller teams, these roles sometimes overlap. A BA might act as PO, or a PM might do business analysis. But in complex projects with multiple stakeholders and intricate business rules, collapsing these roles creates blind spots. Each role has a distinct skillset and a distinct accountability.
Requirements Elicitation Techniques
The BA's most critical skill is elicitation -- extracting requirements from stakeholders who often cannot articulate what they need, or who articulate what they want (which is a different thing entirely).
Effective BAs use multiple elicitation techniques depending on the context. Structured interviews work well for capturing domain expertise from subject matter experts. The BA prepares targeted questions, follows threads that emerge, and documents findings immediately. Workshops bring multiple stakeholders together to resolve conflicting requirements, build consensus, and map complex processes collaboratively. Observation (also called job shadowing) reveals how work actually happens, as opposed to how people think it happens -- the gap between the two is often significant.
Document analysis involves reviewing existing documentation, forms, reports, and system outputs to understand current capabilities and business rules. Prototyping shows stakeholders a rough version of the proposed solution early, which surfaces misunderstandings before they become expensive to fix. Surveys and questionnaires are useful for gathering input from a large number of stakeholders when individual interviews are impractical.
The most experienced BAs combine these techniques. They might start with document analysis to understand the current state, conduct interviews to fill gaps, run a workshop to resolve conflicting perspectives, and build a prototype to validate their understanding. Each technique reveals different information, and relying on only one technique leaves blind spots.
The BA does not gather requirements passively. They actively probe, challenge, and synthesise -- distinguishing what stakeholders want from what they need.
Relying on a single elicitation technique leaves blind spots. The best BAs combine interviews, observation, workshops, and prototyping.
Writing User Stories and Acceptance Criteria
In agile teams, the primary vehicle for communicating requirements is the user story. A well-written user story follows the familiar format: "As a [user role], I want to [action], so that [benefit]." But the format is the least important part. What matters is that the story captures who needs the capability, what they need to do, and why it matters to them.
The real craftsmanship lives in the acceptance criteria. These are the specific, testable conditions that must be true for the story to be considered complete. Good acceptance criteria are unambiguous, measurable, and independent of implementation. They describe behaviour, not technical approach.
Consider this example. A weak acceptance criterion: "The search should be fast." A strong acceptance criterion: "Search results for a query of up to three keywords return within 1.5 seconds for a dataset of up to 500,000 records, with results ranked by relevance score." The second version is testable, specific, and leaves no room for interpretation.
At Pepla, our BAs write acceptance criteria using the Given-When-Then format where behaviour is complex. "Given the user has items in their cart and their session has been inactive for 30 minutes, when the session expires, then the cart contents are preserved for 7 days and restored upon next login." This format maps directly to test cases, which tightens the feedback loop between requirements and verification.
Process Modeling
Before you can improve a business process, you need to understand it. Process modeling is how BAs make the invisible visible -- turning unwritten workflows, tribal knowledge, and ad-hoc procedures into structured, visual representations that everyone can understand and discuss.
The most common notation is BPMN (Business Process Model and Notation), which provides a standardised set of symbols for events, activities, gateways, and flows. A BPMN diagram shows how a process starts, who does what, where decisions are made, and how the process ends. It makes bottlenecks, redundancies, and handoff points visible in a way that narrative descriptions cannot.
Swimlane diagrams extend this by showing which role or department is responsible for each step. This is particularly valuable for cross-functional processes where work passes between teams. The visual layout immediately reveals handoff complexity -- if a process zigzags between lanes repeatedly, it is a candidate for simplification.
At Pepla, we model both the "as-is" process (how things work today) and the "to-be" process (how they will work after the new system is implemented). The gap between these two models defines the scope of the project more precisely than any feature list can.
Data Dictionaries
A data dictionary is one of the BA's most unappreciated deliverables. It documents every data element the system handles: the name, the definition, the data type, valid values or ranges, the source, and any business rules that apply. It sounds mundane. It prevents an extraordinary number of defects.
Without a data dictionary, "customer name" might mean full name to one stakeholder, surname only to another, and display name to a third. "Order date" might mean the date the order was placed, the date it was confirmed, or the date it entered the system. These ambiguities propagate through development, testing, and reporting, creating bugs that are expensive to find and fix because they stem from misunderstanding rather than implementation error.
A well-maintained data dictionary serves as a single source of truth for the entire project team. Developers reference it when building database schemas and APIs. Testers reference it when creating test data. Report builders reference it when constructing queries. It is a small investment with disproportionate returns.
A data dictionary sounds mundane, but it prevents an extraordinary number of defects caused by ambiguous field definitions.
The BA in Agile Teams
Some agile purists argue that the BA role is unnecessary in Scrum teams -- that the Product Owner handles requirements, and the team is cross-functional enough to figure out the details. In practice, this works for simple products with small teams and straightforward business rules. It breaks down rapidly when the domain is complex, the stakeholder landscape is broad, or the business rules are intricate.
In Pepla's agile teams, the BA works closely with the PO. The PO sets priorities and makes trade-off decisions. The BA ensures those priorities are decomposed into stories with sufficient detail for the team to estimate and implement them. The BA participates in sprint planning, clarifying requirements in real time. They attend daily standups to catch misunderstandings early. They are available throughout the sprint to answer questions that arise during development.
The BA's value in agile is not in producing documents. It is in ensuring that every story the team picks up has been thought through well enough that the team can build it without guessing.
This does not mean BAs produce heavyweight specifications upfront. It means they work one to two sprints ahead of the development team, preparing stories to the level of detail needed for the upcoming work. This "just-in-time" analysis reduces waste while ensuring the team always has well-defined work ready.
Tools of the Trade
The BA's toolkit has evolved significantly. For requirements management, tools like Jira, Azure DevOps, and Confluence provide structured environments for capturing, linking, and tracking requirements. For process modeling, tools like Lucidchart, draw.io, and Bizagi offer BPMN support with collaboration features. For prototyping, Figma and Balsamiq allow BAs to create visual representations of proposed solutions without needing design skills.
But tools are secondary to technique. The most effective BA we have ever worked with at Pepla did most of her elicitation with a whiteboard, a camera phone, and a shared document. The tool matters less than the discipline of capturing, validating, and communicating requirements consistently.
What has changed is the expectation of traceability. Modern projects require requirements to be linked to user stories, test cases, and delivered features. This traceability ensures that nothing falls through the cracks and provides an audit trail for regulated industries. Tools like Jira make this linkage practical at scale -- provided someone maintains it. That someone is usually the BA.
Why BAs Matter
Studies consistently show that requirements defects are the most expensive to fix. A misunderstood requirement that reaches production costs 50 to 200 times more to fix than one caught during analysis. The BA's primary contribution is reducing this risk -- not by producing perfect requirements (which is impossible), but by surfacing misunderstandings, resolving ambiguities, and ensuring that what the team builds matches what the business needs.
A misunderstood requirement in production costs 50-200x more to fix than one caught during analysis. BAs are the cheapest insurance you can buy.
At Pepla, we have seen projects with strong BA involvement complete with significantly fewer change requests and rework cycles than those without. The BA does not slow down delivery. They accelerate it by preventing the costly detours that come from building the wrong thing.
