Helping your team connect OpenBoxes WMS and ShipStation TMS without chaos.
The Real Problem: Systems Don't Talk
Imagine a busy 3PL warehouse using OpenBoxes for inventory and ShipStation for parcel shipping — but they’re not connected. Orders come in. Someone exports a spreadsheet. Someone else pastes it into another tool. Nothing syncs. Things fall through the cracks.
That’s the situation one of our clients faced. And the first step to fixing it wasn’t writing code — it was writing a clear Business Requirements Document.
What Is a BRD (and Why It’s Not Just Corporate Fluff)?
A Business Requirements Document (BRD) is a simple, structured doc that answers:
What business problem are we solving?
What systems or teams are involved?
What must the final result do (and not do)?
A BRD is not about tech specs or APIs. It’s about clarifying the goal, the scope, and the rules of engagement — for PMs, business owners, and dev leads alike.
When and Why to Use a Business Requirements Document
You use a BRD at the very beginning of an IT project or system integration. It helps:
Align stakeholders on the problem we’re solving
Define what “done” looks like
Prevent scope creep or missed expectations later
Without a BRD: You’ll waste hours in meetings asking, “Wait, why are we even doing this?”
Who Owns the BRD?
Usually:
A business analyst or project manager drafts it
A business stakeholder reviews and signs off
A tech lead might add system context
This is a collaborative doc, not something created in a vacuum.
What’s In a Biz Requirements Doc (And What’s Not)
✅ In a BRD
Project summary and goals
Problem/opportunity
Business rules and constraints
Scope: what’s in / what’s out
Key stakeholders and systems
Success criteria
❌NOT In a BRD
Field-level mappings
Wireframes
API endpoints
(Those go into specs later.)
How to Get Started Writing a BRD
Ask the right questions:
What are we trying to fix?
Who’s involved?
What existing processes will be impacted or changed?
What systems are involved?
What happens if we don’t fix this?
Start with a simple structure:
Overview / Executive Summary – Provide a high-level summary of the business need and the integration goal.]
Business Objective – What is the primary outcome the business wants to achieve?
Scope – Define what is in scope and out of scope for this project.
Stakeholders & Systems – List the key people and systems involved.
Requirements & Constraints – List key rules, limitations, and must-haves.
Success Criteria – How will the business know this project was successful?
Assumptions & Dependencies – List any assumptions or conditions that must be true.
Talk to both business and tech people.
This is a translation doc.
Real Example: Syncing OpenBoxes and ShipStation at a 3PL
In our client’s case, the BRD helped align everyone around one core goal:
“Outbound orders in OpenBoxes should be automatically sent to ShipStation to create a shipment, reduce delays, and remove manual entry.”
We documented the systems, constraints (e.g. only domestic orders in Phase 1), and success criteria (e.g. 100% order visibility in ShipStation within 2 minutes of WMS approval).
Download the Example + Template Business Requirement Document
- Download our Real BRD Example – OpenBoxes to ShipStation (.docx)
- Download the Blank BRD Template (.docx)
Wrap Up: BRD First, Then Code
If you start with code before a BRD, you’re probably building the wrong thing. A good BRD is fast to create and saves you hours — even weeks — of headaches later.
Next in the series: We’ll show you how to write a Functional Specification that bridges your BRD to real-world dev tickets and data mapping.