Business Analyst
A business analyst turns ambiguity into requirements, test cases, and specifications a delivery team can build against. This pillar covers that work in practice: writing requirements developers can implement, prioritizing with MoSCoW, building a traceability matrix, and turning a one-line business request into a functional spec. Every article here is written for analysts already on a delivery team, with real artifacts you can adapt rather than theory.
What non-functional requirements are, the categories that matter, and how to write NFRs that are testable: measurable targets instead of adjectives. With examples.
What slowly changing dimensions are, how SCD Type 1 and Type 2 differ, how a Type 2 table works with valid_from and valid_to, and how to query it correctly.
What SQL window functions do and the three patterns analysts use daily: ROW_NUMBER for latest record per group, LAG for event timing, SUM OVER for running totals.
What user acceptance testing is, how UAT differs from SIT and QA testing, who writes the scenarios, and the entry and exit criteria that make a UAT cycle real.
The ISO 20022 reason codes analysts meet daily: account codes (AC01, AC04, AC06), amount codes (AM04, AM05), agent and regulatory codes, with the action each implies.
CBPR+ ends fully unstructured addresses in November 2026. What structured and hybrid addresses are, the elements that matter, and how to migrate without rejections.
A business analyst describes intended behavior; a technical BA verifies it against the running system. What separates the roles and how to cross the gap.
Data engineers build the pipelines and platforms that move data; analytics engineers model it in the warehouse so it means something. The split, explained.
Data lineage maps how each field flows from source through transformations to the report that shows it, enabling impact analysis, trust, and audit. With a diagram.
A data mesh decentralizes data: domains own and publish their data as products, on a self-serve platform, under federated governance. Explained with a diagram.
Fivetran and Airbyte both move source data into your warehouse. They differ on openness, hosting, pricing, and who fixes the connector when the API changes.
A functional analyst is accountable for exact system behavior; a product owner for what gets built and in what order. The split, and which seat fits you.
Kimball builds dimensional marts first and integrates through conformed dimensions; Inmon builds a normalized enterprise warehouse first. The classic debate, mapped.
A warehouse is a managed analytical database; a lakehouse adds warehouse guarantees to open files on object storage. The real differences, with a diagram.
Looker is a code-defined semantic layer that governs metrics; Tableau is the strongest visual exploration tool. What each optimizes for and when each fits.
Snowflake and BigQuery are both elastic cloud warehouses. They differ on compute models, pricing units, cloud lock-in, and the knobs your team must operate.
Star and snowflake schemas differ in one thing: whether dimensions are denormalized. What each looks like, when each fits, and how to read one. With diagrams.
A systems analyst maps how systems connect and behave; a solutions architect decides how they should, and answers for it. The line, the overlap, and the jump.
A self-assessment matrix of 25 skills across the five technical analyst hats, with three levels per skill and where to build each one. Original to this site.
Both are technical; the deliverables differ. A technical BA ships verified understanding and specs; an engineer ships production code. Which seat fits you.
How to write acceptance criteria for AI and LLM features when outputs are non-deterministic. Use bounds, properties, guardrails, and evaluation sets, not exact matches.
A practitioner guide to API testing: status codes, response schemas, request chaining, authentication, error contracts, and the checks that actually catch defects.
Batch and event-driven processing differ in timing, and that difference shapes latency, failure modes, and customer experience. When to use each, with banking examples.
The difference between a Business Requirements Document and a Functional Requirements Document: what each covers, who reads it, and when you need both. With examples.
How to turn a vague business requirement into a precise functional specification: decompose intent, define inputs and outputs, and write testable behavior. With examples.
What a data dictionary is, how to build one, and why a single authoritative definition of every field prevents the ambiguity that breaks integrations and reports.
How to use decision tables to specify complex business rules completely: conditions, actions, rule columns, and collapsing combinations. The tool that leaves no case undefined.
How to write requirements for event-driven systems: event schemas, ordering, idempotency, retries, and consistency. A practitioner guide with a Kafka example.
How to run a fit-gap analysis: compare requirements against system capability, classify each as fit, gap, or partial, and turn gaps into decisions. With a payments example.
A practical functional specification template: scope, actors, data, business rules, behavior, error handling, and acceptance criteria. The structure that makes a spec buildable.
The Git an analyst actually needs: clone, navigate, read a diff, browse history, and find when behavior changed. Read the codebase without breaking anything.
A walkthrough of how a technical business analyst actually investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the cause.
Write API requirements the right way: endpoint, method, request and response schema, status codes, error contracts, and testable acceptance criteria. With examples.
The integration patterns that wire systems together: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. With payments examples.
What ISO 20022 actually is as an architecture: the business model, message definitions, structured data, and usage guidelines that shape modern payment systems.
How to use MoSCoW prioritization to rank requirements: what each category means, how to apply it without everything becoming a Must, and how it drives scope decisions.
How to design negative tests systematically: boundary values, invalid inputs, state violations, and failure injection. The unhappy path is where the real defects live.
A practitioner guide to payment testing: following one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases that matter.
How to map payment reason codes to causes and customer messages: ISO 20022 codes like AC04, internal errors, and the mapping that prevents support incidents.
How to design reconciliation between systems: matching keys, break detection, tolerance, timing, and exception handling. The control that proves the money is right.
What a requirements traceability matrix is, how to build one, and why it proves every requirement is designed, built, and tested. With a payments example.
How business analysts use sequence diagrams to map a flow across services, expose integration gaps, and write better requirements. With a payments example.
The SQL a technical analyst actually needs: SELECT, WHERE, JOIN, GROUP BY, and reading state during analysis and testing. Not for reports, for finding the truth.
What a system context diagram is, how to draw one, and why starting at the boundary stops you scoping the wrong thing. With a payments example and the C4 model.
User stories capture intent; specifications capture exact behavior. Here is the real difference, when each fits, and why complex systems need both. With examples.
A functional analyst turns business intent into precise, testable system behavior. Here is what the role does in banking and payments, and how it differs from a BA.
A technical business analyst analyzes, codes, tests, and supports. Here is what the role actually does day to day in banking and payments, and how to become one.
Field notes on an AI project where the acceptance criteria did not work: why exact-match criteria break on non-deterministic output, and what we replaced them with.
PAIN vs pacs explained: why pain.001 is not pacs.008, how pain.002 and pacs.002 mirror it, where camt fits, and how ISO 20022 splits customer and bank.
Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.
Newsletter
Practical, no-fluff playbooks for technical analysts who analyze, code, test, and support. New articles straight to your inbox.
No spam. Unsubscribe anytime.