BRD vs. FSD vs. TSD: How to Write a Technical Specification Document
BRD vs FSD vs TSD is really a question of who is reading the document and what question it needs to answer. Here is exactly where the three split, and a full walkthrough of how to write a technical specification document your engineering team can build from without guessing.
Same project, three different rooms, three different questions.
Introduction
Ask five people what the difference is between a BRD, an FSD, and a TSD, and you will probably get five slightly different answers, and at least one blank stare. Part of the confusion is that these three documents genuinely do overlap in places. The bigger part is that most teams never sat down and agreed on where one stops and the next one starts. That gap is exactly where scope creep, missed requirements, and “wait, who approved this feature” conversations tend to come from.
This guide walks through what each document actually covers, where the real boundaries sit, and then goes deep on the one a Technical Business Analyst usually owns the most: how to actually write a technical specification document that a development team can build from without three rounds of clarifying questions.
What Are BRD, FSD, and TSD?
Every software project that survives past the whiteboard stage tends to produce the same three documents, even if a given team does not always use these exact names. Each one is written for a different room, answers a different question, and when someone confuses their jobs, requirements start slipping through the cracks between them.
A BRD explains why the project exists. An FSD explains what the system needs to do to deliver on that reason. A TSD explains how the technical team is actually going to build it. That single sentence is really the whole relationship, and almost everything that goes wrong in requirements documentation traces back to one of these three quietly answering a question that belonged to a different document.
Core Differences Between BRD, FSD, and TSD
Business Requirements Document (BRD)
The BRD sits at the very top of the funnel. It gets written before anyone has decided how a single screen will look, because its entire job is capturing the business goal, the market opportunity behind it, the financial objectives tied to it, and the constraints the project has to work within. Project sponsors, executives, and business stakeholders are the audience here, people who care about outcomes and return, not screen flows.
Functional Specification Document (FSD)
Once the business case is approved, the FSD takes over and answers a genuinely different question. This is where use cases, user workflows, screen states, validation rules, and error messages get documented in detail. Developers, QA testers, and business analysts are the primary audience, because this is the document a tester will eventually check every acceptance criterion against.
Technical Specification Document (TSD)
The TSD goes one layer deeper again. It stops describing what the user sees and starts describing how the system underneath actually gets built: architecture, database schemas, programming languages, APIs, and security protocols. Software engineers, system architects, and DevOps teams live in this document daily, and it is usually the one a Technical Business Analyst is most directly responsible for shaping.
A BRD defines what the business needs. An FSD explains how the system will work to meet that need. A TSD describes the technical build required to make it real. Together, they carry a project from an idea to a working product.
Key Differences at a Glance
| Aspect | BRD | FSD | TSD |
|---|---|---|---|
| Core Question | Why build this? | What must it do? | How will it be built? |
| Written By | Business analysts or product managers | Product managers or systems analysts | Software architects or lead engineers |
| Primary Audience | Sponsors, executives, stakeholders | Developers, QA, business analysts | Engineers, architects, DevOps teams |
| Typical Content | Business goals, scope, success metrics | Use cases, screen flows, validation rules | Architecture, data models, APIs, security |
If you want a broader look at how the functional and technical layers split beyond just documentation, our Functional BA vs. Technical BA guide covers the same divide across skills, tools, and daily work.
How to Write a Technical Specification Document
Since the TSD is the document most Technical BAs eventually own or contribute to, here is a structure that holds up on real projects.
State the Overview
Start with a short summary anyone on the team can read in under a minute, what is being built and what the technical scope covers. This section exists so a new engineer joining midway through the project does not need three separate meetings just to get oriented.
Define System Architecture
Describe the software stack and frameworks being used, and back it with a diagram showing how the different services actually talk to each other. Words alone rarely communicate architecture cleanly, a simple boxes-and-arrows diagram does more work than three paragraphs of prose ever will.
Design Data Models
Lay out the database schema, the tables, and how they relate to each other. This is also where you explain how data moves through the system and gets saved safely, which matters more than it sounds like it should. A large share of production incidents trace back to a data model nobody documented properly.
Map Out APIs and Integrations
List every endpoint the system exposes or consumes, along with what each request and response actually contains. If the project touches any third-party service, document that integration here too. For a full walkthrough of exactly how to structure this section, our guide to API basics for business analysts covers reading JSON payloads and writing a complete endpoint specification.
Plan Security and Error Handling
Define user roles and permission rules clearly enough that nobody has to guess who can access what. Then document exactly how the system should behave when something breaks, a crash, bad input, an expired session. “Handle errors gracefully” is not a specification, it is a wish.
Ready to Write TSDs That Cut Rework, Not Cause It?
Reading a structure is one thing. Writing a technical specification for a live integration, with real data models and API contracts, is another. Techcanvass’s Technical Business Analyst Course covers TSD writing, system architecture, and API documentation through hands-on, project-based learning.
Common Mistakes When Writing These Documents
Skipping the BRD and jumping straight into an FSD, which usually means nobody actually agreed on the business goal before development started.
Writing a TSD that describes what the system does instead of how it is built, which mostly duplicates the FSD in heavier technical language.
Treating security and error handling as an afterthought at the end of a TSD instead of a first-class section from the start.
Letting the three documents drift out of sync as a project evolves, so the BRD says one thing and the TSD quietly says another.
This exact BRD versus FSD versus TSD distinction shows up constantly in real interviews too. Our Technical Business Analyst interview questions guide covers how these documentation questions actually get asked and what a strong answer sounds like.
Final Thoughts
BRD, FSD, and TSD are not competing documents, they are three checkpoints on the same journey from business idea to working software. Knowing exactly where one hands off to the next, and being able to write a technical specification document clearly enough that a developer never has to guess, is one of the most practical technical business analyst skills you can build. Get comfortable moving fluently across all three, and you stop being the person who writes documents nobody trusts, and start being the person whose documents ship on the first try.
Related Tech BA Reads
Documentation is one piece of the technical layer. Here is the rest of the roadmap.
The full roadmap this documentation guide is one module of, from first principles to your first 90 days.
