COMPANY LOGO

COMPANY LOGO Graphics

COMPANY NAME

Project Name: Financial Data Warehouse [FDW]

Functional Requirement Design Document

<Company Logo>

Page 1

Table of Contents 1. Document Control ................................................................................................................................. 3

1.1 Change Record .............................................................................................................................. 3

1.2 Reviewers ...................................................................................................................................... 3

1.3 Approvals ...................................................................................................................................... 3

1.4 Approval Sections ......................................................................................................................... 4

2. About This Document ........................................................................................................................... 5

2.1 Purpose .......................................................................................................................................... 5

2.2 Intended Audience ........................................................................................................................ 6

3. Assumptions and Dependencies ............................................................................................................ 7

3.1 Assumptions .................................................................................................................................. 7

3.2 Dependencies ................................................................................................................................ 7

4. Requirement Details .............................................................................................................................. 8

4.1 Bus Matrix Requirement with business facts and dimensions ...................................................... 8

4.1.1 Bus Matrix for FDW ............................................................................................................. 8

4.2 Source to Target Mapping requirement ........................................................................................ 8

4.2.1 Link for the source to target mapping Enterprise Performance Management [EPM] ......... 9

4.2.2 Link for the source to target mapping Business Planning and Control [BPC] .................... 9

4.2.3 Link for the source to target mapping Business Objects [BO] universes ............................. 9

4.2.4 Link for source to target mapping for Hierarchy .................................................................. 9

4.2.5 Link for source to target analysis document for peoplesoft Tree Structure .......................... 9

4.2.6 Link for the gap analysis for the PSE DIAL to PSE Prod on the new cube added ............... 9

4.2.7 Link for the view analysis for the summarization data. ........................................................ 9

4.3 Data Handling Requirement .......................................................................................................... 9

4.4 Logical Data Model(s) .................................................................................................................. 9

4.5 Data Dictionary requirement(s) .................................................................................................. 10

4.5.1 The data dictionary for the BPC shall be explained as below link: .................................... 10

4.5.2 The data dictionary for the EPM shall be explained as below link: .................................... 10

4.5.3 The data dictionary based upon the FDW logical model is as follows: .............................. 10

<Company Logo>

Page 2

[Please refer the link for details: ] ...................................................................................................... 10

4.6 File Validation ............................................................................................................................ 10

4.7 Data Validation ........................................................................................................................... 10

4.8 Error Severity [May not Apply as it might have only for loading and failed any reports] ......... 10

4.9 Error Handling ............................................................................................................................ 11

4.10 Audit Trail ................................................................................................................................... 11

4.11 Data Archival .............................................................................................................................. 12

4.12 Error Reporting ........................................................................................................................... 12

4.13 Fallback Mechanism ................................................................................................................... 12

4.14 Service Level Agreement ............................................................................................................ 12

5. Additional Specifications .................................................................................................................... 13

5.1 Performance ................................................................................................................................ 13

5.1.1 Batch performance .............................................................................................................. 13

5.2 Security Specifications ................................................................................................................ 13

6. Open Questions ................................................................................................................................... 14

6.1 Open Issues ................................................................................................................................. 14

7. Appendix A ......................................................................................................................................... 15

7.1 Traceability Matrix ..................................................................................................................... 15

7.2 Review Comments Log ............................................................................................................... 15

8. Appendix B: Acronyms ...................................................................................................................... 16

<Company Logo>

Page 3

1. Document Control

1.1 Change Record

Version Date Changed By Section(s)

Description of Changes

1.0 5/08/2016 Rasananda

Behera Initial Version

1.1 5/16/2016 R Behera Template for Functional Requirements updated as per

internal discussion with Business Stakeholders

1.2 Reviewers

Reviewer Name Reviewer Position

VP/Director Name Company(Financial) - Proxy Business VP & Data Work

stream Lead

Finance Manager/Director Company(Financial) – Manager II, Finance Technology

Accounting/Auditing Manager Company(Financial) – Accounting & Data

CDO [Data & Analytics] Company Chief Data Officer

Sponsor* Company(Financial) – IT Manager

