What to Put in a Requirements Document Your Vendor Can Build From

A requirements document is the brief a vendor uses to estimate, design, and build your product. When it is vague, the vendor fills the gaps with guesses. Those guesses show up later as change orders, missed dates, and features that pass review but miss what customers need.

We scope requirements for implementation by a company's own team, an outside vendor, or a third-party platform. This guide covers what to include, how to write testable stories, what to hand over, and the gaps that cause rework.

Why the requirements document matters

In a 2014 Pulse of the Profession report, PMI found that 47 percent of unsuccessful projects failed to meet their goals because of inaccurate requirements management. The fix is clarity: tie each requirement to a business goal and to a test the vendor can run.

What goes in a business requirements document

A business requirements document (BRD) explains why the work exists and what success looks like. Keep it short. Five sections cover most projects. The examples below use a hypothetical home services company adding online rescheduling for customers.

Give every metric a baseline, a target, and a data source. Turn a goal like "Reduce calls" into something testable, such as "Cut reschedule calls in half within 90 days of launch, measured in the phone system."

How to write user stories with acceptance criteria

A user story names who needs something, what they need, and why. For example: "As a customer, I want to move my appointment online so that I don't have to call during work hours."

The story is a placeholder for a conversation. The acceptance criteria define when it is done. The Given/When/Then format, developed by Dan North and Chris Matts, writes each criterion as a scenario: the starting context, the action, and the expected result.

Three habits make acceptance criteria useful:

• One scenario per business rule. Each rule becomes something a tester can check.

• Include the unhappy paths. Late changes, no open slots, and a scheduling system that is down all need an expected result.

• Describe behavior. Say what the user sees and what the system does. Leave the technical design to the vendor.

Non-functional requirements people forget

Some requirements apply to the whole product. Nobody asks for them in a workshop, so they get left out, and the vendor prices them later as extras. Write these down up front:

• Accessibility. Name a standard, such as WCAG 2.2 Level AA, and say how it will be tested.

• Analytics. List the events to track so you can measure the success metrics in your BRD.

• Performance. Set page load and response time targets.

• Security and privacy. Note login rules, data retention, and any regulations that apply.

• Admin and support tools. Your staff will need to look up and fix records.

How to prioritize requirements

Without a rank, every request looks urgent, and the budget runs out before the most important work is done.

We use MoSCoW: Must have, Should have, Could have, and Won't have this time. The DSDM guidance from the Agile Business Consortium recommends that Must Haves take no more than 60 percent of the effort, with about 20 percent in Could Haves as a buffer. That leaves room when estimates slip.

Two rules keep the ranking honest. Each Must Have should trace back to a goal or metric in the BRD. And the Won't Have list should be signed off, because it is your best defense against scope creep.

What to hand over alongside the requirements document

A document alone leaves too much open to interpretation. Send these with it:

• A clickable prototype or wireframes. They show the flow and layout faster than paragraphs can.

• Research evidence. Interview findings, usability test results, and the data behind each goal. A clear research readout gives the vendor the why behind each decision.

• A ranked backlog. Stories in the vendor's tool, such as Jira or a shared board, with acceptance criteria attached.

• Named decision owners. One person per area who can answer questions within a day.

If the idea itself has not been tested with customers yet, do that before you write requirements. Our guide to validating a product idea shows how.

Before a story goes to the vendor, check it against a short definition of ready:

• It ties to a goal or metric.

• It has acceptance criteria, including unhappy paths.

• Designs or a prototype are attached.

• Dependencies and integrations are named.

• Open questions are answered.

• The vendor has sized it.

Common gaps that cause vendor rework

Frequently asked questions

What is the difference between a BRD and a functional specification?

A BRD explains the business need, goals, scope, and success metrics. A functional specification or set of user stories describes how the system behaves. Many teams keep a short BRD and put the functional detail in the backlog.

How long should a requirements document be?

Long enough for a vendor to estimate with confidence. For most features, a few pages of business requirements plus a ranked backlog of stories is enough.

Who should write the requirements document?

A product owner or business analyst usually writes it. The people who will use the product, the team that will support it, and the vendor's technical lead should all review it.

Do I need a BRD template?

A template helps you remember the sections. Start with goals, scope, success metrics, users, and constraints, and adapt from there.

Should acceptance criteria always use Given/When/Then?

Use it for behavior with rules and edge cases. Simple items, such as a label change, can use a short checklist.

Turn your research into requirements a vendor can build

Our Innovation Retainer gives your team ongoing research and product support, including requirements scoped for your own developers, a vendor, or a third-party platform. We connect each requirement to customer evidence so the build starts with fewer open questions. Read how the Innovation Retainer compares to hiring in-house, see how it works, or start a conversation.

Sources

• Project Management Institute, "Requirements Management: A Core Competency for Project and Program Success," Pulse of the Profession, 2014

• Dan North, "Introducing BDD," dannorth.net, 2006

• Agile Business Consortium, "MoSCoW Prioritisation," DSDM Project Framework, undated web edition

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," W3C Recommendation, 2024