Appendix 1 – Acronyms

19
Defense Finance and Accounting Service Financial Management Center of Excellence Functional Requirements Description For Standard General Ledger Project Version 3.0 December 17, 2007

Transcript of Appendix 1 – Acronyms

Page 1: Appendix 1 – Acronyms

Defense Finance and Accounting Service

Financial Management Center of Excellence

Functional Requirements DescriptionFor

Standard General Ledger Project

Version 3.0

December 17, 2007

Page 2: Appendix 1 – Acronyms

Version Control

Version Date Description of Changes

1.0 July 4, 2007

First released version. This version contains functional requirements for the General Ledger JAD session 1 (Maintain Chart of Accounts) and JAD session 2 (Maintain Transaction Posting Rules).

2.0 August 8, 2007

Second released version. This version contains the functional requirements for the General Ledger JAD sessions 3 (Record Journal Entries) JAD session 4 (Post Transactions to Update General Ledger), and JAD 5 (Perform Periodic General Ledger Postings).

3.0 December 17, 2007

Third released version. This version contains all functional requirements, business rules, process maps, process descriptions, and best practices to include all the USSGL Transaction Library business events.

ii

Page 3: Appendix 1 – Acronyms

Table of Contents

1.0 INTRODUCTION..........................................................................................................................................1BACKGROUND.............................................................................................................................................1

1.2 DOCUMENT PURPOSE...................................................................................................................................11.3 SCOPE...........................................................................................................................................................11.4 DEFINITIONS.................................................................................................................................................2

2.0 THE ENTERPRISE FUNCTIONAL REQUIREMENTS PROGRAM...................................................3

2.1 OVERVIEW....................................................................................................................................................32.2 FUNCTIONAL REQUIREMENTS DEVELOPMENT METHODOLOGY..................................................................42.3 REQUIREMENT IDENTIFICATION FORMAT....................................................................................................5

3.0 STANDARD GENERAL LEDGER CONCEPT OF OPERATIONS.......................................................6

3.1 STANDARD GENERAL LEDGER FUNCTIONAL OVERVIEW..............................................................................63.2 STANDARD GENERAL LEDGER PRACTICES....................................................................................................63.3 STANDARD GENERAL LEDGER RELEASE 3.0 SCOPE.....................................................................................7

4.0 STANDARD GENERAL LEDGER POINTS OF CONTACT.................................................................9

4.1 STANDARD GENERAL LEDGER CONTACT INFORMATION............................................................................94.1.1 STANDARD GENERAL LEDGER SHARED SERVICES DIVISION HOTLINE.................................................94..1.2 STANDARD GENERAL LEDGER DFAS EPORTAL.................................................................................94.1.3 STANDARD GENERAL LEDGER WORLD WIDE WEB........................................................................9

APPENDIX 1 – ACRONYMS...................................................................................................................................10

iii

Page 4: Appendix 1 – Acronyms

[This Page Intentionally Left Blank]

iv

Page 5: Appendix 1 – Acronyms

Introduction

1.1 Background

Department of Defense (DoD) Directive 5118.5 identifies the Director, Defense Finance and Accounting Service (DFAS) as the principal DoD executive for finance and accounting requirements, systems, and functions. That role includes the responsibility to “Direct the consolidation, standardization, and integration of finance and accounting requirements, functions, procedures, operations, and systems within the Department of Defense.” Developing standard, consistent, and effective requirements for DoD finance and accounting operations and systems is a priority initiative for the DFAS Financial Management Center of Excellence (FM COE). The FM COE has assigned this complex program to its Shared Services Division (SSD), which has gathered requirements from current statutory laws, regulations, and guidance, in addition to requirements from existing and developing DoD finance and accounting systems. SSD used functional experts from other DFAS organizations to select and edit the appropriate set of requirements.

The requirements contained herein will become the basis for all new finance and accounting operations and system acquisitions across the Department, and all existing DoD finance and accounting systems will migrate to these requirements as their budgets and priorities dictate.

1.2 Document Purpose