* IT review includes six levels – IT PM, IT Lead, IT Lead Designer, IT Designer,

IT BA and QMC

1.3 Approvals

Approval Role Approver Name Approval Date Version

Business SME

Business Department Head

Business VP

Proxy Business VP

<Company Logo>

Page 4

1.4 Approval Sections

Approval Needed

Business SME,

Business Department Head,

Business VP

Proxy Business VP

FR 024.01 X

FR 001.01 X

FR 001.01.01 X

FR 001.02 X

<Company Logo>

Page 5

2. About This Document

2.1 Purpose

The purpose of this document is to record the Current architecture to build and

design the Future architecture diagram through building blocks extensively used

through TOGAF paradigm. The Functional Requirements and Functional Design for

the Financial Data Warehouse [FDW] flow (see highlighted below) from the

Financial Consolidated Interface (FCI) to Finance Integration Hub (FIH)/ Operational

Data Store (ODS). This is extended to track all of the data both summarization and

other historical information data in Financial Data Warehouse [FDW]. The proposal

to SUNSET the peoplesoft Enterprise Performance Management [EPM] completely

ON Jan 2017 and replace it with FDW. There is certain portion of the BPC related

facts and dimensions shall be available in the FDW as the only source of the financial

data warehouse. Most of the accurate information can be driven from FDW as a

single source of financial data warehouse going forward.

PeopleSoft AP

Journal Activity

GL feed from FCI w/ oldCOA

AP records ( w/ NewCOA )

Financial Data

Warehouse [FDW]

Financial Data

Integration Hub

(FIH/ODS)

Future State Functional Data Flow Diagram

Financial Data Integration Hub ( FIH/ODS)

AP data for Processing

by PeopleSoft AP

Posted GL

Records

FCI

Admin Systems

PeopleSoft GL FAH

PeopleSoft AP processed records

AP records ( w/ NewCOA )

AP records for COA change

GL records updated with NewCOA

Posted GL Records, Processed AP records,

BPC & Allocation data from BPC/EMS,

Old COA <-> New COA maps,

PeopleSoft Tree Structures

Replcaement of EPM

BPC / EMS

Processed GL dataALL BPC/EMS

data for reporting

NXG

Reverse COA

<Company Logo>

Page 6

2.2 Intended Audience

The primary audience for this document is Business Users, Business Analysts and

Subject Matter Experts [SME], Project Lead[PL], Project Manager [PM], Information

Technology [IT] team, Quality Management Control [QMC], Architects and other

cross functional team members and other project stakeholders.

<Company Logo>

Page 7

3. Assumptions and Dependencies

3.1 Assumptions

Assumption Assumption Description

A 001 The structure for data transportation is not defined as it is not business

driven.

A 002

Any BPC related forecasting and budget planning related requirements

in upstream or downstream systems, which is currently in place or

being addressed as part of other functional stream requirements, that

need to be discussed and updated as per requirement change control

process.

A 003

Any agreed approach related to generic requirements such as global

transaction tracking, standard error reporting may require changes to

the functional requirements addressed in this document. These changes

will follow the requirement change control process

A 004

There shall be scheduling requirements of data integration jobs that

must be addressed and finalized during the design phase. There are 60

BPC SSIS packages and over 100 EPM SSIS packages needs to be

assessed for the data transfer and loading process.

A005

This FDW shall be the core with business objects [BO] as the

presentation layer or reporting structure. The FDW can be accessed by

any other platform or tool based on the logical structures - specifically

based on the subject area(s).

A006 The FDW logical model shall be extended based on the people soft tree

structure and hierarchy changes.

3.2 Dependencies

Dependencies Dependencies Description

<Company Logo>

Page 8

4. Requirement Details

4.1 Bus Matrix Requirement with business facts and dimensions

The bus matrix purpose is one of high abstraction and visionary planning on the

financial data ware house architectural level. By dictating coherency in the

development and implementation of an overall financial data ware house the bus

architecture approach enables an overall vision of the broader enterprise integration

and consistency . At the same time we divide the problem into more manageable parts

– all in a technology and software independent manner. The bus matrix and

architecture build upon the concept of confirmed dimensions – creating a structure of

