Data Requirements Specification Template

Entities, data dictionary, quality targets, retention, privacy basis, lineage, data interfaces, migration, ERD

Вимоги та аналізСтандартdata mathОновлено 20 жовт. 2026 р.

Як використовувати: Use it when a system's data must be defined, owned and governed before design or migration. List entities with owners and the business questions first. The main pitfall is quality requirements with no measurable target or measurement method.

Перегляд

Data Requirements Specification: [System or data product name]

Data requirements specification describing the data a system must capture, hold, exchange and dispose of: entities, a data dictionary, quality targets, retention, privacy classification, lineage, interfaces and migration. Based on common industry practice in data management and business analysis. Replace every [bracketed] value and every row marked Example.

Field	Value
Document ID	[DRS-SYSTEM-001]
System / data product	[Name] [release]
Version	[0.1]
Status	[Draft / In review / Approved]
Owner	[@data-owner]
Data steward	[@data-steward]
Privacy reviewer	[@privacy-officer]
Last updated	YYYY-MM-DD
Related documents	[SRS], [Database design], [DPIA], [Data dictionary]

1. Purpose and scope

This specification defines the data requirements for [System name]. It covers the data domains [customer, orders, products] used by the processes [order capture, fulfilment, invoicing]. Out of scope: [data warehouse models, which are specified in DRS-DW-xxx].

Business questions the data must answer:

Example: How many orders were placed per channel per day?
Example: Which customers have open orders older than 5 days?
[Question]

2. Data entities and definitions

Entity	Definition (one record represents)	Owner	Steward	Volume	Growth
Example: Customer	A person or organisation that has placed or may place an order	Head of Sales	CRM team	1.2 M	8% / year
Example: Order	A confirmed request from one customer to buy one or more products	Head of Operations	Order team	4 M / year	15% / year
Example: Order line	One product and quantity within an order	Head of Operations	Order team	11 M / year	15% / year
Example: Product	An item offered for sale, at SKU level	Head of Merchandising	Catalogue team	40,000	5% / year
[Entity]	[Definition]	[Role]	[Team]	[n]	[Rate]

The entity relationships are shown below.

3. Data dictionary

Entity	Field	Type	Length	Format / allowed values	Mandatory	Validation	Source	Owner	Classification
Customer	customer_id	String	12	`C` + 11 digits	Yes	Unique; system generated	System	Sales	Internal
Customer	email	String	254	RFC 5322 address	Yes	Syntax check; verified by link	Customer	Sales	Personal
Customer	date_of_birth	Date	10	YYYY-MM-DD	No	Age 16 to 120	Customer	Sales	Personal
Customer	country_code	String	2	ISO 3166-1 alpha-2	Yes	In code list	Customer	Sales	Internal
Order	order_id	String	14	`ORD-` + 10 digits	Yes	Unique	System	Operations	Internal
Order	placed_at	Timestamp	n/a	ISO 8601, UTC	Yes	Not in future	System	Operations	Internal
Order	status	Enum	20	Placed, Paid, Shipped, Delivered, Cancelled	Yes	Valid transition only	System	Operations	Internal
Order line	quantity	Integer	n/a	1 to 999	Yes	Positive integer	Customer	Operations	Internal
Order line	unit_price	Decimal	12,2	Currency of order	Yes	At or above 0	Catalogue	Merchandising	Internal
[Entity]	[field]	[Type]	[n]	[Format]	[Yes / No]	[Rule]	[Source]	[Owner]	[Public / Internal / Personal / Sensitive personal / Confidential]

4. Data quality requirements