The purpose of this document is to present the context for standard DoD General Ledger functional requirements. That context is a description of the DoD Standard General Ledger concept of operation, its standard business practices, and its operational processes. The processes are taken from the DoD Business Enterprise Architecture (BEA) and extended, as necessary, to complete a level of detail to which the requirements can easily be assigned.

Requirements information is presented in three parts: 1) the contextual description of the requirements project and its functional area, and 2) the process models for this functional area, and 3) the requirement statements, business rules and best practices for this functional area. The contextual description of this requirements project and its functional area are contained in this Functional Requirements Description (FRD). The process models, requirement statements, and business rules are presented in an accompanying spreadsheet.

In addition this document is to present version 3.0 of the General Ledger Functional Requirements Description (FRD) document. This version of the FRD will serve as the definitive reference for General Ledger functional requirements. It is a “living” document and will be updated as requirements change or are refined.

1.3 Scope

This document also establishes the context for the DoD standard functional requirements in the area of General Ledger. It also comprises the most current General Ledger functional requirements resulting from analyses, reviews, and validations performed by Shared Services team members and subject matter experts. Detailed accomplishments which influenced the development of this FRD may be found in Section 3.0.

1

Page 6: Appendix 1 – Acronyms

This document establishes the context for the DoD standard functional requirements in the area of General Ledger. General Ledger Management is the central function of the Core financial management system. All transactions to record financial events must post to the general ledger, regardless of the origin of the transaction. Transactions originating in other systems may post to the general ledger at a summary level, depending on an agency’s overall financial management system design and need. At a minimum, summary transactions must post at a level that maintains the accounting classification elements and attributes needed to support central agency reporting. The General Ledger project is focused on developing standardized functional requirements pertaining to General Ledger only. Intergovernmental (Interfund and IPAC transactions), Accounts Receivable, Accounts Payable, and Disbursing requirements are out of scope. The related requirements for Cash Accountability and Financial Reporting are out of scope but will be shared accordingly as touch-points and interfaces captured during the integration portion of the project. Managerial Accounting and Budget and Funds Distribution and Internal Controls are also out of scope. These functional requirements apply to both general fund and working capital fund.

1.4 Definitions

As used within this document, functional requirements, business rules, and best practices are defined as follows:

Functional Requirement – A statement that describes the intended behavior of a system by describing characteristics, attributes, conditions, constraints, or capabilities to which a system must conform in order to meet a need or objective.1 In this document, when the word “requirement” is used, it means functional requirement.

Business Rule – A statement that defines or constrains some aspect of the business or its architecture. It describes what a business must or must not do, or it describes the rules under which the architecture or its objects behave under certain conditions. Business rules are constraints that are process/activity specific and have no system impact.2

Best Practice – A management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a project can be rolled out and completed with fewer problems and unforeseen complications.3

1 SSD Roadshow Presentation 2 DoD Architecture Framework, Vol. II3 Wikipedia (www.wikipedia.com)

2

Page 7: Appendix 1 – Acronyms

2.0The Enterprise Functional Requirements Program

2.1 Overview

The Enterprise Functional Requirements Program is a set of projects to develop standard functional requirements, business rules, and best practices for DoD finance and accounting operations and systems. The requirements and business rules will be architecture-driven – meaning that they will be aligned to processes in the DoD Finance and Accounting Operational Architecture, which itself is aligned with the DoD Business Enterprise Architecture (BEA) (see Figure 1).

Compliance requirements, business rules, and best practices have already been developed at the DoD enterprise functional level as part of the BEA. In most cases, the compliance requirements do not contain all the functional information necessary for an acquisition program, like GFEBS, Navy ERP, DEAMS, or BEIS, to properly implement and test the acquisition system. Therefore, this program develops functional requirements down to the level of detail such that acquisition programs do not need to make functional interpretations. Yet these requirements should not constrain the implementation in non-functional ways, for example by defining system-specific data element names. Functional requirements for Standard General Ledger were gathered from:

Defense Enterprise Accounting and Management System (DEAMS) Defense Agency Initiative (DAI) Defense Procurement Payment System (DPPS) Business Modernization Reengineering (BMR) [E-Biz] Defense Standard Disbursing System (DSDS) A Guide to Federal Requirements for Financial Management Systems (DFAS

7900.4G - Blue Book) General Fund Enterprise Business System (GFEBS) Business Enterprise Architecture (BEA) Version 4.0 Business Systems Modernization (BSM) OMB Circulars Office of Federal Financial Management (OFFM-NO-0106)

However, most of the requirements derived from the above are too high-level to be readily implemented by system engineers in acquisition program offices. Therefore, a large part of the effort of these requirements projects has been to refine the requirements taken from the above to bring them down to the implementation level, i.e., eliminate any need for the system engineer to make functional interpretation.

All functional requirements will adhere to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. Once approved, the enterprise functional requirements will be given to all finance and accounting system offices for implementation in their respective systems.

Federal FM Guidance

OFFM, Treasury, SFFAS, SFIS

Architecture(BEA)

DoD FM Guidance(FMR & Blue Book)

DoD F&A Operational Architecture

DoD Finance & Accounting Requirements• Processes• Business Rules• Functional Requirements

3

Page 8: Appendix 1 – Acronyms

1. Plan Project2. Develop Processes3. Identify and Gather Requirements,

Business Rules, and Best Practices4. Perform Mapping5. Perform Initial Validation6. Validate and Write Requirements7. Deliver Version 1.x/2.0 Requirements

and Documentation to Director, FM COE8. Integrate Version 3.0 Requirements

and Deliver Final Documentation9. Perform Project Management

Table 2. High Level Development Tasks

Because the DoD finance and accounting domain is so large, the enterprise functional requirements projects have been segmented into functional areas, similar to the chapters in “A Guide to Federal Requirements to Financial Management Systems”4. The selected set of functional areas (i.e., requirements projects) is listed in Table 1. The first seven projects are being executed in FY07 and are considered the Core Financial Finance and Accounting areas.

2.2 Functional Requirements Development Methodology

This, and each of the other requirements projects went through a similar nine-step process to gather, map, write, and validate requirements. Each project developed its own detailed work plan and detailed schedule taking into consideration their scope, priorities, and available resources. Subject Matter Experts (SMEs) were enlisted to help select those requirements that should be standardized, and they wrote additional requirements where the level of detail of those requirements initially gathered was not sufficient. The numerical order of the tasks in Table 2 indicates the approximate sequence of events.

4 Formally, this document is entitled DFAS 7900.4-G, A Guide to Federal Requirements to Financial Management Systems, Jan., 2007. Informally, this book is sometimes referred to as the Blue Book.

Requirements ProjectsAccounts Payable (Payment Mgmt)DisbursingRevenue and Accounts ReceivableGeneral LedgerFinancial ReportingCash AccountabilityIntra-governmentalInventory, Operating Materials and

Supplies, Stockpile MaterialsProperty, Plant and EquipmentManagerial Cost AccountingHuman Resources, Payroll, and BenefitsFunds Control and Budgetary AccountingTravelLoans and GrantsAudit Trails and System ControlsSeized Assets

Table 1. Requirements Functional Areas

4

Page 9: Appendix 1 – Acronyms

2.3 Requirement Identification Format

The General Ledger requirements are uniquely identified by a combination of letters and numbers broken down into several parts. The first part is shown by 2 to 4 letters followed by a dash (-) that identifies which functional area the requirement belongs. The first set of four-position numbers after the dash is a unique number assigned to the parent requirement. Subsequent sets of two-position numbers will be assigned to show children and/or grand children to a parental requirement. As an example, XX or XXXX-0001.01.01 requirement number will be used as a reference.

GL-0001.01.01: 2 – 4 position identifier that delineates functional area

GL- 0001.01.01: Indicates this as requirement number 1 of the functional area

GL-0001.01.01: First child of parental requirement number 1

GL-0001.01. 01 : First child of child requirement number 1

5

Page 10: Appendix 1 – Acronyms