common dimensions used across BPC and EPM by all business processes related to

financial data ware house and corresponding fact tables from which they derive their

context. The Financial data Warehouse [FDW] builds on the bus architecture

“identifies and enforces the relationship between business process metrics and [facts]

and descriptive attributes [dimensions] the information shall reflect the confirmed

dimension concept in the financial data warehouse and create a skeletal structure

where all parts of a system connect, ensures system interoperability, and consistency

of data and consider for future expansion scalability.

4.1.1 Bus Matrix for FDW

A graphical overview of the financial enterprises core business processes each

correspond to a measured table of facts.

4.1.3.1 The system shall be complemented by source system horizontal rows.

4.1.3.2 The vertical columns shall be the group of contextual data as the

confirmed dimensions.

4.2 Source to Target Mapping requirement

There shall be a complete source to target data mapping entity – to – entity level

available for the data loading. There are documents available for the business

planning control [BPC] getting the data loaded from the PeopleSoft and other source

data.

<Company Logo>

Page 9

4.2.1 Link for the source to target mapping Enterprise Performance Management [EPM]

4.2.2 Link for the source to target mapping Business Planning and Control [BPC]

4.2.3 Link for the source to target mapping Business Objects [BO] universes

4.2.4 Link for source to target mapping for Hierarchy

4.2.5 Link for source to target analysis document for peoplesoft Tree Structure

4.2.6 Link for the gap analysis for the PSE DIAL to PSE Prod on the new cube added

4.2.7 Link for the view analysis for the summarization data.

4.3 Data Handling Requirement

In example the key accounting codes such as Business Unit, Financial Account,

Department and/or Product etc.

Requirement

# Requirement Details

FR xxx. The ODS data shall be down streamed to the FDW as described. If there is

any changes to ODS streamline then it will have the similar data feed to

FDW.

4.4 Logical Data Model(s)

Based on the FDW requirements there are different sources of logical model

considered as different subject areas of our baseline data model structures. The FDW

data model shall be adhered based upon the below source logical data model

structures.

Erwin Data Model for ODS

ERWin DataModel for BO

ERWin DataModel for EPM

ERWin DataModel for BPC

ERWIN DataModel for FDW

<Company Logo>

Page 10

4.5 Data Dictionary requirement(s)

4.5.1 The data dictionary for the BPC shall be explained as below link:

4.5.2 The data dictionary for the EPM shall be explained as below link:

4.5.3 The data dictionary based upon the FDW logical model is as follows:

[Please refer the link for details: ]

4.6 File Validation

Requirement

# Requirement Details

FR 025

FR 025.00.01

4.7 Data Validation

Requirement

# Requirement Details

FR 001

FR 001.01

FR 001.01.01

4.8 Error Severity [May not Apply as it might have only for loading and failed any

reports]

The severity level of an error message provides an indication of the type of problem

that the system has encountered and expected resolution SLA for the error.

Error

Severity

Description Action Required

<Company Logo>

Page 11

Showstopper

Direct impact on the potential delay of

the close* process.

Call IT and send urgent (high

importance) email notification to

Business

High

Widespread and/or material data loss

could create inaccuracies in downstream

systems

Urgent (high importance) email

notification to IT and Business

Medium Localized data loss could create

inaccuracies in downstream systems

Email notification (normal

importance) to IT and Business

Low Immaterial data loss could create

inaccuracies in downstream systems

Email notification (normal

importance) to IT and Business

*NOTE: The data associated with a quarterly close impacts the PeopleSoft periods

of March, June, and September; year-end close period is December. The critical work

days (WD) associated with these periods are WD 1 – WD11; year-end critical days are

WD1 – WD14. WDs associated with the close begin the first scheduled work day of

the following month and do not include holidays for which Company office is closed.

For example, for June’s close, WD1 is July 1st (as long as if falls Monday – Friday),

WD2 is July 2nd, WD3 is July 3rd, WD4 is July 5th (July 4th is a scheduled holiday).

Only system abends impacting the close period on critical WDs would qualify as

“showstopper”, e.g. PeopleSoft GL or AP abends on WD2, July 2nd, of the June close

