DATA REQUIREMENT DOCUMENT Author Christina Lee Status Final Revision Version 1.0 Creation Date 01/01/2009 Last Updated 01/01/2009
Table of Contents IT Project Writing Sample 1. Introduction 3 1.1 Summary 3 1.2 Project References 3 2. Assumptions and Dependencies 3 2.1 Project Inventory File Assumptions 3 2.2 Inventory File Dependencies 3 2.3 Event Date File Assumptions 3 2.4 Event Date File Dependencies 4 3. Data Processing Rules 4 3.1 Inventory File Import 4 3.1.1 Load Sunday Inventory File Only 4 3.2 Event Date File Import 4 3.2.1 Import Event Date from Event Date File 4 4. Data Requirements 5 4.1 Inventory File 5 4.1.1 Data Frequency and Transfer Method 5 4.1.2 Data Import Rule 5 4.1.3 Data Mapping Information 5 4.2 New Data Stream Event Date File 6 4.2.1 Data Frequency and Transfer Method 6 4.2.2 Data Mapping Information 6 4.2.3 Event Date Import Rule 6 5. Exception and Escalation Procedure 7 5.1 Inventory File Not Received 7 5.2 Event Date File Not Received 7 5.3 Modified File Received 7 5.4 Contact Grid 7 October 26, 2009 Page 2 of 7
1. Introduction 1.1 Summary The purpose of the Data Requirements Document (DRD) is to define all of the data requirements and processing rules necessary in order to complete the Data Foundation phase of The Project. The collection and aggregation of this data is required to deliver business team reporting in areas of Inventory, Product Attributing and Vendor Improvements. The DRD will provide a framework for the Company business and IT teams to deliver solutions for The Project in an ongoing basis. The project process will follow the prime objectives of Project Team efforts as pertains to the swift delivery of value to the retailer. 1.2 Project References Business Requirements Document IT Project SharePoint Site Data Dictionary 2. Assumptions and Dependencies 2.1 Inventory File Assumptions The file will be provided each Monday no later than 7:00 PM local time with a stock date of Sunday. The file will be up to date and accurate at the time it is received. The file will be stable and remain unchanged from submission to submission. In the event that any file is received with a modified data structure, The Company will be unable to process that file. The IT Team will then follow up with the appropriate contact, and assist them in resubmitting a file with the correct data structure. If the file requires a permanent change to structure, those changes will be subject to the standard Company change control process. The IT Team will provide assistance with requesting the change control. If the Sunday Inventory file is not received on the following Monday, processing will continue using the most current data in the staging table, and the escalation contact will be alerted. Use the following contact grid to contact the appropriate IT representative so that they may resolve the discrepancy with the customer. 2.2 Inventory File Dependencies The numeric data for units and value file require recalculation upon receipt in order to provide the correct amounts when processed. 2.3 Event Date File Assumptions The file will be provided by the client to The Company on an ad hoc basis. Initially, the file will be reviewed by Company staff for accuracy and data integrity before being submitted for processing. This will take place until the end of March, 2010, and at that time the procedure will be evaluated to determine if the quality assurance review is still necessary. The file will be stable and remain unchanged from submission to submission. In the event that any file is received with a modified data structure, The Company will be unable to process that file. The IT Team will then follow up with the appropriate contact, and assist them in resubmitting a file with the correct data structure. If the file requires a permanent change to structure, those changes will be subject to the standard Company change control process. The IT Team will provide assistance with requesting the change control. If a new file is unavailable for weekly processing, the most recent Event Date file submitted will October 26, 2009 Page 3 of 7
be an acceptable substitute. In the event that the same Event Date file is used for processing a total of three consecutive cycles, an automated notification will need to be sent to the IT Team requesting a new Event Date file. Weekly processing will continue regardless of the age of the most current file, and no further action will be required. 2.4 Event Date File Dependencies Processing of Event Date file for reporting purposes requires that Company staff will complete the data integrity check before submission. An existing, non-stale-dated version of the Event Date file will need to be imported and available for weekly processing. 3. Data Processing Rules 3.1 Inventory File Import 3.1.1 Load Sunday Inventory File Only Rule is to load the daily Inventory file for Sunday only, and not load the Inventory file received for any other day of the week. 3.2 Event Date File Import 3.2.1 Import Event Date from Event Date File The Event Date file is considered the most accurate source of event date information. When a record in the event date file has a key match with a record in the main item file (DEST_TABLE2), the event date from the event date file will be used to populate a generic date field in the main item table. This date value will then be used to perform Event Days calculations. October 26, 2009 Page 4 of 7
3.2.1.1 Process Flow Join event date file record to DEST_TABLE2 using the Key Matching Key found in DEST_TABLE2? No Do not import event date Yes Use the date value from Column1 to populate COL1 4. Data Requirements 4.1 Inventory File 4.1.1 Data Frequency and Transfer Method The Project Inventory file is submitted to the FTP server 999.99.999.999 on a daily basis. The file is in Unicode text file format with (PIPE) character used as a field separator, zipped to facilitate transfer. The data load schedule documentation can be found in the IT Project SharePoint Site. 4.1.2 Data Import Rule Import the record from the Project Inventory file only if the following criteria is met: o There is a matching record found in the Project Items file, AND o The matching record does not contain The Project Code = 000 or 999. The Project Code can be determined by accessing the Project Items staging table, and concatenating the values from the third, fourth, and fifth columns in the staging table. 4.1.3 Data Mapping Information Import Table / Field Description Rule Destination Table / Field Import_yyyymmmdd.key Key Must match DEST_TABLE.KEY. If no Key match found in DEST_TABLE, insert source DEST_TABLE.KEY October 26, 2009 Page 5 of 7
Import Table / Field Description Rule Destination Table / Field record to EXCEPTION_TABLE Import_yyyymmmdd.col1 Column1 DEST_TABLE.COL1 Import_yyyymmmdd.col2 Column2 DEST_TABLE.COL2 Import_yyyymmmdd.col3 Column3 DEST_TABLE.COL3 Additional data mapping details for this file can be found in the Data Dictionary. 4.2 New Data Stream Event Date File 4.2.1 Data Frequency and Transfer Method The Event Date file will be a tab delimited.txt file, and will be received on the FTP site ftp.company.com with username johndoe and password 12345. The frequency for transmitting this file is expected to be a minimum of once per month. Weekly processing of the Event Date file should occur during standard weekly processing for all data. The most recent version of the Event Date file will need to be on hand in order to complete weekly processing, even if it has already been used during the previous week. Once the same Event Date file has been processed for three consecutive weeks, an ALERT will need to be generated requesting a new Event Date file. 4.2.2 Data Mapping Information Import Table / Field Description Rule Destination Table / Field Import2_yyyymmmdd.key Key Must match DEST_TABLE2.KEY. If no Key match found, go to next record DEST_TABLE2.KEY Import2_yyyymmmdd.col1 Column1 DEST_TABLE2.COL1 Import2_yyyymmmdd.col2 Column2 DEST_TABLE2.COL2 Import2_yyyymmmdd.col3 Column3 DEST_TABLE2.COL3 Additional data mapping details for this file can be found in the Data Dictionary. 4.2.3 Event Date Import Rule The following logic will illustrate how to correctly populate the value in the COL1 column of the DEST_TABLE2 table: 1. Is DEST_TABLE2.COL1 NULL? a. If no Use the value from Import2_yyyymmmdd.col1 for event date b. If yes Update DEST_TABLE2.COL1 with the value from Import2_yyyymmmdd.col2 2. Continue 3. End October 26, 2009 Page 6 of 7
Data Flow Diagram: No Use the value from Import2_yyyymmmd d.col1 for event date Is DEST_TABLE2.COL1 NULL? Yes Update DEST_TABLE2.COL 1 with the value from Import2_yyyymmmd d.col2 5. Exception and Escalation Procedure 5.1 Inventory File Not Received If the Sunday Inventory file is not received on the following Monday, processing will continue using the most current data in the staging table, and the escalation contact will be alerted. Use the following contact grid to contact the appropriate IT representative so that they may resolve the discrepancy with the customer. 5.2 Event Date File Not Received If the Inventory file is not received for the current week, processing will continue using the most current data in the staging table, and the escalation contact will be alerted. Use the following contact grid to contact the appropriate IT representative so that they may resolve the discrepancy with the customer. 5.3 Modified File Received In the event that any file received has had their data structure modified, The Company will be unable to process that file. The support team should contact the appropriate IT representative using the contact grid so that they can follow up with the customer and assist them in resubmitting a file with the correct data structure. If the customer requires a permanent change to the file structure, the IT representative can also assist the customer in initiating the change control process to make it happen. These types of changes will be subject to the standard change control process. 5.4 Contact Grid Order Contact Role Phone E-mail Primary John Doe Analyst 555-1212 john.doe@email.com Secondary Jane Doe Manager 555-1212 jane.doe@email.com October 26, 2009 Page 7 of 7