Document Data Requirements¶
(Activity) for Tier: Data Management
PURPOSE¶
Clearly defining Data Requirements helps to establish a repeatable process which ensures that business objectives are satisfied, prioritized, and validated. A well-documented process helps to achieve business objectives regardless of the use of a database, data lake, data warehouse, etc. This process also helps all relevant stakeholders and existing business processes that create and/or use the data.
WHEN¶
During the requirements gathering and release planning phases when data is involved in any of the following:
- Storing data in any datastore
- Updating data in the datastore
PARTICIPATING ROLES¶
- ACCOUNTABLE
- RESPONSIBLE
INPUTS¶
- Data Source with data set
ENTRY CRITERIA¶
- The accountable party(ies) have a full understanding of the requirements and how it should fit into the current architecture of the existing system or data store.
SUB-ACTIVITIES¶
Gather Requirements
- Using the agreed to data source collaborate and reach an agreement on requirements.
- Document an initial list of data requirements.
Note
It is recommended that the business analyst also has a clear understanding of related data management activities to assist with such as, but not limited to:
- Develop Data Catalog
- Conduct Data Profiling
- Data Quality Assessment
- Data Cleansing
Define Business Rules
- Based on the agreed to set of data requirements define business terms and business rules. Business rules for system behavior should be developed in parallel with the logical design of the destination system’s data store. This methodology is bi-directional and iterative.
Elaborate Data Requirements
Document each requirement in desired format and specify within your team procedure.
The following elements are examples of content captured:
- Business term: The data element name in business English. (e.g., Street Address)
- Term definition: The approved definition of the business term. (e.g., Street Address: the street address a person lives at)
- Originating business process or Data Source: The process that creates the data. (e.g., MilPDS)
- Modifying business process(es): The process or processes through which the data can be modified. (e.g., IMR)
- Logical name: The business term transformed to the organization’s data design standards. (e.g., Street Address 1 Text, Street Address 2 Text)
- Allowed values: The codes, minimum/maximum ranges, etc. which are acceptable. (e.g., M, F, U)
- Values format: How the values are represented. (e.g., MMDDYYYY, 999-99-9999 (SSN), 2x (state code), 9-999-999-9999 (phone number))
- Physical name: The name of the term developed for the physical database in which it is or will be stored, applying physical data standards. (e.g., ST_ADDR_1_TX)
- Quality rule(s): The automated test or tests that will be applied to the data element upon entry. (e.g., First Name must contain more than one character, First Name must contain a single word)
OUTPUTS¶
Exit Criteria¶
- Data Requirements have been captured with all necessary elements.