is a “showstopper”. Data related errors are considered “high” severity.

4.9 Error Handling

Requirement

# Requirement Details

FR 014

FR 015

FR 015.01

4.10 Audit Trail

Requirement

# Requirement Details

FR 017

FR 017.01

<Company Logo>

Page 12

4.11 Data Archival

Requirement

# Requirement Details

FR 018

4.12 Error Reporting

Requirement

# Requirement Details

FR xxx

FR xxx.01

4.13 Fallback Mechanism

Requirement

# Requirement Details

FR xxx

FR xxx.01

4.14 Service Level Agreement

Requirement

# Requirement Details

FR xxx The system shall be loaded automatically process for the data feed to

FDW. There are cases when manual process involved in the loading

process within the defined Service Level Agreement

FR xxx.01

The current availability timeline for batch process and ETL load is 2 times

in 24 hours’ time period. The time schedule job is 12:00AM midnight and

5:00 AM schedule. This timeline has to be readjusted as per the future

state data flow. The SLA slippage will be notified to IT Finance group.

<Company Logo>

Page 13

5. Additional Specifications

5.1 Performance

5.1.1 Batch performance

The FDW data load will be processed and sent to database schema within agreed

timeframe from the time of arrival.

5.2 Security Specifications

The access to the business object security shall be made available to the necessary

access process. The roles and permissions shall be granted by role based. The

privileges shall be for user levels are derived for PS_YX_BO_SECURITY entity

level.

<Company Logo>

Page 14

6. Open Questions

6.1 Open Issues

# Question Resolution Responsibili

ty

Target

Date

Complete

d Date

1.

2.

3.

4.

5

<Company Logo>

Page 15

7. Appendix A

7.1 Traceability Matrix

URL Link:

https://projectserver/PWA/BCS...

7.2 Review Comments Log

https://projectserver/PWA/BCS...

<Company Logo>

Page 16

8. Appendix B: Acronyms

The following acronyms have been used in this document:

Term Explanation

FDW Financial data warehouse (FDW or DWH), also known as data warehouse

(DW), is a system used for financial reporting and financial data analysis, and

is considered as a core component of business intelligence environment.

FDW is a central repository of integrated data from one or more disparate

sources. They store current and historical data and are used for creating

analytical reports for knowledge workers throughout the enterprise.

Financial Data warehouses are optimized for analytic access patterns.

Analytic access patterns generally involve selecting specific fields and rarely

if ever 'select *' as is more common in operational databases. Because of these

differences in access patterns, operational databases (loosely, OLTP) benefit

from the use of a row-oriented DBMS whereas analytics databases (loosely,

OLAP)

Fact A fact is a value or measurement, which represents a fact about the managed

entity or system.

Facts as reported by the reporting entity are said to be at raw level. E.g. if a

BTS (business transformation service) received 1,000 requests for traffic

channel allocation, it allocates for 820 and rejects the remaining then it would

report 3 facts or measurements to a management system.

Facts at raw level are further aggregated to higher levels in various

dimensions to extract more service or business-relevant information out of it.

These are called aggregates or summaries or aggregated facts.

Dimension Dimensional vs. normalized approach for storage of data.

There are three or more leading approaches to storing data in a data

warehouse — the most important approaches are the dimensional approach

and the normalized approach.

The dimensional approach refers to Ralph Kimball’s approach in which it is

stated that the data warehouse should be modeled using a Dimensional Model

or star schema. The normalized approach, also called the 3NF model (Third

<Company Logo>

Page 17

Normal Form) refers to Bill Inmon's approach in which it is stated that the

data warehouse should be modeled using an E-R model/normalized model.

MDDB Multi-dimensional database

OLAP On-Line Analytical Processing

SCD Slow Change Dimension

BO Business Objects

BPC Business Planning and Consolidation

EPM Enterprise Performance Management a People soft enterprise data warehouse

KPI Key Performance Indicator

SSIS SQL Server Integration Services

ETL Extraction Transformation and Loading

Extracts data from homogeneous or heterogeneous data sources

Transform the data for storing it in the proper format or structure for

the purposes of querying and analysis

Loads it into the final target