ID	Dimension	Rule	Target	Measurement	Frequency	Action when breached
DQ-01	Accuracy	Customer postal address matches the postal reference file	98%	Address validation report	Weekly	Steward reviews failures
DQ-02	Completeness	Mandatory fields populated on Order	100%	Null count query	Daily	Block load; alert team
DQ-03	Completeness	Customer phone number present	85%	Null ratio	Monthly	Prompt at next login
DQ-04	Timeliness	Order visible in reporting after placement	Within 15 min for 99%	Lag metric	Continuous	Incident if over 1 h
DQ-05	Consistency	Order total equals sum of lines plus tax and shipping	100%	Reconciliation job	Daily	Quarantine record
DQ-06	Uniqueness	No duplicate customers by verified email	99.5%	Duplicate match report	Monthly	Merge process
DQ-07	Validity	country_code in ISO list	100%	Constraint check	On write	Reject write
[DQ-nn]	[Dimension]	[Rule]	[Target]	[Method]	[Frequency]	[Action]

Completeness for a field is measured as:

\text{Completeness} = \frac{\text{records with a valid non-empty value}}{\text{total records in scope}} \times 100\%

5. Retention and archival

Entity / data set	Active retention	Archive	End-of-life action	Basis
Example: Order and order line	2 years online	Years 3 to 7 in archive storage	Delete after 7 years	Tax record-keeping rules
Example: Customer (inactive)	3 years after last activity	None	Anonymise	Privacy policy
Example: Application logs with IP address	90 days	None	Delete	Security policy
[Data set]	[Period]	[Archive]	[Action]	[Source]

Deletion must cover backups within [35] days of the end-of-life date.

6. Privacy classification and lawful basis

Data category	Fields	Purpose	Lawful basis	Special category	Access roles
Example: Contact data	email, phone	Order communication	Performance of contract	No	Support, Operations
Example: Date of birth	date_of_birth	Age-restricted products	Legal obligation	No	Compliance only
Example: Marketing preferences	opt_in flags	Newsletters	Consent	No	Marketing
[Category]	[Fields]	[Purpose]	[Basis]	[Yes / No]	[Roles]

Data subject rights to support: access, rectification, erasure, restriction, portability and objection, each fulfilled within [30] days.

7. Data lineage and sources

Entity	System of record	Upstream source	Downstream consumers	Refresh
Example: Customer	CRM	Web sign-up, store sign-up	Order system, data warehouse, email platform	Real time
Example: Product	PIM	Supplier feeds	Web shop, order system	Hourly
Example: Order	Order system	Web shop, call centre	ERP, data warehouse	Real time
[Entity]	[System]	[Source]	[Consumers]	[Frequency]

8. Data interfaces

ID	Interface	Direction	Entities	Format	Frequency / volume	Error handling
DI-01	Example: Orders to ERP	Out	Order, order line	JSON events	Real time, 15,000 / day	Retry 5 times; dead-letter queue
DI-02	Example: Product feed from PIM	In	Product	CSV over SFTP	Hourly, 40,000 rows	Reject file if over 1% invalid rows
[DI-nn]	[Interface]	[In / Out]	[Entities]	[Format]	[Frequency]	[Handling]

9. Data migration requirements

ID	Requirement	Acceptance
MIG-01	Example: Migrate all customers active in the last 3 years from the legacy CRM.	Record counts reconcile within 0.1% with documented exclusions
MIG-02	Example: Map legacy status codes to the new status list using mapping table MAP-03.	100% of codes mapped; no defaults used
MIG-03	Example: Remove duplicates before load using the matching rules in DQ-06.	Duplicate rate under 0.5% after load
MIG-04	Example: Run two full trial migrations before cut-over.	Both trials pass reconciliation
MIG-05	Example: Keep the legacy system read-only for 90 days after cut-over.	Read access confirmed
[MIG-nn]	[Requirement]	[Acceptance]

10. Open issues and revision history

ID	Issue	Owner	Due	Status
OI-01	Example: Confirm retention period for call recordings linked to orders	[@privacy-officer]	YYYY-MM-DD	Open
[OI-nn]	[Issue]	[@name]	YYYY-MM-DD	[Status]

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Initial draft
[x.y]	YYYY-MM-DD	[@name]	[Change]

Standard and licence note

Based on common industry practice for data requirements specification in data management and business analysis. Original text written for this collection; examples are illustrative, and privacy content is a format, not legal advice. Template licence: MIT.

Схожі шаблони

Вимоги та аналіз