Business Information Fields
Business Information is intentionally lightweight — the goal is to capture the information landscape at a business level, not to produce a detailed data specification. Four fields cover the essential facts.
1. Description
-
What it’s for: A plain-language explanation of what this information is and how the business uses it.
-
What to include:
- Describe the information in business terms — what it represents, who uses it, and what decisions or processes it supports.
- Do not describe the technical storage — focus on the business meaning.
- Keep it accessible: a business stakeholder should be able to read this and immediately understand what it is.
-
Example:
"A customer record contains the details the business holds about each registered customer, including contact information, account status, and order history. Used by sales, customer service, and billing teams."
2. Information Quantity
-
What it’s for: An approximate count of how many items of this information the solution must support.
-
What to include:
- Provide a realistic estimate of the total volume — how many customer records, how many orders per day, how many products in the catalogue.
- This figure is used as an input to data storage sizing, performance modelling, and migration planning.
- If the volume varies significantly (e.g., seasonal spikes), note the peak figure.
- An order of magnitude estimate is fine — the goal is to surface volume, not produce a precise count.
-
Examples:
50,000(total customer records);2,000 per day(order volume)
3. Information Format
-
What it’s for: The current or expected medium or format in which this information exists.
-
What to include:
- Describe how this information is currently held or how it will be provided to the solution.
- Common values: Excel, Word, PDF, Email, database table, paper form, verbal/undocumented, SharePoint, legacy system, API feed.
- This field is particularly valuable for surfacing migration, transformation, or digitisation work — for example, if information currently exists only as a Word document or on paper, the solution may need to provide a structured capture mechanism.
-
Example:
Excel spreadsheet (currently maintained manually by the Finance team)
4. Information Attributes
-
What it’s for: A list of the key attributes that describe this information, from a business perspective.
-
What to include:
- List the main data points that make up this information — the fields a business user would expect to see.
- Keep it at a business level: Name, Email, Status, Order Date, Total Value — not database column names or technical field identifiers.
- This is not a detailed data specification. The goal is to capture enough to confirm scope and enable mapping to Data Set fields later in the design process.
- Focus on the most meaningful attributes; there is no need to list every possible field exhaustively.
-
Example attributes for a Customer Record:
Name,Email Address,Phone Number,Account Status,Registration Date,Assigned Account Manager
Relationships
| Relationship | What to link |
|---|---|
| Contains Business Information | Child information items that form part of this information (e.g., “Customer Record” contains “Customer Address”) |
| Supports Business Requirement | Business requirements that this information is needed to fulfil |
| Has Acceptance Criteria | Acceptance criteria related to how this information must be captured or maintained |
| Has Risk | Risks associated with this information — data quality, availability, sensitivity |
| Has Assumption | Assumptions being made about this information (volume, format, availability) |
| Has Issue | Known issues with this information (e.g., currently incomplete, held in incompatible format) |
| Has FAQ | Frequently asked questions about this information |
| Has Task | Tasks associated with defining, migrating, or governing this information |
| Implements Business Reference | Reference standards, policies, or governance documents that apply to this information |