logo for information-management-architect.com
leftimage for information-management-architect.com

Requirements Specification

Improve requirements gathering process with David Bowman’s information management guidelines for data warehouse requirements specification

This site is designed for Information Technology professionals who need to improve efficiency and require guidance and direction to help teams consistently produce error free results.

It provides a checklist of information management guidelines for requirements analysis and a template that can help jump-start a project.

What are Data Warehouse Requirements?


A data warehouse requirements specification states the project objectives and goals and related data storage, data integration, information delivery, security, quality, usage, functional and non-functional requirements that must be delivered in order to achieve the project objectives.

The requirements specification provides a means of specifying all requirements and the criteria that will be used to accept that the requirements have been met.

It helps ensure that the technical team does not design and build something that is not specified.

Objectives and Scope
  • Should document any assumptions that will impact the requirements;
  • Should identify any dependencies that will impact solution delivery;
  • Should identify any systems that will be impacted by the solution; and
  • Should define how requirements will be evaluated e.g all requirements should be uniquely identified, all requirements should have a status value (proposed, defective, rejected, deferred, or approved), all requirements should be evaluated using the requirements quality criteria (unambiguous, correctness, completeness, consistency, feasibility, testability, relevance, atomic, classification, traceability, and defects have been captured; and all defective requirements should have been fixed or the risks associated with the defective requirements not being fixed have been documented and accepted.
Data Requirements
Conceptual Data Model
  • Should provide an appreciation for the overall scope of data storage requirements;
  • Should include definitions of each conceptual entity;
  • Should confirm understanding of the project data storage scope;
  • Should be a sub-set of the enterprise conceptual data model;
  • Should involve data modeling sessions with selected stakeholders;
  • Should involve feed-back sessions to introduce the conceptual data model; and
  • Should be approved before commencing logical data modeling.
Logical Data Model
  • Should finalize structure and design requirements;
  • Should involve data modeling sessions with selected stakeholders;
  • Should document entity definitions;
  • Should document entity attributes;
  • Should document storage volumetric requirements;
  • Should list any known issues with the logical data model;
  • Should be the subject of an internal team review; and
  • Should be approved before finalizing requirements specification.
Backup and Recovery
  • Should define backup and recovery requirements to achieve service level agreements in the event of operational, non-catastrophic, failure;
  • Should involve facilitating working sessions with selected stakeholders to discuss backup/recovery requirements;
  • Should be the subject of an internal team review; and
  • Should be approved before finalizing requirements specification.
Disaster Recovery
  • Should define backup and recovery requirements to achieve service level agreements in the event of operational, non-catastrophic, failure;
  • Should involve facilitating working sessions with selected stakeholders to discuss backup/recovery requirements;
  • Should be the subject of an internal team review; and
  • Should be approved before finalizing requirements specification.
Data Integration Requirements

Conceptual Data Movement Diagram
  • Should provide definitions of each key system or data source that is required;
  • Should confirm understanding of the data integration scope;
  • Should be a sub-set of the enterprise conceptual data movement diagram;
  • Should involve working sessions with selected stakeholders;
  • Should involve feed-back sessions to introduce the conceptual data movement digram; and
  • Should be approved before commencing logical data movement diagrams.
Logical Data Movement Diagram
  • Should show all existing and new interfaces that will be required to satisfy requirements;
  • Should show the flow of data into, between, and out of all applications impacted by the project;
  • Should assign each system a system id;
  • Should assign each interface (existing and new) an interface id for requirements traceability;
  • Should involve working sessions with selected stakeholders;
  • Should involve feed-back sessions to introduce the conceptual data movement digram;
  • Should be the subject of an internal team review; and
  • Should be approved before commencing logical data movement diagrams.
Source System Definitions
  • Should provide a definition of each source system that will be required by the project;
  • Should provide a definition of each interface that will be required by the project;
  • Should involve a feed-back session with selected stakeholders to introduce the source system documentation;
  • Should be the subject of an internal team review; and
  • Should be approved before finalizing requirements specification.
Data Migration or Conversion
  • Should identify all data migration and or data conversion requirements to help plan the architecture and design;
  • Should involve facilitating working sessions with selected stakeholders to elicit data conversion requirements;
  • Should document data conversion requirements;
  • Should be the subject of an internal team review; and
  • Should be approved before finalizing requirements specification
Business Rules Requirements (Source To Target Mapping)
  • Should provide 1st pass logical source to target map to ensure that all required source data is included in the logical data model;
  • Should involve reviewing source system data models and/or table/file definitions;
  • Should map source columns to the logical data model;
  • Should document any key business rules and/or data transformation rules;
  • Should be the subject of an internal team review;
  • Should involve feed-back sessions with selected stakeholders to introduce the source to target mapping document; and
  • Should be approved before finalizing requirements specification.
Data Quality Analysis
  • Should create a data profile for each data source so as to gain an understanding of the quality of source data to help the architecture an design team finalize detail specifications;
  • Should utilize a data profiling tool to analyze each source system table;
  • Should document data profile results in a project documentation repository;
  • Should be the subject of an internal team review;
  • Should involve feed-back session with selected stakeholders to introduce the data profile results; and
  • Should be approved before finalizing requirements specification.
Change Data Movement
  • Should identify change data movement requirements in terms of how the client wants to report changes;
  • Should involve working sessions with selected stakeholders to elicit change data movement requirements;
  • Should document change data movement requirements;
  • Should be the subject of an internal team review;
  • Should involve feed-back session with selected stakeholders to introduce the requirements; and
  • Should be approved before finalizing requirements specifications.
Information Delivery Requirements

High Level Dimensional Model
  • Should define facts and dimensions required for reporting/analytic purposes;
  • Should specify facts, dimensions and volumetric information;
  • Should specify a fact/dimension matrix;
  • Should specify measures;
  • Should document facts, dimensions and measures;
  • Should deliver a 1st draft Dimensional Model (Usually not in a data modeling tool); and
  • Should be approved before finalizing requirements specifications.
Reporting Requirements
  • Should define any ad-hoc query profiles that may not already covered by the dimension model;
  • Should identify report conversion requirements and might involve analyzing a large list of existing reports to determine which reports should be converted or it might involve discussions with selected client stakeholders to identify classes or types of reports to convert;
  • Should identify any audit reporting requirements; and
  • Should identify any reconciliation reporting requirements.
Data Security Requirements

Should identify security requirements for data movement, data access and for test data.

Data Quality Requirements

Should identify all data quality reporting requirements. 

Metadata Requirements
  • Should define data warehouse metadata requirements; and
  • Should define metadata repository requirements.
Functional Requirements
  • Should define business requirements in terms of the functionality required from the Business Intelligence solution; and
  • Should define what is expected from the business intelligence tool.
System Requirements

Should define all system or non-functional requirements required to ensure successful implementation of the solution. 

Requirements Acceptance
  • Should commence the requirements traceability process; and
  • Should confirm project acceptance criteria.
Requirements Specification Template

Under Construction  

Summary...

An information management project is concerned with getting the right information, in the right hands, at the right time to make the right decision.

A data warehouse requirements specification states the project objectives and goals and related data storage, data integration, information delivery, security, quality, usage, functional and non-functional requirements that must be delivered in order to achieve the project objectives.

This site provided a checklist of information management guidelines for requirements analysis and a template that can help jump-start a project.