Chapter 01 · From Requirements to Data Models
Turning Business Language into Data Requirements
Convert interviews, policies, reports, and workflow language into precise data requirements without jumping prematurely to tables.
Learning outcomes
Requirements for data rarely arrive as a clean list of tables and keys. They arrive as interviews, policy documents, spreadsheets, screen mockups, reports, API payloads, and sentences such as “we need to know who worked on each job.” This lesson teaches you to translate that language into explicit data requirements before implementation begins.
Distinguish business goals, functional behavior, and data requirements.
Extract candidate entities, attributes, relationships, events, and constraints from prose.
Rewrite vague statements as testable modeling questions.
Create a requirements matrix for the WorkshopHub case study.
Do not ask stakeholders for tables
A domain expert knows the business but may not know normalization, foreign keys, or transaction isolation. Asking “What tables do you want?” pushes an implementation decision onto the wrong person. Ask instead about facts, policies, workflows, identity, history, exceptions, and reports.
Replace “What columns belong in the work-order table?” with “When a work order is created, what must we know immediately, what may become known later, and what information must remain historically true even if other records change?”
Three layers of requirements
| Layer | Example | Modeling impact |
|---|---|---|
| Business goal | Reduce repair turnaround time. | May require timestamps and status history so duration can be measured. |
| Functional behavior | A dispatcher assigns technicians. | Requires a representation of assignments and possibly reassignment history. |
| Data requirement | Keep who was assigned, when, and in what role. | Suggests an assignment entity with foreign keys and effective timestamps. |
The same business goal can lead to different data requirements depending on how the organization measures success. A data modeler keeps asking until the required facts are concrete.
Extract nouns, verbs, qualifiers, and time words
Consider this WorkshopHub requirement:
“A customer may register multiple assets. Each asset has a manufacturer serial number. When a repair request is accepted, a work order is opened. One or more technicians can be assigned over the lifetime of the order. Dispatchers need to know the current technician, but managers must also report every previous assignment.”
Four types of clues appear:
- Nouns suggest candidate concepts: customer, asset, work order, technician, dispatcher.
- Verbs suggest relationships or events: register, open, assign, report.
- Qualifiers express cardinality and optionality: multiple, each, one or more.
- Time words reveal history requirements: current, over the lifetime, previous.
The phrase “current technician” alone might tempt us to add technician_id to work_order. The requirement for every previous assignment changes the design: assignments have their own history and likely deserve their own entity.
Turn vague language into modeling questions
Ambiguity is normal. The modeler's job is not to guess silently; it is to convert ambiguity into questions whose answers affect the schema.
| Vague statement | Useful questions |
|---|---|
| “Customers have addresses.” | One or many? Billing and service addresses? Do we need history? Can two customers share an address? |
| “Technicians use parts.” | Are parts consumed per work order, per task, or per technician? Must quantity and unit cost be preserved historically? |
| “Every asset has a serial number.” | Unique globally or only within manufacturer? Can serial number be corrected? |
| “Orders can be cancelled.” | Before work begins only? Must reason, actor, and cancellation time be stored? |
Use examples and counterexamples
Abstract rules become clearer when you ask for concrete examples. If a stakeholder says “an asset belongs to one customer,” ask about leased equipment, transferred ownership, or corporate fleets. If they say “one technician handles an order,” ask what happens during shift changes or specialist review.
Counterexamples are especially valuable because they discover hidden cardinalities and history requirements before the schema hardens.
For every word such as always, never, one, unique, or required, ask for the exceptional case. If the exception is valid business behavior, the model must represent it.
Build a data requirements matrix
A simple matrix keeps discovery traceable. Each row ties a source statement to the facts and rules it implies.
| ID | Requirement | Candidate facts | Open question |
|---|---|---|---|
| R-01 | Customers register assets. | Customer identity, asset identity, ownership/registration relationship. | Can ownership change? |
| R-02 | Serial numbers identify assets. | Manufacturer, serial number. | Global or manufacturer-scoped uniqueness? |
| R-03 | Orders may have several technician assignments over time. | Work order, technician, assigned_at, unassigned_at, role. | Can assignments overlap? |
| R-04 | Managers report turnaround time. | opened_at, completed_at. | Does paused time count? |
Requirements are not screen fields
User interfaces change more quickly than domain rules. A form may show “Customer name” inside a work-order screen, but that does not mean customer name belongs as a duplicated column in every work-order row. The UI is one view over the model.
Screen field: Customer nameModel meaning: WorkOrder -> Asset -> Customer -> full_nameScreen field: Current technicianModel meaning: latest active WorkOrderAssignment for this work orderThis distinction prevents a common design failure: copying the screen layout directly into the database.
Practice: rewrite requirements
Workshop
Rewrite each statement as at least two precise data questions.
- “Parts have prices.”
- “Customers can cancel.”
- “We need technician performance reports.”
- “Assets have owners.”
Review sample questions
For parts: Is price current-only or historical? Is it purchase cost, list price, charged price, or all three? For cancellation: which object is cancelled, who may cancel it, at what states, and must reason/time be recorded? For performance: what measures define performance and which timestamps/facts are needed? For ownership: one owner at a time or many, and must transfers be preserved?
Summary and next lesson
Good schemas come from precise requirements, not from guessing tables. Extract candidate concepts and relationships from prose, then challenge cardinality, uniqueness, optionality, time, exceptions, and history. The next lesson organizes these discoveries into facts, business rules, explicit scope, and recorded assumptions.
References
- Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.
- Martin Fowler, Analysis Patterns.
- Eric Evans, Domain-Driven Design, for domain language and bounded context concepts.
- C. J. Date, Database Design and Relational Theory.