# 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*.

<!--
Guidance: How to use this template
- Start from the business questions and processes the data must serve,
  then define entities. Data defined without a use is rarely maintained.
- Name an owner (accountable business role) and a steward (day-to-day
  custodian) for every entity. Unowned data degrades.
- Give every quality requirement a number and a measurement method.
- This document states requirements; the physical schema belongs in the
  database design document. Privacy content here is a format, not legal
  advice: confirm lawful basis and retention with your privacy officer.
-->

| 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

<!-- Guidance: Which system, which data domains, which processes. State what is out of scope (for example analytics copies owned by another team). -->

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

<!-- Guidance: One row per entity, defined in business language. A definition says what one record represents, not how it is stored. -->

| 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.

```mermaid
erDiagram
  CUSTOMER ||--o{ ORDER : places
  ORDER ||--|{ ORDER_LINE : contains
  PRODUCT ||--o{ ORDER_LINE : "appears in"
  CUSTOMER ||--o{ ADDRESS : has
  ORDER }o--|| ADDRESS : "ships to"
  CUSTOMER {
    string customer_id PK
    string email
    string country_code
  }
  ORDER {
    string order_id PK
    string customer_id FK
    datetime placed_at
    string status
  }
```

## 3. Data dictionary

<!-- Guidance: One row per attribute that the system must hold. Classification drives security and retention. Keep the format column precise: patterns, units, code lists. -->

| 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

<!-- Guidance: Each dimension gets a measurable rule, a target and how it is measured. Agree what happens when the target is missed. -->

| 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

<!-- Guidance: Retention periods come from legal, contractual and business needs; cite the source. Say what happens at the end: delete, anonymise or archive. -->

| 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

<!-- Guidance: List personal data categories, why they are processed and on what basis. This is a format, not legal advice; confirm with your privacy officer and DPIA. -->

| 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

<!-- Guidance: Where each entity comes from and where it goes. Lineage lets you find the cause of a quality problem and the impact of a change. -->

| 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

<!-- Guidance: Data exchanged with other systems: format, frequency, volume, and data-level rules. Protocol detail belongs in the interface specification. -->

| 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

<!-- Guidance: If data moves from a legacy system, define scope, mapping, cleansing, reconciliation and cut-over. Migration failures are a top cause of failed go-lives. -->

| 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.