3.0 General Ledger Concept of Operation

This section contains an end-to-end description of and lists the important practices for the Project’s “To-Be” functional area. The description provides context for the processes described in the accompanying spreadsheet.

3.1 General Ledger Functional Overview

In October, 2006, the Requirements Management Division was tasked to establish a set of functional requirements for the General Ledger. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current Business Enterprise Architecture model and identify any gaps if they existed.

First, the work group gathered existing general ledger functional requirements and business rules from available sources. These requirements were consolidated, reviewed, mapped to business processes, and pre-validated by the working group.

Next, a selected set of general ledger subject matter experts (SMEs) were invited to a Joint Application Development (JAD) session to review and validate the requirements for applicability as a DoD standard in each process area. General Ledger functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting results when each functional requirement is implemented across systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. At any time if issues were uncovered, they were identified, logged, and worked toward resolution.

At the completion of the JAD session, the General Ledger Work Group reviewed the comments and new requirements developed by the SMEs and prepared issues where necessary. Then, the SMEs re-convened the JAD session to validate their earlier work, each SME was given the opportunity to provide their comments and rationale regarding each requirement. As issues were uncovered, they were documented, logged, analyzed, and worked toward final resolution.

At the completion of the JAD sessions, the requirements were reviewed again by the General Ledger Work Group and presented to FMCOE for review and approval to publish across the network. After the review and approval process, the FMCOE Director (also the DFAS Requirements Approval Authority) approved the raw functional requirements set as a standard for all DoD systems.

3.2 General Ledger Practices

The purpose of this project is to provide the functional requirements, business rules, and best practices to allow the DoD financial community the ability to record proprietary and budgetary general ledger (GL) transactions in accordance with FASAB standards, GAAP and regulatory requirements. These requirements, business rules, and best practices will be utilized to define the use of, and rules to, control GL accounts and to conduct analyses and reconciliations. This will ensure that Organizations across the enterprise network are able to support and post to a DoD corporate general ledger in a standard, consistent manner that satisfies federal regulatory requirements. Consistent use of general ledger provides enhanced auditability and analytical transparency. The requirements in the accompanying spreadsheet reflect the to-be model for the General Ledger processes. There is a current and on-going effort to refine the USSGL Transaction Library in an attempt to identify the business events that are unique to the

6

Page 11: Appendix 1 – Acronyms

Department of Defense business. The development of the standard functional requirements for the general ledger project coupled with the refining of the USSGL Transaction Library will ensure that all general ledger postings are consistent and that all gaps are filled.

3.3 Release Integration Scope

3.3.1 Map Requirements to BEA Processes

During Release 3.0 the Shared Services Branches completed Integration or cross function validation of the functional requirements. In release 3.0 requirements were mapped to the lowest level possible within the BEA architecture and if appropriate to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services Functional Branches Integrated these requirements by reviewing, analyzing, and updating the requirements based upon missing or necessary architectural and functional links. Missing requirements were developed and included in the General Ledger requirements database to encompass any gaps between the documents.

3.3.2 Review Requirements Linked by Processes

The Shared Services Branches further integrated functional requirements by identifying requirements that were touch points between functions. The teams conducted cross team reviews and updated the requirements based upon touchpoints between the functional areas. The requirements were updated based upon the teams’ analysis.

3.3.3 Validate Requirements Source Information

Release 3.0 requirement authoritative sources were validated by the functional branches and the Quality Review Panel and the Business transformation Agency. Authoritative source updates to the requirements included regulation or policy changes received in October and November 2007. Gaps between the version 2.0 requirements and authoritative sources were documented and new requirements were written and added to the database as necessary.

3.3.4 Review Requirements for Implementability

The Release 3.0 requirements were reviewed 100% by SAP and Oracle subject matter experts. The review provided feedback on clarity of the requirements and implementability of the requirements in the SAP and Oracle environments. Shared Service Functional Teams updated requirements based upon SAP and Oracle feedback.

3.3.5 Assign Rejected Requirement to Other Core Teams

