The BA's central job is translation. Business stakeholders speak in outcomes; engineers build from specifications; the BA is the only person on the team whose job is to make sure each side ends up with what they actually need. The work is harder than it looks because translation is lossy by default, and the costs of bad translation show up months later in production, when fixing them is most expensive.
This lesson is not about the FRS artefact (Module 5 Lesson 2 covers that). It is about the discipline of translation itself. The mindset, the common failure modes, the conversation patterns and the technical literacy that supports the work.
What translation actually is
A business sponsor says: "We need to reduce loan abandonment." That is not yet a requirement. It is an intent. The translation work fills the gap between intent and something engineers can build from.
From intent to specificationThe gap closes through specific questions. What does abandonment mean (started but not completed, or all applications regardless of stage)? Reduce by how much, measured over what period, against what baseline? Which causes are in scope (form length, document friction, response time, opaque declines)? What does the system need to do differently for each? Only when those answers exist does the original intent become a specification a team can build.
Translation is moving from intent to specification, not paraphrasing business language into technical language. Most BAs who struggle in tech-delivery contexts are paraphrasing; the BAs who thrive are clarifying.
The four common failure modes
1
Lossy translationThe BA paraphrases business needs into technical-sounding language without sharpening them. Ambiguity is preserved, not removed. Engineers later interpret the ambiguity in their own way. The build matches the spec but not the intent. This is the most common failure on slow-moving SA enterprise projects.
2
Over-specificationThe BA assumes a specific solution and writes the spec around it. Engineering loses design freedom. Better alternatives never surface because the spec already locked the design. Often happens when the BA used to be a developer and reaches for the implementation they would write.
3
Translation-by-escalationThe BA punts hard decisions to engineering. 'I do not know whether this should be synchronous or asynchronous, work it out.' Engineering decides, often based on what is easy to build rather than what business needs. The cost shows up in production behaviour the business sponsor never agreed to.
4
The spec was right, the build was wrongThe translation was clean; the build did not follow it. Usually a sign that the team did not engage with the spec early enough. Engineers built from memory of an early conversation, not the refined spec. Mitigation: walk engineers through the spec before they start coding, not after.
The translator's toolkit
The discipline rests on four tools the BA brings to every translation.
VocabularyShared terms that mean the same thing on both sides. 'Customer' means one thing to the business and another to the data team. 'Account' means one thing to operations and another to finance. The BA's job is to enforce one definition. A glossary at the front of the spec is not optional; it is the single highest-leverage page.
ModellingPictures absorb ambiguity that prose preserves. A BPMN diagram forces decisions that a sentence can paper over. An ERD makes implicit relationships explicit. A sequence diagram surfaces the timing assumptions in an integration. Reach for the model before reaching for more prose.
ExamplesReal or realistic. 'When a customer applies on a Friday at 16:55 with a pre-existing late repayment in the last 60 days...' is more useful than 'when a customer applies with a poor credit history'. Engineers build from examples better than from rules; QA writes tests from examples better than from rules.
Edge casesThe parts of the system that do not happen often but cost most when handled wrong. Surface them deliberately during translation. The business sponsor will not raise them; the engineer cannot raise what they have not seen. The BA who systematically asks 'what about...' is the BA who delivers requirements that hold up in production.
The BA-tech-lead conversation rhythm
Translation works when the BA and tech lead pair on it. The rhythm:
1
BA brings draft specs to the tech lead before the team sees themPre-sharing surfaces ambiguity and over-specification at the cheapest moment. The 30 minutes the tech lead spends on the draft saves 3 days of sprint-time confusion.
2
Tech lead pushes backOn unclear behaviour, missing edge cases, integration assumptions and timing. The BA does not defend the draft; the BA listens and adjusts.
3
BA goes back to business for clarificationWhere the tech lead's pushback reveals that the business intent itself was unclear. The conversation is 'you said X, the tech lead is asking Y, what should it really do?' The sponsor often discovers their own ambiguity.
4
Tech lead and BA jointly walk the team through the resultRefinement is the joint walkthrough, not the BA presenting at the team. The tech lead has skin in the spec; the team treats it as agreed engineering territory.
When the BA writes specs in a vacuum and hands them to the team, translation usually breaks. The fix is the pairing.
When to stop translating and go back to business
A practical signal worth memorising: when you find yourself making 3+ assumptions to specify a section, stop. Each assumption is a guess about intent. Three guesses stacked together is no longer translation; it is invention.
The assumption testTake the section you are about to specify. List the assumptions you are about to make. Count them. If the list reaches 3, the work needs to go back to the business sponsor before any more spec gets written. Surface the assumptions explicitly: 'I am about to assume X, Y and Z. Are those correct, or should the specification be different?' The senior BA does this routinely; the junior BA writes the assumptions silently into the spec and lives with the consequences months later.
Technical literacy: how much is enough
You do not need to write production code. You do need:
1
Reading depth, not writing depthRead a function and explain what it does. Read an API endpoint and explain what it expects and returns. Read a SQL query and explain what data it pulls. Reading is the bar; writing is not.
2
System diagrams without needing them explainedArchitecture diagrams, sequence diagrams, deployment diagrams. Recognise the shapes and what they mean. Ask intelligent questions about them. The architect explaining 'this is the message broker' should not need to first explain what a message broker is.
3
Conversational fluency in the basicsWhat an API is, what a database is, what a queue is, what a cache is, what a load balancer is, what an environment is (dev/stg/prd). At the level you could explain to a smart non-technical person. Not at the level of designing one.
4
The SDLC and where requirements work fits in itWhere requirements lock in, where design happens, where code gets written, where it gets tested, where it gets deployed, where it gets monitored. Without this, the BA cannot anticipate where their work lands and where it gets stale.
This is achievable in 4-6 months of deliberate study for a non-technical BA. Beyond this, more depth helps; it is not required for the role.
The engineering-team relationship as backdrop
Translation works in a team that respects the BA's authority on what gets built and the tech lead's authority on how. When that respect is missing (engineers ignore the spec, BAs ignore engineering pushback), translation fails regardless of technique.
SA enterprise realityIn matrix-managed SA enterprises (banks, large insurers, telcos), the BA often does not formally report to the tech lead. The relationship is collegial, not hierarchical. The BA who treats engineering as a peer relationship (information-sharing, mutual challenge, shared accountability for the build) gets better translation than the BA who treats it as either a customer ('engineering, please build this') or a supplier ('I will accept whatever engineering produces'). The peer framing is the productive one.
A worked example: from intent to specification
A sponsor says: "Customers should not be able to apply for the same loan twice."
A junior BA writes: "The system must prevent duplicate loan applications." Engineers ask: by customer? by amount? by timestamp? same product? same branch? Within how long? The spec is one sentence and four ambiguities.
A senior BA writes (after the pairing with the tech lead and a clarifying call with the sponsor):
Worked specFR-X: Duplicate application prevention.
The system shall prevent a customer from submitting a new small-business loan application if they have an existing application (status: Pending or Approved) for the same loan product, within the same calendar quarter.
Edge cases handled:
- A customer with a Declined or Withdrawn previous application IS permitted to re-apply.
- A customer with an Approved application that has been disbursed IS permitted to apply for a separate additional loan.
- 'Customer' is identified by SA ID number; spouses applying separately are NOT treated as the same customer.
- The prevention check is applied at submission time, not at draft-save time.
The system shall display a clear message to the customer if a duplicate is detected: 'You have a recent application for this product. Please wait until it is fully resolved before applying again.'
Same intent. One sentence vs one spec. The second is what engineers can build from without coming back with questions.
Key Takeaways- Translation is moving from intent to specification. Paraphrasing is not translation; clarifying is.
- Four common failure modes. Lossy translation, over-specification, translation-by-escalation, spec-right-build-wrong.
- Toolkit. Vocabulary, modelling, examples, edge cases.
- BA-tech-lead pairing. Pre-share with the tech lead before the team sees it.
- Stop and go back when assumptions reach 3. The senior BA surfaces assumptions; the junior writes them silently into the spec.
- Technical literacy is reading depth. Reading code and diagrams, conversational fluency in the basics, knowing where requirements fit in the SDLC.
- The engineering-team relationship is the backdrop. Treat engineering as peer, not customer or supplier.