A business stakeholder says: "We need to speed up our order processing." A developer hears: "Build a faster system." But between those two statements lies an enormous gap — a gap filled with assumptions, ambiguity, unstated constraints, and competing priorities. The business analyst's job is to bridge that gap, transforming vague business needs into specifications precise enough that a development team can build the right thing the first time.
This article walks through the BA's workflow from initial discovery through to validated specifications, covering the specific techniques that produce clarity from chaos.
Phase 1: Discovery — Understanding the Real Problem
Discovery is the most important and most frequently rushed phase. The goal is not to gather requirements — that comes later. The goal is to understand the business context deeply enough that you can distinguish between what stakeholders say they want, what they actually need, and what is feasible within their constraints.
Stakeholder Interviews
Interviews are the foundation of discovery. But effective BA interviews differ significantly from casual conversations. Structure matters.
Start with context questions: What is the business objective? What does success look like? What happens if nothing changes? These questions establish the "why" before diving into the "what." A stakeholder who says "we need a new reporting dashboard" might actually need "visibility into production delays so we can reduce overtime costs." The dashboard is one possible solution. Understanding the actual need opens space for better solutions.
Use open-ended questions to explore: "Walk me through what happens when a new order comes in." "What are the most common problems your team encounters?" "If you could change one thing about the current process, what would it be?" Follow up on specifics: "You mentioned manual reconciliation — how many transactions per day? How long does each one take? What errors are most common?"
Interview at multiple levels. Executives describe strategic objectives. Middle managers describe operational constraints and process bottlenecks. Front-line staff describe the actual daily reality, which is often quite different from what management believes happens. All three perspectives are essential.
A stakeholder who says "we need a dashboard" might actually need "visibility into production delays to reduce overtime costs." Discover the real need.
Observation
People describe their work differently from how they actually perform it. Not because they are dishonest, but because routine tasks become invisible. An accounts clerk who describes their process as "entering invoices into the system" might actually spend 40% of their time reformatting data from supplier emails before they can enter it. They do not mention the reformatting because it has become a normal part of "entering invoices."
Observation — sitting with users while they work — reveals these hidden steps, workarounds, and inefficiencies. It is time-intensive but irreplaceable. At Pepla, our BAs spend time embedded with client teams during discovery precisely because observation surfaces requirements that no interview can uncover.
Document Analysis
Existing documentation — process maps, standard operating procedures, system specifications, training materials, and even complaint logs — provides valuable context. But treat documents as a starting point, not as truth. Process documents frequently describe how work should happen rather than how it actually happens. The gap between documented and actual processes is itself a valuable finding.
Pay particular attention to spreadsheets. In most organisations, the presence of a complex spreadsheet is a reliable indicator that a system gap exists. People build spreadsheets to fill gaps between what their systems do and what their jobs require. Each spreadsheet is a requirements document in disguise.
Phase 2: Analysis — Making Sense of What You Found
Discovery produces a large volume of information — interview notes, observation logs, documents, process descriptions, and stakeholder opinions. Analysis is where you transform that raw material into structured understanding.
Process Modelling
Map the current-state processes that are in scope. Use a notation your stakeholders can read — BPMN is powerful but can be overwhelming for non-technical audiences. Swimlane diagrams work well for most contexts because they clearly show who does what, where handoffs occur, and where delays accumulate.
For each process, identify the pain points: Where do errors occur? Where do things get stuck? Where is manual effort being spent that could be automated? Where are there duplicate activities or unnecessary approvals?
Gap Analysis
Gap analysis compares the current state with the desired state and identifies what must change. This is not a wish list — it is a structured assessment. For each gap, document the current capability, the required capability, the size of the gap, and the impact of closing it (or the cost of leaving it open).
Gaps fall into several categories: process gaps (steps that are missing, redundant, or broken), data gaps (information that is not captured, not accessible, or not accurate), system gaps (functionality that does not exist or does not work), and people gaps (skills, capacity, or roles that are missing).
Not all gaps are equal. Some are root causes; others are symptoms. A common analytical mistake is treating symptoms as requirements. "We need better reporting" is a symptom. "We cannot make data-driven decisions because our order data is captured in three different systems that do not synchronise" is a root cause. Solving the root cause often eliminates multiple symptoms simultaneously.
Stakeholders describe what they want, not what they need. The BA's job is to discover the real problem hiding behind the stated request.
Prototyping
For complex or novel solutions, prototyping during analysis — not during development — dramatically reduces risk. A prototype can be as simple as a paper sketch of a screen layout, a clickable wireframe, or a spreadsheet that simulates a calculation engine.
The purpose of an analysis-phase prototype is not to design the solution. It is to validate understanding. Show a stakeholder a rough prototype and they will immediately tell you what is wrong, what is missing, and what they actually meant when they said "a dashboard." This feedback loop is orders of magnitude cheaper during analysis than during development.
Phase 3: Specification — Writing Requirements Developers Can Use
This is where many BAs struggle, and where the quality of the specification directly determines the quality of the delivered software. A specification that is ambiguous, incomplete, or internally contradictory will produce software that is wrong, incomplete, or inconsistent.
The Anatomy of a Good Requirement
Each requirement should be:
- Specific. "The system shall calculate the order total including VAT at the rate configured for the customer's province" is specific. "The system shall handle taxes" is not.
- Measurable. If you cannot test it, it is not a requirement. "The system shall be fast" is not testable. "The search results page shall load within 2 seconds for up to 10,000 records" is testable.
- Traceable. Every requirement should trace back to a business need identified during discovery. If a requirement cannot be traced, question whether it is necessary.
- Prioritised. Not every requirement is equally important. Use MoSCoW (Must, Should, Could, Won't) or a simple High/Medium/Low scale. This gives the development team the information they need to make trade-off decisions.
- Independent where possible. Requirements that are tightly coupled create cascading change when one requirement is modified. Write each requirement to stand on its own as much as practical.
User Stories and Acceptance Criteria
In agile contexts, user stories are the primary requirements format. The standard template — "As a [role], I want [capability] so that [benefit]" — is a good starting point, but the real value lives in the acceptance criteria. These are the specific, testable conditions that must be true for the story to be considered complete.
Write acceptance criteria using Given-When-Then format: "Given a customer with a verified credit rating, when they submit an order exceeding R50,000, then the system shall apply the pre-approved credit terms without manual intervention." This format is unambiguous and directly translatable into test cases.
Non-Functional Requirements
Functional requirements describe what the system does. Non-functional requirements describe how well it does it. Performance, security, availability, scalability, accessibility, and compliance requirements are all non-functional — and all are frequently overlooked until they cause production failures.
Specify non-functional requirements with the same precision as functional ones. "The system shall be secure" is meaningless. "All API endpoints shall require OAuth 2.0 authentication, all data at rest shall be encrypted using AES-256, and all user sessions shall expire after 30 minutes of inactivity" is actionable.
Phase 4: Validation — Confirming You Got It Right
Validation is the checkpoint between specification and development. Its purpose is to confirm that the documented requirements accurately represent the stakeholders' needs and that the proposed solution is feasible within the project constraints.
Structured walkthroughs are the primary validation technique. Walk through each requirement with the relevant stakeholders, using concrete scenarios. "Let's trace what happens when a customer in Gauteng places an order for three items, one of which is out of stock, and they want split delivery." Scenarios reveal gaps and inconsistencies that reading a requirements document does not.
Technical validation is equally important. Review specifications with the development team before they start building. They will identify technical constraints, integration challenges, and implementation risks that the BA may not have considered. This review frequently surfaces questions that require going back to stakeholders for clarification — which is exactly what should happen at this stage rather than during development.
At Pepla, the specification review between our BA team and development team is a formal step in every project. The developers ask the hard questions here so that the build phase can focus on building rather than on discovering that the requirements are incomplete.
Validate specifications with developers before building -- questions are cheap in analysis and ruinously expensive in production.
The BA's Toolkit in Practice
No single technique works for every situation. Experienced BAs select and combine techniques based on the context:
- Interviews work best for understanding strategic context and surfacing unstated needs.
- Observation excels at revealing actual workflows and hidden workarounds.
- Document analysis provides historical context and existing process documentation.
- Prototyping is essential when stakeholders cannot articulate what they want until they see something tangible.
- Gap analysis structures the transition from current state to target state.
- Workshops bring multiple stakeholders together to resolve conflicts and build consensus.
Each spreadsheet in an organisation is a requirements document in disguise -- it fills a gap between what systems do and what jobs require.
The journey from business need to technical solution is iterative, not linear. Expect to cycle between discovery, analysis, and specification multiple times as understanding deepens. The investment in getting requirements right is the highest-return investment in any software project — because the cost of fixing a requirements error in production is fifty to two hundred times the cost of finding it during analysis.
