How to write a data requirement specification (with template)

The data requirement specification is the most under-rated document in data sourcing, and the highest-leverage. A precise spec turns a vague wish into something that can be sourced, priced and delivered accurately. This guide shows how to write one, with a template.

Why the spec is the highest-leverage step

Everything downstream, availability assessment, pricing, delivery, depends on the requirement. A vague spec produces vague, expensive results; a precise one makes the whole process faster and more accurate.

Start from the decision

Write the requirement backwards from the decision the data must support. If you cannot state the decision and how the data informs it, the spec is not ready. This single discipline avoids most wasted effort.

The template: what to capture

• Outcome: the decision or use the data supports.
• Data type and fields: the specific variables needed.
• Geography and granularity: coverage and resolution.
• Historical depth and volume.
• Refresh frequency and cadence.
• Structure and format, and delivery interface.
• Quality thresholds and acceptance criteria.
• Privacy and anonymisation constraints.
• Deadline, including any tender date.

Common mistakes

The usual failures are specifying the source instead of the need, omitting quality and acceptance criteria, leaving cadence undefined, and ignoring privacy until late. Each causes rework or dispute.

Make it testable

A good spec is measurable: quality and acceptance criteria should be objective enough to test on delivery. That is what turns a requirement into an enforceable agreement.

How a partner uses the spec

With a precise spec, a managed supply partner can assess availability, identify routes, price accurately and define delivery, often returning options quickly. The spec is the contract between what you need and what you get.

A worked requirement example

Suppose the goal is to forecast regional product demand. A weak requirement says “we need sales and weather data”. A strong one specifies: weekly sales by postal district for three years; daily temperature and rainfall for the same districts and period; a defined delivery format (Parquet) and interface (scheduled SFTP); completeness above 98% with flagged estimates; and no personal data. That precision is what lets a supplier assess availability, price accurately and deliver something testable, the difference between weeks of back-and-forth and a clean engagement.

Make every criterion testable

The discipline that separates a usable spec from a wish list is testability: every quality and acceptance criterion should be objectively checkable on delivery. “High quality” is not testable; “completeness above 98%, freshness within 24 hours, zero schema violations” is. A spec written this way doubles as the acceptance contract, so what you asked for and what you accept are the same thing.

Sources & further reading

• DAMA-DMBOK: requirements and data specification.
• ISO/IEC 25012: data quality dimensions for acceptance criteria.
• European Commission: data spaces requirements guidance.
• Internal practice: DataSupplier requirement framework.