Release 3.0 included requirements that were previously rejected in version 1.0 and 2.0 as being out of scope for a specific functional area. These requirements were identified and considered for inclusion in another team’s functional requirements.

7

Page 12: Appendix 1 – Acronyms

3.3.6 Perform Team Quality Review of Requirements

In Release 3.0, the functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision.

3.3.7 Perform Quality Panel Review of Requirements

In Release 3.0 a Quality Panel reviewed 100% of the functional requirements and provided feedback to the functional branches on Scope; Functionality; Testability; Necessity; Achievability; Singularity; Syntax; Clarity and authoritative source validation. Functional branches updated the requirements based upon Quality Panel and branch supervisory reviews.

3.3.8 Develop Additional Process Models

General Ledger Team did not develop additional process models for release 3.0 of the FRD. Possible gaps with the BEA were identified, however, and will be reviewed by the team to determine the need for developing additional process models to encompass these gaps.

3.3.9 Close Out Open Issues

Issues identified during release 3.0 and previous releases were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FM COE staff were transferred to the office that had responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool. The General Ledger Team resolved all issues prior to the subsequent JAD sessions.

3.3.10 Compare Requirements to DoD Transaction Library

Functional requirements were mapped to the DoD transaction library and their associated general ledger affects. Shared Services Functional Branches reviewed, analyzed, and updated requirements based upon general the ledger scenarios. The requirements from other functional areas were updated to include the DoD transaction Code (DTC) contained in the DoD transaction Library. All transaction library scenarios and their general ledger affects were reviewed for possible inclusion in the requirements. This ensured general ledger debit and credit pairs were linked to the associated functional requirements.

In Release 3.0 Shared Services implemented a Requirements Database for storing, updating and retrieving the Functional Requirements. Requirements for all functional areas are included in the Database. Tailored Excel products are available for customer and staff use.

8

Page 13: Appendix 1 – Acronyms

4.0 General Ledger Points of Contact

4.1 Contact Information

Following is a list of methods which the reader may use to provide feedback on this document or to obtain additional information as needed.

1.1.1 Shared Services Division Hotline

Shared Services Division has established a hotline which may be used to provide comments or request information regarding the use of the General Ledger FRD. The Shared Services Hotline number is (317) 510-2000.

1.1.2 DFAS eportal

Shared Services Division has established a DFAS eportal page titled “Core Financial Requirements” which may be used to access General Ledger Requirement Documentation. Access to the eportal page is available to DoD staff. Staff must have PKI capability to access the eportal. Request Access to the eportal page by contacting the Shared Services Hotline at (317) 510-2000.

1.1.3 World Wide Web

A web site is under development for the storage and retrieval of functional requirement information. Implementation of the Web page is expected in January 2008.

9

Page 14: Appendix 1 – Acronyms

Appendix 1 – Acronyms

AP Accounts PayableAR Accounts ReceivableBEA Business Enterprise ArchitectureBEIS Business Enterprise Information SystemBEP Business Enterprise PriorityBID Business Integration DivisionBPR Business Process ReengineeringBTA Business Transformation AgencyCA Cash AccountabilityCCB Configuration Control BoardDEAMS Defense Enterprise Accounting and Management SystemDFAS Defense Finance and Accounting ServiceDISB DisbursingDMI Desktop Management InitiativeDOORS Dynamic Object-oriented Requirements SystemDoD Department of DefenseERP Enterprise Resource PlanningFASAB Federal Accounting Standards Advisory BoardFASB Financial Accounting Standards BoardFBS Functional Business SupportFM COE Financial Management Center of ExcellenceFMR Financial Management RegulationsFR Financial ReportingGAAP Generally Accepted Accounting PrinciplesGAO Government Accountability OfficeGFEBS General Fund Enterprise Business SystemGL General LedgerHPO High Performing OrganizationIG Intra-GovernmentalIT Information TechnologyJAD Joint Applications DevelopmentOA Operational ArchitectureSME Subject Matter ExpertSSD Shared Services DivisionWBS Work Breakdown Structure

10