• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Functional Requirement Document
 

Functional Requirement Document

on

  • 2,088 views

 

Statistics

Views

Total Views
2,088
Views on SlideShare
2,088
Embed Views
0

Actions

Likes
0
Downloads
52
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Functional Requirement Document Functional Requirement Document Document Transcript

    • Defense Finance and Accounting Service Financial Management Center of Excellence Functional Requirements Description For Release 6.0 September 30, 2009
    • Release/Version Control Release/ Date Description of Changes Version Release 5.0 contains new functional requirements related to Managerial Cost Accounting, Eliminations, Funds Control and Budgetary Accounting, Seized Assets, Grants, Financial 5.0 April 30, 2009 Reporting – Departmental Level and Audit Trails and Systems Controls. Also included are updates to Accounts Payable, Accounts Receivable, and Intragovernmental. This release contains new functional requirements related to Benefits; Direct Loans; Foreign Military Sales (Security Assistance Accounting); Guaranteed Loans; Human Resources and Payroll – Civilian; Human Resources and 6.0 September 30, 2009 Payroll – Military; Inventory, Operating Materials & Supplies, Stockpile Material; Property, Plant and Equipment; Time and Attendance; and Travel. In addition, updates to previously released areas. ii
    • Table of Contents DEFENSE FINANCE AND ACCOUNTING SERVICE..........................................................................................I FINANCIAL MANAGEMENT CENTER OF EXCELLENCE..............................................................................I I SEPTEMBER 30, 2009.................................................................................................................................................I 1.0INTRODUCTION....................................................................................................................................................1 1.1BACKGROUND...........................................................................................................................................................1 1.2DOCUMENT PURPOSE.................................................................................................................................................1 1.3SCOPE 2 1.4DEFINITIONS.............................................................................................................................................................2 2.0THE ENTERPRISE FUNCTIONAL REQUIREMENTS PROGRAM.............................................................3 2.1OVERVIEW................................................................................................................................................................3 2.2FUNCTIONAL REQUIREMENTS DEVELOPMENT METHODOLOGY...........................................................................................5 2.3REQUIREMENT IDENTIFICATION FORMAT........................................................................................................................5 3.0ACCOUNTS PAYABLE (PUBLIC) CONCEPT OF OPERATION..................................................................7 3.1ACCOUNTS PAYABLE (PUBLIC) FUNCTIONAL OVERVIEW.................................................................................................7 3.2ACCOUNTS PAYABLE (PUBLIC) PRACTICES....................................................................................................................9 3.3RELEASE 6.0 SCOPE..................................................................................................................................................9 3.3.1Map Requirements to BEA Processes...........................................................................................................9 3.3.2Review Requirements Linked by Processes..................................................................................................9 3.3.3Validate Requirements Source Information..................................................................................................9 3.3.4Assign Reclassified Requirements to Other Core Teams..............................................................................9 3.3.5Perform Team Quality Review of Requirements..........................................................................................9 3.3.6Develop Additional Process Models...........................................................................................................10 3.3.7Close Out Open Issues.................................................................................................................................10 3.3.8Compare Requirements to DoD Transaction Library.................................................................................10 4.0ACCOUNTS RECEIVABLE CONCEPT OF OPERATION...........................................................................11 4.1ACCOUNTS RECEIVABLE FUNCTIONAL OVERVIEW........................................................................................................11 4.2ACCOUNTS RECEIVABLE PRACTICES...........................................................................................................................12 4.3RELEASE 6.0 SCOPE................................................................................................................................................12 4.3.1Map Requirements to BEA Processes.........................................................................................................12 4.3.2Review Requirements Linked by Processes................................................................................................12 4.3.3Validate Requirements Source Information................................................................................................12 4.3.4Assign Reclassified Requirements to Other Core Teams............................................................................12 4.3.5Perform Team Quality Review of Requirements........................................................................................12 4.3.6Develop Additional Process Models...........................................................................................................12 4.3.7Close Out Open Issues.................................................................................................................................13 4.3.8Compare Requirements to DoD Transaction Library.................................................................................13 5.0AUDIT TRAILS AND SYSTEM CONTROLS CONCEPT OF OPERATION..............................................14 5.1AUDIT TRAILS AND SYSTEM CONTROLS FUNCTIONAL OVERVIEW...................................................................................14 5.2AUDIT TRAILS AND SYSTEM CONTROLS PRACTICES......................................................................................................15 5.3RELEASE 6.0 SCOPE................................................................................................................................................15 5.3.1Map Requirements to BEA Processes.........................................................................................................15 5.3.2Review Requirements Linked by Processes................................................................................................15 iii
    • 5.3.3Validate Requirements Source Information................................................................................................15 5.3.4Assign Reclassified Requirements to Other Core Teams ..........................................................................15 5.3.5Perform Team Quality Review of Requirements........................................................................................15 5.3.6Develop Additional Process Models...........................................................................................................16 5.3.7Close Out Open Issues.................................................................................................................................16 5.3.8Compare Requirements to DoD Transaction Library.................................................................................16 6.0BENEFITS CONCEPT OF OPERATION..........................................................................................................17 6.1BENEFITS FUNCTIONAL OVERVIEW.............................................................................................................................17 6.2BENEFITS PRACTICES................................................................................................................................................18 6.3RELEASE 6.0 SCOPE................................................................................................................................................18 6.3.1Map Requirements to BEA Processes.........................................................................................................18 6.3.2Review Requirements Linked by Processes................................................................................................18 6.3.3Validate Requirements Source Information................................................................................................18 6.3.4Assign Reclassified Requirements to Other Core Teams............................................................................18 6.3.5Perform Team Quality Review of Requirements........................................................................................18 6.3.6Develop Additional Process Models...........................................................................................................19 6.3.7Close Out Open Issues.................................................................................................................................19 6.3.8Compare Requirements to DoD Transaction Library.................................................................................19 7.0CASH ACCOUNTABILITY CONCEPT OF OPERATION............................................................................20 7.1CASH ACCOUNTABILITY FUNCTIONAL OVERVIEW.........................................................................................................20 7.2CASH ACCOUNTABILITY PRACTICES...........................................................................................................................21 7.3RELEASE 6.0 SCOPE................................................................................................................................................21 7.3.1Map Requirements to BEA Processes.........................................................................................................21 7.3.2Review Requirements Linked by Processes................................................................................................21 7.3.3Validate Requirements Source Information................................................................................................21 7.3.4Assign Reclassified Requirements to Other Core Teams............................................................................22 7.3.5Perform Team Quality Review of Requirements........................................................................................22 7.3.6Develop Additional Process Models...........................................................................................................22 7.3.7Close Out Open Issues.................................................................................................................................22 7.3.8Compare Requirements to DoD Transaction Library.................................................................................22 8.0DIRECT LOAN CONCEPT OF OPERATION.................................................................................................23 8.1DIRECT LOAN FUNCTIONAL OVERVIEW......................................................................................................................23 8.2DIRECT LOAN PRACTICES.........................................................................................................................................24 8.3RELEASE 6.0 SCOPE................................................................................................................................................24 8.3.1Map Requirements to BEA Processes.........................................................................................................24 8.3.2Review Requirements Linked by Processes................................................................................................24 8.3.3Validate Requirements Source Information................................................................................................24 8.3.4Assign Reclassified Requirements to Other Core Teams............................................................................24 8.3.5Perform Team Quality Review of Requirements........................................................................................24 8.3.6Develop Additional Process Models...........................................................................................................24 8.3.7Close Out Open Issues.................................................................................................................................25 8.3.8Compare Requirements to DoD Transaction Library.................................................................................25 9.0DISBURSING CONCEPT OF OPERATION....................................................................................................26 9.1DISBURSING FUNCTIONAL OVERVIEW.........................................................................................................................26 9.2DISBURSING PRACTICES............................................................................................................................................28 9.3RELEASE 6.0 SCOPE................................................................................................................................................28 9.3.1Map Requirements to BEA Processes.........................................................................................................28 9.3.2Review Requirements Linked by Processes................................................................................................28 iv
    • 9.3.3Validate Requirements Source Information................................................................................................28 9.3.4Assign Reclassified Requirements to Other Core Teams............................................................................28 9.3.5Perform Team Quality Review of Requirements........................................................................................28 9.3.6Develop Additional Process Models...........................................................................................................28 9.3.7Close Out Open Issues.................................................................................................................................29 9.3.8Compare Requirements to DoD Transaction Library.................................................................................29 10.0FIELD LEVEL REPORTING CONCEPT OF OPERATION.......................................................................30 10.1FIELD LEVEL REPORTING FUNCTIONAL OVERVIEW.....................................................................................................31 10.2FIELD LEVEL REPORTING PRACTICES........................................................................................................................31 10.3RELEASE 6.0 SCOPE..............................................................................................................................................31 10.3.1Map Requirements to BEA Processes.......................................................................................................31 10.3.2Review Requirements Linked by Processes..............................................................................................32 10.3.3Validate Requirements Source Information..............................................................................................32 10.3.4Assign Rejected Requirement to Other Core Teams.................................................................................32 10.3.5Perform Team Quality Review of Requirements......................................................................................32 10.3.6Develop Additional Process Models.........................................................................................................32 10.3.7Close Out Open Issues...............................................................................................................................32 10.3.8Compare Requirements to DoD Transaction Library...............................................................................32 11.0FINANCIAL REPORTING CONCEPT OF OPERATION...........................................................................33 11.1FINANCIAL REPORTING FUNCTIONAL OVERVIEW........................................................................................................33 11.2FINANCIAL REPORTING PRACTICES...........................................................................................................................34 11.3RELEASE 6.0 SCOPE..............................................................................................................................................34 11.3.1Map Requirements to BEA Processes.......................................................................................................34 11.3.2Review Requirements Linked by Processes..............................................................................................34 11.3.3Validate Requirements Source Information..............................................................................................34 11.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................34 11.3.5Perform Team Quality Review of Requirements......................................................................................34 11.3.6Develop Additional Process Models.........................................................................................................35 11.3.7Close Out Open Issues...............................................................................................................................35 11.3.8Compare Requirements to DoD Transaction Library...............................................................................35 12.0FOREIGN MILITARY SALES CONCEPT OF OPERATION.....................................................................36 12.1FOREIGN MILITARY SALES FUNCTIONAL OVERVIEW...................................................................................................36 12.2FOREIGN MILITARY SALES PRACTICES......................................................................................................................37 12.3RELEASE 6.0 SCOPE..............................................................................................................................................37 12.3.1Map Requirements to BEA Processes.......................................................................................................37 12.3.2Review Requirements Linked by Processes..............................................................................................37 12.3.3Validate Requirements Source Information..............................................................................................37 12.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................37 12.3.5Perform Team Quality Review of Requirements......................................................................................37 12.3.6Develop Additional Process Models.........................................................................................................38 12.3.7Close Out Open Issues...............................................................................................................................38 12.3.8Compare Requirements to DoD Transaction Library...............................................................................38 13.0FUNDS CONTROL AND BUDGETARY ACCOUNTING CONCEPT OF OPERATION........................39 13.1FUNDS CONTROL AND BUDGETARY ACCOUNTING FUNCTIONAL OVERVIEW....................................................................39 13.2FUNDS CONTROL AND BUDGETARY ACCOUNTING PRACTICES.......................................................................................40 13.3RELEASE 6.0 SCOPE..............................................................................................................................................40 13.3.1Map Requirements to BEA Processes.......................................................................................................40 13.3.2Review Requirements Linked by Processes..............................................................................................40 v
    • 13.3.3Validate Requirements Source Information..............................................................................................40 13.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................40 13.3.5Perform Team Quality Review of Requirements......................................................................................41 13.3.6Develop Additional Process Models.........................................................................................................41 13.3.7Close Out Open Issues...............................................................................................................................41 13.3.8Compare Requirements to DoD Transaction Library...............................................................................41 14.0GENERAL LEDGER CONCEPT OF OPERATION......................................................................................42 14.1GENERAL LEDGER FUNCTIONAL OVERVIEW..............................................................................................................43 14.2GENERAL LEDGER PRACTICES.................................................................................................................................44 14.3RELEASE 6.0 SCOPE..............................................................................................................................................44 14.3.1Map Requirements to BEA Processes.......................................................................................................44 14.3.2Review Requirements Linked by Processes..............................................................................................44 14.3.3Validate Requirements Source Information..............................................................................................44 14.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................44 14.3.5Perform Team Quality Review of Requirements......................................................................................45 14.3.6Develop Additional Process Models.........................................................................................................45 14.3.7Close Out Open Issues...............................................................................................................................45 14.3.8Compare Requirements to DoD Transaction Library ..............................................................................45 15.0GUARANTEED LOANS CONCEPT OF OPERATION................................................................................46 15.1GUARANTEED LOANS FUNCTIONAL OVERVIEW..........................................................................................................46 15.2GUARANTEED LOANS PRACTICES.............................................................................................................................47 15.3RELEASE 6.0 SCOPE..............................................................................................................................................47 15.3.1Map Requirements to BEA Processes.......................................................................................................47 15.3.2Review Requirements Linked by Processes..............................................................................................47 15.3.3Validate Requirements Source Information..............................................................................................47 15.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................47 15.3.5Perform Team Quality Review of Requirements......................................................................................47 15.3.6Develop Additional Process Models.........................................................................................................48 15.3.7Close Out Open Issues...............................................................................................................................48 15.3.8Compare Requirements to DoD Transaction Library...............................................................................48 16.0HUMAN RESOURCES AND PAYROLL – CIVILIAN CONCEPT OF OPERATION.............................49 16.1HUMAN RESOURCES AND PAYROLL – CIVILIAN FUNCTIONAL OVERVIEW.......................................................................49 16.2HUMAN RESOURCES AND PAYROLL – CIVILIAN PRACTICES.........................................................................................50 16.3RELEASE 6.0 SCOPE..............................................................................................................................................50 16.3.1Map Requirements to BEA Processes.......................................................................................................50 16.3.2Review Requirements Linked by Processes..............................................................................................50 16.3.3Validate Requirements Source Information..............................................................................................50 16.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................51 16.3.5Perform Team Quality Review of Requirements......................................................................................51 16.3.6Develop Additional Process Models.........................................................................................................51 16.3.7Close Out Open Issues...............................................................................................................................51 16.3.8Compare Requirements to DoD Transaction Library...............................................................................51 17.0HUMAN RESOURCES AND PAYROLL – MILITARY CONCEPT OF OPERATION...........................52 17.1HUMAN RESOURCES AND PAYROLL – MILITARY FUNCTIONAL OVERVIEW.....................................................................52 17.2HUMAN RESOURCES AND PAYROLL – MILITARY PRACTICES........................................................................................52 17.3RELEASE 6.0 SCOPE..............................................................................................................................................52 17.3.1Map Requirements to BEA Processes.......................................................................................................52 17.3.2Review Requirements Linked by Processes..............................................................................................52 vi
    • 17.3.3Validate Requirements Source Information..............................................................................................52 17.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................52 17.3.5Perform Team Quality Review of Requirements......................................................................................53 17.3.6Develop Additional Process Models.........................................................................................................53 17.3.7Close Out Open Issues...............................................................................................................................53 17.3.8Compare Requirements to DoD Transaction Library...............................................................................53 18.0INTRA-GOVERNMENTAL CONCEPT OF OPERATION..........................................................................54 18.1INTRA-GOVERNMENTAL FUNCTIONAL OVERVIEW........................................................................................................54 18.2INTRA-GOVERNMENTAL PRACTICES...........................................................................................................................55 18.3RELEASE 6.0 SCOPE..............................................................................................................................................55 18.3.1Map Requirements to BEA Processes.......................................................................................................55 18.3.2Review Requirements Linked by Processes..............................................................................................55 18.3.3Validate Requirements Source Information..............................................................................................55 18.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................55 18.3.5Perform Team Quality Review of Requirements......................................................................................55 18.3.6Develop Additional Process Models.........................................................................................................55 18.3.7Close Out Open Issues...............................................................................................................................55 18.3.8Compare Requirements to DoD Transaction Library...............................................................................56 19.0INTRA-GOVERNMENTAL ELIMINATIONS CONCEPT OF OPERATION...........................................57 19.1INTRA-GOVERNMENTAL ELIMINATIONS FUNCTIONAL OVERVIEW..................................................................................57 19.2INTRA-GOVERNMENTAL ELIMINATIONS PRACTICES.....................................................................................................58 19.3RELEASE 6.0 SCOPE..............................................................................................................................................58 19.3.1Map Requirements to BEA Processes.......................................................................................................58 19.3.2Review Requirements Linked by Processes..............................................................................................59 19.3.3Validate Requirements Source Information..............................................................................................59 19.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................59 19.3.5Perform Team Quality Review of Requirements......................................................................................59 19.3.6Develop Additional Process Models.........................................................................................................59 19.3.7Close Out Open Issues...............................................................................................................................59 19.3.8Compare Requirements to DoD Transaction Library...............................................................................59 20.0INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS CONCEPT OF OPERATION.....................................................................................................................60 20.1INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS FUNCTIONAL OVERVIEW.......................60 20.2INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS PRACTICES..........................................61 20.3RELEASE 6.0 SCOPE..............................................................................................................................................61 20.3.1Map Requirements to BEA Processes.......................................................................................................61 20.3.2Review Requirements Linked by Processes..............................................................................................61 20.3.3Validate Requirements Source Information..............................................................................................61 20.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................61 20.3.5Perform Team Quality Review of Requirements......................................................................................61 20.3.6Develop Additional Process Models.........................................................................................................61 20.3.7Close Out Open Issues...............................................................................................................................61 20.3.8Compare Requirements to DoD Transaction Library...............................................................................62 21.0MANAGERIAL COST ACCOUNTING CONCEPT OF OPERATION......................................................63 21.1MANAGERIAL COST ACCOUNTING FUNCTIONAL OVERVIEW.........................................................................................63 21.2MANAGERIAL COST ACCOUNTING PRACTICES............................................................................................................64 21.3RELEASE 6.0 SCOPE..............................................................................................................................................64 21.3.1Map Requirements to BEA Processes.......................................................................................................64 vii
    • 21.3.2Review Requirements Linked by Processes..............................................................................................65 21.3.3Validate Requirements Source Information..............................................................................................65 21.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................65 21.3.5Perform Team Quality Review of Requirements......................................................................................65 21.3.6Develop Additional Process Models.........................................................................................................65 21.3.7Close Out Open Issues...............................................................................................................................65 21.3.8Compare Requirements to DoD Transaction Library...............................................................................65 22.0PROPERTY, PLANT, AND EQUIPMENT CONCEPT OF OPERATION.................................................66 22.1PROPERTY, PLANT, AND EQUIPMENT FUNCTIONAL OVERVIEW......................................................................................66 22.2PROPERTY, PLANT, AND EQUIPMENT PRACTICES........................................................................................................67 22.3RELEASE 6.0 SCOPE..............................................................................................................................................67 22.3.1Map Requirements to BEA Processes.......................................................................................................67 22.3.2Review Requirements Linked by Processes..............................................................................................67 22.3.3Validate Requirements Source Information..............................................................................................67 22.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................67 22.3.5Perform Team Quality Review of Requirements......................................................................................67 22.3.6Develop Additional Process Models.........................................................................................................67 22.3.7Close Out Open Issues...............................................................................................................................67 22.3.8Compare Requirements to DoD Transaction Library...............................................................................68 23.0TIME AND ATTENDANCE CONCEPT OF OPERATION..........................................................................69 23.1TIME AND ATTENDANCE FUNCTIONAL OVERVIEW......................................................................................................69 23.2TIME AND ATTENDANCE PRACTICES.........................................................................................................................70 23.3RELEASE 6.0 SCOPE .............................................................................................................................................70 23.3.1Map Requirements to BEA Processes ......................................................................................................70 23.3.2Review Requirements Linked by Processes..............................................................................................70 23.3.3Validate Requirements Source Information..............................................................................................71 23.3.4Assign Reclassified Requirements to Other Core Teams .........................................................................71 23.3.5Perform Team Quality Review of Requirements .....................................................................................71 23.3.6Develop Additional Process Models ........................................................................................................71 23.3.7Close Out Open Issues ..............................................................................................................................71 23.3.8Compare Requirements to DoD Transaction Library ..............................................................................71 24.0TRAVEL CONCEPT OF OPERATION...........................................................................................................72 24.1TRAVEL FUNCTIONAL OVERVIEW.............................................................................................................................72 24.2TRAVEL ACCOUNTING PRACTICES............................................................................................................................73 24.3RELEASE 6.0 SCOPE..............................................................................................................................................73 24.3.1Map Requirements to BEA Processes.......................................................................................................73 24.3.2Review Requirements Linked by Processes..............................................................................................73 24.3.3Validate Requirements Source Information..............................................................................................73 24.3.4Assign Reclassified Requirements to Other Core Teams..........................................................................73 24.3.5Perform Team Quality Review of Requirements......................................................................................74 24.3.6Develop Additional Process Models.........................................................................................................74 24.3.7Close Out Open Issues...............................................................................................................................74 24.3.8Compare Requirements to DoD Transaction Library...............................................................................74 25.0SHARED SERVICES POINTS OF CONTACT...............................................................................................75 25.1SHARED SERVICES DIVISION HOTLINE EMAIL............................................................................................................75 25.2WORLD WIDE WEB..............................................................................................................................................75 25.3SCENARIO DATABASE.............................................................................................................................................75 25.4BEA 6.0 ARCHITECTURE.......................................................................................................................................75 viii
    • APPENDIX 1 – ACRONYMS...................................................................................................................................76 ix
    • [This Page Intentionally Left Blank] x
    • 1.0Introduction 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 (FMCoE). The FMCoE 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 requirements including: • Accounts Payable (Public) • Foreign Military Sales • Intra-governmental • Accounts Receivable (Security Assistance • Intra-governmental (Public) Accounting) Eliminations • Audit Trails and System • Funds Control and • Inventory, Operating Controls Budgetary Materials & Supplies, • Benefits Accounting Stockpile Material • Cash Accountability • General Ledger • Managerial Cost Accounting • Direct Loans • Guaranteed Loans • Property, Plant, and • Disbursing • Human Resources Equipment • Field Level Reporting and Payroll – Civilian • Time and Attendance • Financial Reporting • Human Resources • Travel and Payroll – Military The context is a description of the DoD 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, 2) the process models for this functional area, and 3) the requirement statements, business rules and best practices for each functional area. The contextual description of the requirements project and its functional area are contained in this 1
    • Functional Requirements Description (FRD). The process models, requirement statements, and business rules are presented in accompanying spreadsheets. This version of the FRD will serve as the definitive reference for Release 6.0 functional requirements. It is a “living” document and will be updated as requirements change or is refined. 1.3 Scope This document establishes the context for the DoD standard functional requirements. It also comprises the most current functional requirements resulting from analyses, reviews, and validations performed by Shared Services team members and Subject Matter Experts (SMEs). Detailed accomplishments which influenced the development of this FRD may be found in Section 3.0. A separate file (the repository listing) contains the requirements, process model, and other related information in spreadsheet format. The project’s purpose is to develop functional requirements and business rules consistent with commercial industry best practices and compliance requirements (laws, regulations, and policies), and to map them to implementation level processes consistent with the BEA. The project objectives are to: • Present standard functional requirements that can be implemented for any DoD system. • Provide requirements detailed enough so that no functional interpretation is required by system implementers. • Provide requirements that are necessary, achievable, uniquely identifiable, singular, concise, unambiguous, complete, consistent and testable. • Provide relevant information related to the logistical and financial management of DoD events, enhancing system development. 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 Road show Presentation 2 DoD Architecture Framework, Vol. II 3 3 Wikipedia (www.wikipedia.com) 2
    • 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 Federal FM Guidance requirements and business rules will be architecture-driven – OFFM, Treasury, SFFAS, SFIS meaning that they will be aligned to processes in the DoD Finance and Accounting Operational Architecture, which Architecture DoD FM Guidance itself is aligned with the DoD BEA (see Figure 1). (BEA) (FMR & Blue Book) Compliance requirements, business rules, and best practices have already been developed at the DoD enterprise DoD F&A Operational Architecture functional level as part of the BEA. In most cases, the compliance requirements do not contain all the functional DoD Finance & Accounting Requirements information necessary for an acquisition program, like DAI, • Processes • Business Rules GFEBS, Navy ERP, DEAMS, or BEIS, to properly • Functional Requirements implement and test the acquisition system. Therefore, this program develops functional requirements down to the level Figure 1. Requirements Development of detail such that acquisition programs do not need to make Concept functional interpretations. Yet these requirements should not constrain the implementation in the non-functional ways, for example, by defining system specific data elements names. The functional requirements and business rules were gathered from sources such as: • A Guide to Federal Requirements for Financial Management Systems (DFAS 7900.4G - Blue Book) • Business Enterprise Architecture Version 6.0 • Business Modernization Reengineering (BMR) [E-Biz] • Business Systems Modernization (BSM)/Enterprise Business System (EBS) • Core Financial Systems Requirements (OFFM-NO-0106) • Defense Federal Acquisition Regulation Supplement (DFARS) • Defense Transportation Regulation (DTR) 4500.9-R, Part II, Chapter 210 • DFAS, Deputy Director, Operations Memorandum, dated May 2006 • DFAS 7000.10-I, Accounting High Performing Organization • DoD 4000.25-7-M, MILSBILLS • DoD Guidebook for Miscellaneous Payments • DoD Instruction 8500.2, Information Assurance (IA) Implementation • DoD Instruction 8510.01, DoD Information Assurance Certification and Accreditation Process (DIACAP) • DoD Directive 8000.01, Management of the Department of Defense Information Enterprise • DoD Directive 8500.01E, Information Assurance (IA) • Defense Information Systems Agency (DISA), Security Technical Implementation Guides (STIG): Access Control STIG V2R1 and Database STIG V8R1 • DoD 4100.39-M, Volume 4, Federal Logistics Information System 3
    • • DoD 4140.1-R, DoD Supply Chain Management Regulation • DoD Financial Management Regulation (DoD 7000.14-R) • DoD Guidebook for Miscellaneous Payments • Federal Acquisition Regulation (FAR) • Federal Financial Management Systems (FFMSR-8) • Federal Financial Management Systems (FFMSR-00-01) • GAO/AIMD-00-21.3.1, Standards for Internal Control in the Federal Government • JFMIP-SR-99-8, Property Management Systems Requirements • JFMIP-SR-99-14, Seized Property and Forfeited Assets System Requirements • JFMIP-SR-00-4, Property Management System Requirements • JFMIP-SR-01-01, Benefit System Requirements • JFMIP SR-02-01, Core Financial Systems Requirements • JFMIP SR-03-01, Revenue System Requirements • JFMIP-SR-03-02, Inventory, Supplies, and Materials System Requirements • National Institute of Standards and Technology (NIST) Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations, Revision 3 • National Institute of Standards and Technology (NIST) National Security Telecommunications and Information Systems Security Policy (NSTISSP), No. 11, Revised Fact Sheet • OMB Circular A-11, Preparation, Submission and Execution of the Budget • OMB Circular A-127 Financial Management Systems • OMB Circulars A-129 Policies for Federal Credit Programs and Non-tax Receivables • OMB Circular A-130, Management of Federal Information Resources • OMB Circular A-136, Financial Reporting Requirements • OMB Memorandum 09-06, Implementation Guidance for the Federal Financial Management Improvement Act (January 2009) • OUSD (C) Memorandum, "Standard Financial Information Structure (SFIS) Implementation Policy" (August 2005) • OSD and DFAS Policies • Statements of Federal Financial Accounting Standards (SFFAS) No. 1 • SFFAS-3, Accounting for Inventory and Related Property • SFFAS-6, Accounting for Property, Plant, and Equipment • SFFAS-8, Supplementary Stewardship Reporting • SFFAS-23, Eliminating the Category National Defense Property, Plant, and Equipment • SFFAS-29, Heritage Assets and Stewardship Land • Standards and Compliance (S&C) • Treasury Financial Manual (TFM) • Under Secretary of Defense, Deputy Chief Financial Officer Memorandum, dated October 2002 • 5 CFR 1315 (Prompt Payment Act) • 5 USC Section 522a (Privacy Act of 1974) • 44 U.S.C. Section 3541, Information Security 4
    • However, most of the requirements derived from the above are too high-level to be readily implemented by system Requirements Projects engineers in acquisition program offices. Therefore, a large Accounts Payable (Payment Mgmt) part of the effort of these requirements projects has been to Disbursing Revenue and Accounts Receivable refine the requirements taken from the above to bring them General Ledger down to the implementation level, i.e., eliminate any need for Financial Reporting the system engineer to make functional interpretation. Cash Accountability Intra-governmental All functional requirements will adhere to the following Inventory, Operating Materials and Supplies, quality characteristics: necessary, achievable, correct, Stockpile Materials unambiguous, complete, consistent, concise, singular, Property, Plant and Equipment Managerial Cost Accounting implementation-free, and testable. Once approved, the Human Resources and Payroll enterprise functional requirements will be given to all finance Funds Control and Budgetary Accounting and accounting system offices for implementation in their Travel respective systems. Grants Audit Trails and System Controls Because the DoD finance and accounting domain is so large, Seized Assets the enterprise functional requirements projects have been Eliminations (Intra-Governmental) Field Level Reporting segmented into functional areas, similar to the chapters in “A Direct Loans Guide to Federal Requirements to Financial Management Guaranteed Loans Systems”4. Benefits Time and Attendance The selected set of functional areas (i.e., requirements Foreign Military Sales (Security Assistance projects) is listed in Table 1. The first seven projects were Accounting) executed in FY07 and are considered the Core Financial Table 1. Requirements Functional Areas Finance and Accounting areas. 2.2 Functional Requirements Development Methodology This, and each of the other requirements projects went through 1. Plan Project a similar process to gather, map, write, and validate 2. Develop Processes requirements. Each project developed its own detailed work 3. Identify and Gather Requirements, plan and detailed schedule taking into consideration their Business Rules, and Best Practices 4. Perform Mapping scope, priorities, and available resources. The SMEs were 5. Perform Initial Validation enlisted to help select those requirements that should be 6. Validate and Write Requirements standardized, and they wrote additional requirements where the 7. Deliver Release 6.0 Requirements and level of detail of those requirements initially gathered was not Documentation to Director, Shared sufficient. The numerical order of the tasks in Table 2 Services for Approval indicates the approximate sequence of events. Table 2. High Level Development Tasks 2.3 Requirement Identification Format The requirements are uniquely identified by a combination of letters and numbers broken down into several parts. The first part is shown by letters followed by a dash (-) that identifies which functional areas 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 4 Formally, this document is entitled DFAS 7900.4-G, A Guide to Federal Requirements to Financial Management Systems, Feb., 2009. Informally, this book is sometimes referred to as the Blue Book. 5
    • to a parental requirement. As an example, XX-0001.01.01 requirement number will be used as a reference. XX-0001.01.01: 2 position identifier that delineates functional areas XX- 0001.01.01: Indicates this as requirement number 1 of the functional areas XX-0001.01.01: First child of parental requirement number 1 XX-0001.01.01: First child of child requirement number 1 6
    • 3.0Accounts Payable (Public) Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Accounts Payable (Public). To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Accounts Payable (Public) functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Accounts Payable (Public) SMEs were invited to participate in a series of Joint Application Development (JAD) sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Accounts Payable (Public) Working Group determined what additional processes were needed. The group then identified gaps within the Accounts Payable (Public) process models and steps. The Accounts Payable (Public) Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 3.1 Accounts Payable (Public) Functional Overview Functional requirements developed for Accounts Payable (Public) are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Accounts Payable (Public) business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage Liabilities), BEA process name (e.g. Manage Execution Fund Account) and the DFAS process name (e.g. Manage Prevalidation Requests). It should be noted that only the process steps associated with Accounts Payable (Public) are being addressed by this document. Therefore, in some instances, the incorporated business 7
    • process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Accounts Payable (Public) requirements defined to date. The following process models are included: →Acknowledge Goods Tendered →Perform Acceptance Procedures →Validate Invoice →Manage Liabilities * →Manage Entitlement →Process Payment Request →Calculate Entitlement →Manage Funds Validation →Manage Execution Fund Account** →Manage Payment Confirmation and Follow-Up →Process Collections Against Entitlement * The Manage Liabilities process model incorporated into this document is a subset of the BEA Manage Liabilities model and reflects the initial steps to Evaluate Liabilities Information and Establish Accounts Payable. It was also expanded to incorporate additional steps required in the processing of Accounts Payable transactions not currently depicted in the BEA. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions. ** The Manage Execution Fund Account process model incorporated into this document is an expanded version of the BEA Manage Execution Fund Account model. It reflects the process steps to be added to support the Entitlement process. In order to make for a more manageable grouping of requirements, 12 Accounts Payable process areas were selected based on subchapters of the Accounts Payable (Payment Management) in the DFAS 7900.4G - Blue Book. In addition, these areas were supported by The Federal Acquisition Regulations (FAR), Defense Federal Acquisition Regulations Supplement (DFARS), and the Financial Management Regulation (FMR). The AP Project contained seven phases in Release 3.0, December 18, 2007. As each Release was updated, it was annotated in the Release/ Version Control History table at the beginning of the document. Release 3.0 added the process review and validation of functional requirements for Intra- governmental as well as a review and inclusion of the USSGL Accounting Transaction Categories to the previous releases/versions of: Receipt, Acceptance, and Recognition (Release 1.0), Managing Entitlements (Version 1.1), Invoices, Payment Terms and Prevalidation (Version 1.2); Transportation, Miscellaneous, and Scheduling Payments (Version 1.3); Workflow, Internal Controls, and Reports (Version 1.4); Accounting (Release 2.0); and Intra-governmental (Release 3.0) requirements and process areas. Release 5.0 includes revised BEA 6.0 0V-6c process model for Manage Entitlement to the new Manage Supply Chain Entitlement and it’s newly created sub-processes: Calculate Supply Chain Entitlement, Prepare Certified Business Partner Payment, Manage Scheduled Payments, and 8
    • Monitor Payments. Accounts Payable cross-walked the functional requirements and business process models to the new BEA 6.0 0V-6c model for Manage Supply Chain Entitlement. The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Accounts Payable (Public) working group and SMEs. In addition to the new requirements for Intra-governmental transactions, requirements and processes from previous versions have been further refined. The requirements contained within the spreadsheet are grouped and sorted based on the business process model to which they apply. Combined, they define a set of standard processes that will optimize the effectiveness and efficiency of Accounts Payable operations throughout DoD. Upon completion of this project, this document will also provide a comprehensive repository of Accounts Payable requirements for future system development efforts. 3.2 Accounts Payable (Public) Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Accounts Payable (Public) DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 3.3 Release 6.0 Scope 3.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 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 touch points between the functions. 3.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 3.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Accounts Payable (Public). These requirements were identified and considered for inclusion in another team’s functional requirements. 3.3.5 Perform Team Quality Review of Requirements In Release 6.0 the functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality 9
    • 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.6 Develop Additional Process Models The Accounts Payable (Public) developed additional process models. 3.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 3.3.8 Compare Requirements to DoD Transaction Library There were Accounts Payable (Public) DoD Transaction Library requirements. The Accounts Payable (Public) requirements were compared to the DoD Transaction Library. Missing requirements were developed and included in the Accounts Payable (Public) database to encompass any gaps between the documents. The following requirements were not addressed in the DoD Transaction Library and need to be addressed in future revisions to the document: Accounts Payable (Public) requirements related to purchase returns, construction-in-progress, advances and prepayments, commitments/programs subject to apportionment, and expended/unexpended authority. These are business events that are not currently covered in the Treasury Financial Manual (TFM) but do occur within the DoD financial community and should result in transactions recorded in the General Ledger for DoD. 10
    • 4.0Accounts Receivable Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Accounts Receivable. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Accounts Receivable functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. Next, Accounts Receivable SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Accounts Receivable Working Group determined what additional processes were needed. The group then identified gaps within the Accounts Receivable process models and steps. The Accounts Receivable Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 4.1 Accounts Receivable Functional Overview Functional requirements developed for Accounts Receivable are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Accounts Receivable business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Order to Cash) and the BEA process name (e.g. Record and Manage Receivable). It should be noted that only the process steps associated with Accounts Receivable are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Accounts Receivable requirements defined to date. 11
    • The following process model is included: Record and Manage Receivable: - This process consists of three areas - Establish Receivable, Maintain Receivable and Apply Collection. The process involves the administration of monies owed to DoD. It includes recording the receivable, recognizing revenue earned, applying cash receipts and liquidating receivable. The Manage Receivable activity also includes billing, aging, dunning, write-off, adjustment, and the assessment of interest and penalties on outstanding receivable. 4.2 Accounts Receivable Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Accounts Receivable DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 4.3 Release 6.0 Scope 4.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 4.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 touch points between the functions. 4.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 4.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Accounts Receivable. These requirements were identified and considered for inclusion in another team’s functional requirements. 4.3.5 Perform Team Quality Review of Requirements In Release 6.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. 4.3.6 Develop Additional Process Models The Accounts Receivable Working Group did not develop additional process models. 12
    • 4.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 4.3.8 Compare Requirements to DoD Transaction Library There were Accounts Receivable DoD Transaction Library requirements. Functional requirements were mapped to the DoD transaction library and their associated general ledger effects. Shared Services reviewed, analyzed and updated requirements based upon the general ledger scenarios. The requirements were updated to include the DoD Transaction Code (DTC) contained in the DoD Transaction Library. All transaction library scenarios and their general ledger effects were reviewed for possible inclusion in the requirements. This ensured related general ledger debits and credits were linked to the associated functional requirements. 13
    • 5.0Audit Trails and System Controls Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Audit Trails and System Controls. To accomplish this mission it was necessary to map all requirements extracted from the authoritative sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the work group gathered existing Audit Trails and System Controls functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Audit Trails and System Controls SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate DFAS process flows/steps. 5.1 Audit Trails and System Controls Functional Overview Functional requirements developed for Audit Trails and System Controls are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model would be used as a starting point for the identification and development of more detailed Audit Trails and System Controls business processes. This includes identifying the BEA process diagrams, BEA process name, and the DFAS process name (e.g. Audit Trails). However, the BEA 6.0 does not provide business processes or diagrams for Audit Trails & System Controls. Therefore, the team developed a list of DFAS processes / activities. The following are areas and their related DFAS processes / activities: • Audit Trails o Audit Trails • Application Controls o Document and Transaction Control o Document Referencing and Modification o Workflow/Messaging o Document Management o Operations • General Controls o System-Generated Transactions o General Design/Architecture o Infrastructure o User interfaces 14
    • o Interoperability o Internet access o Security o Ad-hoc query o Documentation o System performance Because of ATSC pervasiveness to all business processes, it is impractical to develop models. Therefore, the processes / activities are identified within the functional requirements however, no process models were created. 5.2 Audit Trails and System Controls Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Audit Trails and System Controls DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 5.3 Release 6.0 Scope 5.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 5.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 touch points between the functions. 5.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 5.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Audit Trails and System Controls. These requirements were identified and considered for inclusion in another team’s functional requirements. 5.3.5 Perform Team Quality Review of Requirements In Release 6.0, the functional branches continuously performed internal team review 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. 15
    • 5.3.6 Develop Additional Process Models Audit Trails and System Controls did not develop additional process models for Release 6.0. 5.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 5.3.8 Compare Requirements to DoD Transaction Library The Audit Trails and System Controls requirements were not compared to the DoD Transaction Library since Audit Trails and System Controls does not create transactions. 16
    • 6.0Benefits Concept of Operation In May 2009, the SSD was tasked to establish a set of functional requirements for Benefits. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Benefits functional requirements from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process. Next, Benefits SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Benefits Working Group determined what additional processes were needed. The group then identified gaps within the Benefits process models and steps. The Benefits Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps. 6.1 Benefits Functional Overview Functional requirements developed for Benefits are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Benefits business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage Benefits), BEA process name (e.g. Manage Benefits) and the DFAS process name (e.g. Claims Acceptance and Tracking). It should be noted that only the process steps associated with Benefits are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Benefits requirements defined to date. 17
    • The following process models are included: Manage Benefits: This process supports DoD Quality of Life Programs as well as benefit eligibility, enrollment, termination and reporting. It includes provision of Morale, Welfare, and Recreation Programs (including Chaplain programs, commissary, exchange, and other Non- Appropriated Fund (NAF) operations). The process is associated with providing military Health programs and supporting individual elections of medical, dental, life, and long term insurance; pension/retirement programs; flexible spending programs; disability benefits; military housing; educational benefits; savings management (Thrift/Bonds). 6.2 Benefits Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Benefits DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 6.3 Release 6.0 Scope 6.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 6.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 touch points between the functions. 6.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 6.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Benefits. These requirements were identified and considered for inclusion in another team’s functional requirements. 6.3.5 Perform Team Quality Review of Requirements In Release 6.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. 18
    • 6.3.6 Develop Additional Process Models The Benefits developed additional process models for Release 6.0. 6.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 6.3.8 Compare Requirements to DoD Transaction Library The Benefits requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 19
    • 7.0Cash Accountability Concept of Operation In October, 2006, the SSD was tasked to establish a set of functional requirements for Cash Accountability. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Cash Accountability functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. Next, Cash Accountability SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. Cash Accountability functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting to make certain each functional requirement could be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. The Cash Accountability Working Group mapped the standard functional requirements to the applicable BEA process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate BEA process flows/steps for Release 6.0. 7.1 Cash Accountability Functional Overview Functional requirements developed for Cash Accountability are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Send Statement of Accountability or Transactions or Trial Balance to Treasury) and BEA process name (e.g. Manage Execution with Treasury). It should be noted that only the process steps associated with Cash Accountability are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Cash Accountability requirements defined to date. 20
    • Release 6.0 contains the following process models: →Send Statement of Accountability or Transactions or Trial Balance to Treasury →Reconcile Undisbursed Expenditure Account Ledger →Generate Correcting Pro Forma Entries →Verify Information →Reconcile Deposits →Document Results of Reconciliation →Manage Execution with Treasury →Capture Treasury Confirmation Data →Capture Treasury Statements →Reconcile Disbursements →Create Anomaly Explanation The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Cash Accountability working group and SMEs. Upon completion of this project, a comprehensive repository of Cash Accountability requirements will be available for future system development efforts. 7.2 Cash Accountability Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Cash Accountability DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 7.3 Release 6.0 Scope 7.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 7.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 touch points between the functions. 7.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 21
    • 7.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Cash Accountability. These requirements were identified and considered for inclusion in another team’s functional requirements. 7.3.5 Perform Team Quality Review of Requirements In Release 6.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. 7.3.6 Develop Additional Process Models Cash Accountability did not develop additional process models for Release 6.0. 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. 7.3.7 Close Out Open Issues Issues identified during Release 6.0 and previous releases were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 7.3.8 Compare Requirements to DoD Transaction Library The Cash Accountability requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 22
    • 8.0Direct Loan Concept of Operation In May 2009, the SSD was tasked to establish a set of functional requirements for Direct Loans. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Direct Loan functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process. Next, Direct Loan SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Direct Loan Working Group determined what additional processes were needed. The group then identified gaps within the Direct Loan process models and steps. The Direct Loan Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 8.1 Direct Loan Functional Overview Functional requirements developed for Direct Loan are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Direct Loan business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Record Loans and Grants), BEA process name (e.g. Record Loans and Grants) and the DFAS process name (e.g. Application Screening). It should be noted that only the process steps associated with Direct Loans are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Direct Loan requirements defined to date. 23
    • The following process model is included: Record Loans and Grants - This process records the financial impact of business events related to the award, origination, performance, payment, collection and closeout of direct loans, loan guarantees and grants 8.2 Direct Loan Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Direct Loan DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 8.3 Release 6.0 Scope 8.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 8.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 touch points between the functions. 8.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 8.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Direct Loan. These requirements were identified and considered for inclusion in another team’s functional requirements. 8.3.5 Perform Team Quality Review of Requirements In Release 6.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. 8.3.6 Develop Additional Process Models The Direct Loan team developed additional process models for Release 6.0. 24
    • 8.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 8.3.8 Compare Requirements to DoD Transaction Library The Direct Loan requirements were not compared to the DoD Transaction Library during Release 6.0. The DTCs will be mapped to the test scenarios. Then the requirements will be updated with the DTC information in a maintenance release. 25
    • 9.0Disbursing Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Disbursing. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Disbursing functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Disbursing SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. Disbursing functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Disbursing Working Group determined what additional processes were needed. The group then identified gaps within the Disbursing process models and steps. The Disbursing working group then mapped the standard Disbursing functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 9.1 Disbursing Functional Overview Functional requirements developed for Disbursing are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Disbursing business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process diagram (e.g. Manage Disbursements), BEA process name (e.g. Cancel Payments) or the DFAS diagram name (e.g. Disbursing Accountability). As an incremental project, the Disbursing FRD expanded with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document was a cumulative document, and incorporated all functional requirements mapped to applicable processes which were finalized with Release 6.0. The process models continued to be refined in 26
    • later versions of the FRD as additional requirements were identified and existing requirements were assessed in detail. It should be noted that only the process steps associated with Disbursing are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Disbursing requirements defined to date. Release 6.0 contains the following process models: →Manage Disbursements Cancel Payments Convert United Sates Dollar Equivalent to Foreign Equivalent Create Check Print File Create Electronic Fund Transfer File Disburse Disburse Cash Issue Cancel Payment Notice Manage Returned Payments Prepare Paid Disbursement Voucher Process IPAC Reject Ready-To-Pay File Information Return Cancel Payment Request Validate Cancel Payment Request Information Validate Ready-To-Pay File Information →Manage Collections Add Voucher to Collection Voucher Control Log Collect Prepare Advice of Collection Prepare Deposit Ticket & Advice of Collection Prepare Collection Voucher & Deposit Receive Collection Receipts Receive Debit Vouchers Receive Other Receipts →Manage Execution with Treasury Reconcile Disbursements Reconcile Deposits The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Disbursing working group and SMEs. Requirements and processes from previous versions have been further refined. The requirements contained within the spreadsheet are grouped and sorted based on the business process model to which they apply. Combined, they define a set of standard processes that will optimize the effectiveness and efficiency of Disbursing operations 27
    • throughout DoD. Upon completion of this project, a comprehensive repository of Disbursing requirements will be available for future system development efforts. 9.2 Disbursing Practices The requirements were developed for all systems and business operations to be compliant with the Disbursing DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 9.3 Release 6.0 Scope 9.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 9.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 touch points between the functions. 9.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 9.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Disbursing. These requirements were identified and considered for inclusion in another team’s functional requirements. 9.3.5 Perform Team Quality Review of Requirements In Release 6.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. 9.3.6 Develop Additional Process Models The Disbursing working group modified the DFAS process models which were previously delivered going from three to two. For Release 4.0, the DFAS process models were Reconcile Disbursing Officers Accountability; Disbursing Administration, Management & Oversight; and Manage Returned Payments. At the completion of Version 6.0, the DFAS Activities are Disbursing Accountability and Disbursing Administration, Management & Oversight. The previously released Reconcile Disbursing Officers Accountability is now Disbursing 28
    • Accountability. There was no change to Disbursing Administration, Management & Oversight. The Manage Returned Payments was incorporated into the BEA 6.0 Activity Manage Disbursement process diagram. 9.3.7 Close Out Open Issues Issues identified during Release 6.0 and previous releases were documented and tracked in the issue tracking tool until resolution. Those issues that were not resolved by the FMCoE staff were transferred to the office that has responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool. 9.3.8 Compare Requirements to DoD Transaction Library The Disbursing requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 29
    • 10.0Field Level Reporting Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Field Level Reporting. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. Field Level Reports can be either mandatory reports in compliance with regulatory requirements or discretionary reports in support of other requirements. The scope of this project is limited to mandatory reports as listed in Table 3. The end product will also concentrate on ensuring requirements produce standardized Field Level Reports throughout DFAS to ensure complete and timely financial data. Field Level Reports International Balance of Payments (IBOP) Forest Product Sales Program Reports • Actual Revenue and Obligation RCS: DD-A&T(Q&A) 1649 • Quarterly Forest Products Program DD-A&T(Q&A) 1649 • Annual Forest Products Program Budget DD-A&T(Q&A) 1649 Monthly Receivables Data (MRD) Report Foreign Currency Fluctuations, Defense Report (DD-COMP(M)) 1506 Foreign Currency Fluctuations, Construction, Defense Report (DD-COMP(M)) 1761 Current Status of Accounts Receivable from Foreign Obligors Table 3 - Field Level Reports First, the Field Level Reporting Internal Work Group (IWG) requested a list of current field level reports from Standards & Compliance (S&C). The IWG reviewed the list of reports provided by S&C to validate the authoritative sources and it applicability across the entire DFAS accounting network. The list of reports in Table 1 was derived from this analysis. Next, the IWG gathered existing Field Level Reporting functional requirements and business rules from available authoritative sources. These requirements were analyzed, mapped to Field Level Reports, and pre-validated by the IWG. Next, a selected set of Field Level Reporting SMEs were invited to JAD sessions to review and validate the requirements for applicability as a DoD standard in each Field Level Report. The Field Level Reporting functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting results when each functional requirement is implemented in the financial reporting system. At the completion of each JAD session, the IWG reviewed the comments and new requirements and prepared issues where needed. The SMEs re-convened to validate the updated documentation. As issues were uncovered, they were documented, analyzed, and worked toward resolution. 30
    • 10.1Field Level Reporting Functional Overview Functional requirements developed for Field Level Reporting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Field Level Reporting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Capture Financial Transaction Report), BEA process name (e.g. Perform Financial Reporting) and DFAS process name (e.g. Management Report). It should be noted that only the process steps associated with Field Level Reporting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Field Level Reporting requirements defined to date. The following process models are included: Perform Financial Reporting: The Perform Financial Reporting model describes how DoD will develop and release their Financial Statements. Prior to developing the Financial Statement all of the financial transactions must be consolidated from the subsidiaries and necessary adjustments must be made to close the General Ledger. Once this is complete all of the agencies Ledgers will be compiled and a corporate view will be generated. Elimination entries will occur and anomaly explanation reports will be developed. After all compilations and eliminations are complete the Financial Statements and Footnotes will be created and sent to the internal auditors for review. Once the review and necessary adjustments are made the Final Financial Statements and briefing package will be made and released. 10.2Field Level Reporting Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Field Level Reporting DoD financial and accounting requirements. In addition, sample report formats are provided for each of the Field Level Reports as Attachment 1 to this FRD. By complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 10.3Release 6.0 Scope 10.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 31
    • 10.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 touch points between the functions. 10.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 10.3.4 Assign Rejected Requirement to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Field Level Reporting. These requirements were identified and considered for inclusion in another team’s functional requirements. 10.3.5 Perform Team Quality Review of Requirements In Release 6.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. 10.3.6 Develop Additional Process Models Field Level Reporting did not develop additional process models. 10.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 10.3.8 Compare Requirements to DoD Transaction Library The Field Level Reporting requirements were not compared to the DoD Transaction Library since Field Level Reporting does not create transactions. 32
    • 11.0Financial Reporting Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Financial Reporting. To accomplish this mission it was necessary to map all requirements extracted from the authoritative sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the work group gathered existing Financial Reporting functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Financial Reporting SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Financial Reporting Working Group determined what additional processes were needed. The group then identified gaps within the Financial Reporting process models and steps. The Financial Reporting Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 11.1Financial Reporting Functional Overview Functional requirements developed for Financial Reporting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Financial Reporting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Capture Financial Transaction Report), BEA process name (e.g. Perform Financial Reporting), and the DFAS process name (e.g. Manage Financial Reporting Requirement). It should be noted that only the process steps associated with Financial Reporting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model 33
    • are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Financial Reporting requirements defined to date. The following is one of the process models that are included: Perform Financial Reporting: The Perform Financial Reporting model describes how DoD will develop and release their Financial Statements. Prior to developing the Financial Statement all of the financial transactions must be consolidated from the subsidiaries and necessary adjustments must be made to close the General Ledger. Once this is complete all of the agencies Ledgers will be compiled and a corporate view will be generated. Elimination entries will occur and anomaly explanation reports will be developed. After all compilations and eliminations are complete the Financial Statements and Footnotes will be created and sent to the internal auditors for review. Once the review and necessary adjustments are made the Final Financial Statements and briefing package will be made and released. 11.2Financial Reporting Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Financial Reporting DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 11.3Release 6.0 Scope 11.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 11.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 touch points between the functions. 11.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 11.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Financial Reporting. These requirements were identified and considered for inclusion in another team’s functional requirements. 11.3.5 Perform Team Quality Review of Requirements In Release 6.0, the functional branches continuously performed internal team review of the requirements to ensure that all functional requirements adhered to the following quality 34
    • 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. 11.3.6 Develop Additional Process Models Financial Reporting did not develop additional process models for Release 6.0. 11.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 11.3.8 Compare Requirements to DoD Transaction Library The Financial Reporting requirements were not compared to the DoD Transaction Library since Financial Reporting does not create transactions. 35
    • 12.0Foreign Military Sales Concept of Operation In July 2009, the SSD was tasked to establish a set of functional requirements for Foreign Military Sales. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Foreign Military Sales functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. The working group also documented the standard DFAS process. Next, Foreign Military Sales SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Foreign Military Sales Working Group determined what additional processes were needed. The group then identified gaps within the Foreign Military Sales process models and steps. The Foreign Military Sales Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 12.1Foreign Military Sales Functional Overview Functional requirements developed for Foreign Military Sales are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Foreign Military Sales business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Accounts Payable/Accounts Receivable), BEA process name (e.g. Conduct Payables/Conduct Receivables) and the DFAS process name (e.g. Foreign Military Sales). It should be noted that only the process steps associated with Foreign Military Sales are being addressed by this document. Therefore, in some instances, the incorporated business process 36
    • models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Foreign Military Sales requirements defined to date. The FMS process is unique in that a majority of FMS requirements resides in Accounts Payable, Accounts Receivable, Financial Reporting, Funds Control and Budgetary Accounting, General Ledger, and Managerial Cost Accounting. Another portion of the FMS unique financial requirements are performed by DFAS-IN and Defense Contract Management Agency (DCMA) and not in the ERPs. 12.2Foreign Military Sales Practices The requirements in the database were developed for all systems and business operations to be compliant with the Foreign Military Sales DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 12.3Release 6.0 Scope 12.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 12.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 touch points between the functions. 12.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 12.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Foreign Military Sales. These requirements were identified and considered for inclusion in another team’s functional requirements. 12.3.5 Perform Team Quality Review of Requirements In Release 6.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. 37
    • 12.3.6 Develop Additional Process Models The Foreign Military Sales developed additional process models for Release 6.0. 12.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 12.3.8 Compare Requirements to DoD Transaction Library The Foreign Military Sales transactions were not compared to the DoD Transaction Library since Foreign Military Sales does not create transactions. 38
    • 13.0Funds Control and Budgetary Accounting Concept of Operation In October 2008, the SSD was tasked to establish a set of functional requirements for Funds Control and Budgetary Accounting. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Funds Control and Budgetary Accounting functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Funds Control and Budgetary Accounting SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. However, SMEs were not available for this release. From the BEA diagrams, the Funds Control and Budgetary Accounting Working Group determined what additional processes were needed. The group then identified gaps within the Funds Control and Budgetary Accounting process models and steps. The Funds Control and Budgetary Accounting Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements and business rules mapped to the appropriate process flows/steps. 13.1Funds Control and Budgetary Accounting Functional Overview Functional requirements developed for Funds Control and Budgetary Accounting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Funds Control and Budgetary Accounting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Financial Visibility) and BEA process name (e.g. Perform Planning, Programming, Budgeting, Funds Distribution and Control). It should be noted that only the process steps associated with Funds Control and Budgetary Accounting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Funds Control and Budgetary Accounting requirements defined to date. 39
    • The following process models are included: • Execute Apportionment and Allocate Funds • Execute Continuing Resolution • Manage Report of Programs • Manage Execution Fund Account • Perform Budgeting • Perform Reprogramming and Transfers • Execute Rescission, Cancellation and Deferrals • Financial Visibility • Manage Execution Fund Account • Post General Ledger • Manage General Ledger • Perform Financial Reporting 13.2Funds Control and Budgetary Accounting Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Funds Control and Budgetary Accounting DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 13.3Release 6.0 Scope 13.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 13.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 touch points between the functions. 13.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 13.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Funds Control and Budgetary Accounting. These requirements were identified and considered for inclusion in another team’s functional requirements. 40
    • 13.3.5 Perform Team Quality Review of Requirements In Release 6.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. 13.3.6 Develop Additional Process Models The Funds Control and Budgetary Accounting did not develop additional process models. 13.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 13.3.8 Compare Requirements to DoD Transaction Library The Funds Control and Budgetary Accounting requirements were compared to the DoD Transaction Library. Missing requirements were developed and included to encompass any gaps between the documents. 41
    • 14.0General Ledger Concept of Operation In October, 2006, the SSD was tasked to establish a set of functional requirements for 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 BEA model and identify any gaps if they existed. 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 to include Interfund and Intragovernmental Payment and Collection (IPAC), 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 & Budget and Funds Distribution & Internal Controls are also out of scope. These functional requirements apply to both general funds and working capital funds. First, the working 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. The General Ledger Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. Next, General Ledger SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. At the completion of the JAD session, the General Ledger working 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 and 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. 42
    • 14.1General Ledger Functional Overview Functional requirements developed for General Ledger are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed General Ledger business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Post General Ledger Transactions) and BEA process name (e.g. Post to General Ledger). It should be noted that only the process steps associated with General Ledger are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the General Ledger requirements defined to date. The following process models are included: Manage Financial Management Policy: The Manage Financial Management Policy process begins from receiving a new requirement from an internal or external customer. The process determines whether notification to the OUSD(C) is required or not. The requirements are then analyze to identify proposals for implementation. Control Board approval is required for changes to the Chart of Accounts, SFIS Attributes, Pro Forma Entries or Calendar. There should be relevant coordination within DoD prior to processing the policy changes. Manage General Ledger: This process includes the ability to record financial transactions as updates to specific proprietary, budgetary, and memorandum general ledger accounts in accordance with Federal Accounting Standard Advisory Board (FASAB) standards, General Accepted Accounting Principles (GAAP) and regulatory requirements; to define the use of, and rules to, control General Ledger accounts; and to conduct General Ledger analyses and reconciliations. Perform Financial Reporting: The Perform Financial Reporting model describes how DoD will develop and release their Financial Statements. Prior to developing the Financial Statement all of the financial transactions must be consolidated from the subsidiaries and necessary adjustments must be made to close the General Ledger. Once this is complete all of the agencies Ledgers will be compiled and a corporate view will be generated. Elimination entries will occur and anomaly explanation reports will be developed. After all compilations and eliminations are complete the Financial Statements and Footnotes will be created and sent to the internal auditors for review. Once the review and necessary adjustments are made the Final Financial Statements and briefing package will be made and released. Post to General Ledger: This process model describes how DoD will account for all of their journal entries. The process captures all of the pro forma entries, which collects all of the un- posted charge/credits or cash receipts from the subsidiary ledgers, either by batch number or by entry date and then generates the transactions that will be placed into the General Ledger. Once all of the transactions are developed they will be summarized by account and optionally 43
    • by charge/credit code, and then adds them to the General Ledger with the corresponding credit and debit amounts. This posting maintains a complete audit trail of all transactions within DoD and records the business events and reports the financial condition of the Department of Defense. 14.2General Ledger Practices The requirements in the accompanying spreadsheet were developed to allow the DoD financial community the ability to record proprietary and budgetary general ledger 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 general ledger 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 the general ledger provides enhanced audit ability 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 U.S. Standard General Ledger (USSGL) Transaction Library in an attempt to identify the business events that are unique to the DoD 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. 14.3Release 6.0 Scope 14.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 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. 14.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 touch points between functions. 14.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 14.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for General Ledger. These requirements were identified and considered for inclusion in another team’s functional requirements. 44
    • 14.3.5 Perform Team Quality Review of Requirements In Release 6.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. 14.3.6 Develop Additional Process Models General Ledger did not develop additional process models for Release 6.0. 14.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 14.3.8 Compare Requirements to DoD Transaction Library For Release 6.0, there were no General Ledger DoD Transaction Library requirements. However, as a part of Release 4.0, 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 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. 45
    • 15.0Guaranteed Loans Concept of Operation In May 2009, the SSD was tasked to establish a set of functional requirements for Guaranteed Loans. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Guaranteed Loans functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. The working group also documented the standard DFAS process. Next, Guaranteed Loans SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Guaranteed Loans Working Group determined what additional processes were needed. The group then identified gaps within the Guaranteed Loans process models and steps. The Guaranteed Loans Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 15.1Guaranteed Loans Functional Overview Functional requirements developed for Guaranteed Loans are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Guaranteed Loans business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage General Ledger), BEA process name (e.g. Record Loans and Grants) and the DFAS process name (e.g. Lender Eligibility Process). It should be noted that only the process steps associated with Guaranteed Loans are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model 46
    • are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Guaranteed Loans requirements defined to date. The following process models are included: Manage General Ledger - The ability to record financial transactions as updates to specific proprietary, budgetary, and memorandum general ledger accounts in accordance with Federal Accounting Standard Advisory Board standards, General Accepted Accounting Principles and regulatory requirements; to define the use of, and rules to, control General Ledger accounts; and to conduct General Ledger analyses and reconciliations. Record Loans and Grants - This process records the financial impact of business events related to the award, origination, performance, payment, collection and closeout of direct loans, loan guarantees and grants. 15.2Guaranteed Loans Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Guaranteed Loans DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 15.3Release 6.0 Scope 15.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 15.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 touch points between the functions. 15.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 15.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Guaranteed Loans. These requirements were identified and considered for inclusion in another team’s functional requirements. 15.3.5 Perform Team Quality Review of Requirements In Release 6.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, 47
    • singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision. 15.3.6 Develop Additional Process Models The Guaranteed Loans developed additional process models. 15.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 15.3.8 Compare Requirements to DoD Transaction Library The Guaranteed Loan transactions were not compared to the DoD Transaction Library during Release 6.0. The DTCs will be mapped to the test scenarios. Then the requirements will be updated with the DTC information in a maintenance release. 48
    • 16.0Human Resources and Payroll – Civilian Concept of Operation In November 2008, the SSD was tasked to establish a set of functional requirements for Human Resources and Payroll – Civilian. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Human Resources and Payroll – Civilian functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process. Next, Human Resources and Payroll – Civilian SMEs were invited to participate in a series of Joint Application Development (JAD) sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Human Resources and Payroll – Civilian Working Group determined what additional processes were needed. The group then identified gaps within the Human Resources and Payroll – Civilian process models and steps. The Human Resources and Payroll – Civilian Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 16.1Human Resources and Payroll – Civilian Functional Overview Functional requirements developed for Human Resources and Payroll – Civilian are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Human Resources and Payroll – Civilian business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process diagram (e.g. Personnel Visibility), BEA process name (e.g. Develop Human Resources) and the DFAS diagram name (e.g. Civilian Pay). 49
    • It should be noted that only the process steps associated with Human Resources and Payroll – Civilian are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Human Resources and Payroll – Civilian requirements defined to date. The following process models are included: Personnel Visibility: Personnel Visibility (PV) is a process defined as the fusion of accurate human resources information and secure, interoperable technology. PV is defined as having reliable information that provides visibility of military Service members, civilian employees, military retirees, contractors (in theater), and other U.S. personnel, across the full spectrum – during peacetime and war, through mobilization and demobilization, for deployment and redeployment, while assigned in a theater of operation, at home base, and into retirement. This includes ensuring timely and accurate access to compensation and benefits for DoD personnel and their families and ensuring that Combatant Commanders have access to the timely and accurate data on personnel and their skill sets. 16.2Human Resources and Payroll – Civilian Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Human Resources and Payroll – Civilian DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 16.3Release 6.0 Scope 16.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 16.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 touch points between the functions. 16.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 50
    • 16.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Human Resources and Payroll – Civilian. These requirements were identified and considered for inclusion in another team’s functional requirements. 16.3.5 Perform Team Quality Review of Requirements In Release 6.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. 16.3.6 Develop Additional Process Models The Human Resources and Payroll – Civilian developed additional process models. 16.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 16.3.8 Compare Requirements to DoD Transaction Library The Human Resources and Payroll – Civilian requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 51
    • 17.0Human Resources and Payroll – Military Concept of Operation In November 2008, the SSD was tasked to establish a set of functional requirements for Human Resources and Payroll – Military. First, the working group gathered existing Human Resources and Payroll – Military functional requirements from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems. The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps. 17.1Human Resources and Payroll – Military Functional Overview Functional requirements developed for Human Resources and Payroll – Military are driven by operational architecture and compliance requirements. The Human Resources and Payroll – Military functional requirements were not mapped to the BEA 6.0 OV-6c diagrams and processes, but will be in future releases. 17.2Human Resources and Payroll – Military Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Human Resources and Payroll – Military DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 17.3Release 6.0 Scope 17.3.1 Map Requirements to BEA Processes In Release 6.0, the requirements were not mapped within the BEA architecture. However, the team did map all functional requirements to the DFAS process. The mapping to BEA processes will occur within a future maintenance release. 17.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 touch points between the functions. 17.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 17.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Human Resources and Payroll – Military. These requirements were identified and considered for inclusion in another team’s functional requirements. 52
    • 17.3.5 Perform Team Quality Review of Requirements In Release 6.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. 17.3.6 Develop Additional Process Models The Human Resources and Payroll – Military did not develop additional process models. The team will document the DFAS processes in a future maintenance release. 17.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 17.3.8 Compare Requirements to DoD Transaction Library The Human Resources and Payroll – Military requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 53
    • 18.0Intra-governmental Concept of Operation In October 2006, the SSD was tasked to establish a set of functional requirements for Intra- governmental. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Intra-governmental functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre- validated by the working group. The working group also documented the standard DFAS process. Next, Intra-governmental SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From BEA diagrams, the Intra-governmental Working Group determined what additional processes were needed. The group then identified gaps within the Intra-governmental process models and steps. The Intra-governmental Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 18.1Intra-governmental Functional Overview Functional requirements developed for Intra-governmental are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Intra-governmental business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. Since Intra-governmental is contained within multiple areas such as Accounts Payable and Accounts Receivable, there is no specific BEA Intra- governmental diagram. The requirements contained within, represent a set of standard requirements that will optimize the effectiveness and efficiency of Intra-governmental Buyer and Seller operations throughout DoD. These standard functional requirements will also provide a comprehensive repository of Intra-governmental requirements for future system development efforts. 54
    • 18.2Intra-governmental Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Intra-governmental DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 18.3Release 6.0 Scope 18.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 18.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 touch points between the functions. 18.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 18.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Intra- governmental. These requirements were identified and considered for inclusion in another team’s functional requirements. 18.3.5 Perform Team Quality Review of Requirements In Release 6.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. 18.3.6 Develop Additional Process Models The Intra-governmental developed an additional DFAS process model. 18.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 55
    • 18.3.8 Compare Requirements to DoD Transaction Library Functional requirements were mapped to the DoD transaction library and their associated general ledger affects. Shared Services reviewed, analyzed and updated requirements based upon general the ledger scenarios. The requirements were updated to include the 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. The Intra-governmental requirements were compared to the DoD Transaction Library. Missing requirements were developed and included in the Intra-governmental Transactions database to encompass any gaps between the documents. 56
    • 19.0Intra-Governmental Eliminations Concept of Operation In November 2008, the SSD was tasked to establish a set of functional requirements for Intra- Governmental Eliminations. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Intra-Governmental Eliminations functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Intra-Governmental Eliminations SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the Intra-Governmental Eliminations Working Group determined what additional processes were needed. The group then identified gaps within the Intra-Governmental Eliminations process models and steps. The Intra-Governmental Eliminations Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 19.1Intra-Governmental Eliminations Functional Overview Functional requirements developed for Intra-Governmental Eliminations are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Intra-Governmental Eliminations business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the intra-governmental elimination processes were identified, the functional requirements were mapped to a DFAS process diagram developed by the Working Group. It should be noted that only the process steps associated with Intra-Governmental Eliminations are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an 57
    • indication that they are not applicable to the Intra-Governmental Eliminations requirements defined to date. The following DFAS process model is included: DFAS Elimination Process - The DFAS Elimination Process Model is intended to demonstrate the flow of intra-governmental transactions between field level accounting offices, departmental accounting offices and OMB/Treasury. 19.2Intra-Governmental Eliminations Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Intra-Governmental Eliminations DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. A current DoD accounting system has not been put into place to identify IG transactions for elimination. As a result, the multiple accounting systems in use by DoD do not capture and maintain all of the data required for balancing accounts, or capture the data in a standard format that permits easy cross-referencing. These accounting systems do not capture trading partner information at the transaction level; therefore, current systems cannot identify those transactions to be eliminated for reporting purposes. Currently, eliminations are done at the entity code level and reported through the Defense Departmental Reporting System (DDRS). Interfaces between the various accounting systems and DDRS are manual and accomplished through a business practice of data calls, journal vouchers, crosswalk tables, and an import spreadsheet. The level of detail is determined by the users and customers and varies significantly. The elimination of Intra-governmental transactions is currently accomplished by forcing the buyer’s books to match the seller’s. The future or “to-be” environment shall contain the proper data elements such as Business Partner Number (BPN) and common document number (linking buyer to seller) to process, trace, and eliminate Intra-Governmental transactions. It shall also have the capability to accept files or data from an accounting entitlement system, or ERP module. It will compare, match, or suspend transactions (or business processes) that fail validation. The system must also allow interface or online entry of customer and line of accounting data, order and bill data, access controls, internal controls, and business process suspension when the corresponding buyer/seller transactions are not in balance. The buyer/seller must be linked from end-to-end upon establishment of the buyer/seller agreement. All Standard Financial Information Structure (SFIS) mandatory data elements will be used, and a drill down reporting capability will exist on all data elements relevant to analysis, research, and reporting. The functional requirements shall enable the processing and facilitation of proper elimination at all levels of Intra-governmental transactions. Until end-state, when ERP systems are integrated, the DoD will provide seller reports to buyers and reconcile and balance Intra-Governmental transactions as instructed in TFM Bulletin 07-03. 19.3Release 6.0 Scope 19.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the 58
    • requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 19.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 touch points between the functions. 19.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 19.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Intra- Governmental Eliminations. These requirements were identified and considered for inclusion in another team’s functional requirements. 19.3.5 Perform Team Quality Review of Requirements In Release 6.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. 19.3.6 Develop Additional Process Models The Intra-Governmental Eliminations Working Group developed additional process. 19.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 19.3.8 Compare Requirements to DoD Transaction Library Intra-Governmental Elimination transactions do not impact General Ledger accounts. General Ledger accounts are impacted at the time an accounting transaction is initially input. Intra- Governmental Elimination transactions merely separate previously recorded intra-governmental accounting transactions from public accounting transactions for reporting purposes. Because of this, the Intra-Governmental Elimination requirements were not compared to the DoD Transaction library. 59
    • 20.0Inventory, Operating Materials and Supplies, and Stockpile Materials Concept of Operation In May 2009, the SSD was tasked to establish a set of functional requirements for IOMSSM. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing IOMSSM functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, IOMSSM SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The IOMSSM functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. Since no issues materialized, no issue papers were written and a JAD session was not held. From the BEA diagrams, the IOMSSM Working Group determined the DFAS processes that were needed. The group then identified gaps within the IOMSSM process models and steps. The IOMSSM working group then mapped the standard IOMSSM functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps for Release 6.0. 20.1Inventory, Operating Materials and Supplies, and Stockpile Materials Functional Overview This project includes the recording and reporting of IOMSSM financial information outside the core financial system. Functional requirements developed for IOMSSM are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process, diagram, and activity. IOMSSM is part of the Property and Material activity in the BEA. Even IOMSSM encompasses both Financial Visibility and Material Visibility diagrams within BEA Property and Materiel activity, the requirements in this project only impact Financial Visibility. 60
    • 20.2Inventory, Operating Materials and Supplies, and Stockpile Materials Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the IOMSSM DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 20.3Release 6.0 Scope 20.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. The IOMSSM working group gathered the business rules from the BEA 6.0. 20.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 touch points between the functions. 20.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 20.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for IOMSSM. These requirements were identified and considered for inclusion in another team’s functional requirements. 20.3.5 Perform Team Quality Review of Requirements In Release 6.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. 20.3.6 Develop Additional Process Models The IOMSSM did not develop additional process models. 20.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 61
    • 20.3.8 Compare Requirements to DoD Transaction Library The IOMSSM requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 62
    • 21.0Managerial Cost Accounting Concept of Operation In October 2008, the SSD was tasked to establish a set of functional requirements for MCA. 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 working group gathered existing MCA functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, MCA SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. From the BEA diagrams, the MCA Working Group determined what additional processes were needed for MCA. The group then identified gaps within the MCA process models and steps. BTA and the MCA working group then mapped the standard MCA functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps for Version 1.0. 21.1Managerial Cost Accounting Functional Overview Functional requirements developed for MCA are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed MCA business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Perform Managerial Cost Accounting), BEA process name (e.g. Define Cost Performance Model) and the DFAS process name (e.g. Identify Costs). As an incremental project, the MCA FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable 63
    • processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail. It should be noted that only the process steps associated with MCA are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the MCA requirements defined to date. Release 6.0 contains the following process models: →Perform Managerial Cost Accounting →Define Cost Performance Model* →Populate Cost Performance Model** →Perform Cost Analysis*** * The Define Cost Performance Model process incorporated into this document is a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Define Cost Performance Model and establishes Managerial Cost Accounting. Define Cost Performance Model is further broken down into DFAS lower-level processes: Identify Costs, Assign Costs, and Maintain Cost Information. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions. ** The Populate Cost Performance Model process incorporated into this document is also a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Populate Performance Model. Populate Cost Performance Model is further broken down into DFAS lower-level processes: Accumulate Costs, Distribute Costs, Record Costs, Allocate Costs, and Send/Transfer Costs. *** The Perform Cost Analysis process incorporated into this document is also a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Perform Cost Analysis. Perform Cost Analysis is further broken down into DFAS lower-level processes: Calculate Costs, Produce/Provide Costs, Reconciliation Costs, and Capture Costs. 21.2Managerial Cost Accounting Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the MCA DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 21.3Release 6.0 Scope 21.3.1 Map Requirements to BEA Processes The Shared Services completed integration or cross-function validation of the functional requirements. 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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 64
    • 21.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 touch points between the functions. 21.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through March 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 21.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for MCA. These requirements were identified and considered for inclusion in another team’s functional requirements. 21.3.5 Perform Team Quality Review of Requirements 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. 21.3.6 Develop Additional Process Models The MCA team developed additional process models. 21.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 21.3.8 Compare Requirements to DoD Transaction Library The MCA were not compared to the DoD Transaction Library since MCA does not create transactions. 65
    • 22.0Property, Plant, and Equipment Concept of Operation In May 2009, the SSD was tasked to establish a set of functional requirements for Property, Plant, and Equipment. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Property, Plant, and Equipment functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Property, Plant, and Equipment SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. Since no issues materialized, no issue papers were written and a JAD session was not held. From the BEA diagrams, the Property, Plant, and Equipment Working Group determined the DFAS processes that were needed. The group then identified gaps within the Property, Plant, and Equipment process models and steps. The Property, Plant, and Equipment working group then mapped the standard Property, Plant, and Equipment functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements and business rules mapped to the appropriate process flows/steps. 22.1Property, Plant, and Equipment Functional Overview This project includes the recording and reporting of Property, Plant, Equipment, Seized Property, and Forfeited Assets financial information outside the core financial system. Functional requirements developed for Property, Plant, and Equipment are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Property, Plant, and Equipment business processes. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process, diagram, and activity. Property, Plant, and Equipment is part of the Property and Material activity in the BEA. Property, Plant, and Equipment 66
    • encompasses both Financial Visibility and Material Visibility diagrams within BEA Property and Materiel activity, the requirements in this project only impact Financial Visibility. 22.2Property, Plant, and Equipment Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Property, Plant, and Equipment DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 22.3Release 6.0 Scope 22.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. The working group gathered the business rules from the BEA 6.0. 22.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 touch points between the functions. 22.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 22.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 includes requirements that were reclassified as being out of scope for Property, Plant, and Equipment. These requirements were identified and considered for inclusion in another team’s functional requirements. 22.3.5 Perform Team Quality Review of Requirements In Release 6.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. 22.3.6 Develop Additional Process Models The Property, Plant, and Equipment Working Group did not develop additional process models. 22.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE staff were transferred to the 67
    • office that had responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool. 22.3.8 Compare Requirements to DoD Transaction Library The Property, Plant, and Equipment requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 68
    • 23.0Time and Attendance Concept of Operation In February 2009, the SSD was tasked to establish a set of functional requirements for T&A. To accomplish this mission, it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing T&A functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, T&A SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The T&A functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. The T&A working group mapped the standard Time and Attendance functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps. 23.1Time and Attendance Functional Overview Functional requirements developed for T&A are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed T&A business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Personnel Visibility), BEA process name (e.g. Manage Personnel and Pay) and the DFAS process name (e.g. Human Resources and Payroll). As an incremental project, the T&A FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail. 69
    • It should be noted that only the process steps associated with T&A are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the T&A requirements defined to date. Release 6.0 contains the following process models: • Record Time and Attendance • Personnel Visibility * • Manage and Sustain Personnel** • Manage Personnel and Pay *** * The Personnel Visibility Model process incorporated into this document is a subset of the BEA Record Time and Attendance model and reflects the initial steps to Personnel Visibility Model and establishes Time and Attendance. Personnel Visibility Model is further broken down into DFAS lower-level processes. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions. ** The Manage and Sustain Personnel Model process incorporated into this document is also a subset of the BEA Record Time and Attendance model and reflects the initial steps to Manage Personnel Model. Manage and Sustain Personnel Model is further broken down into DFAS lower-level processes. *** The Manage Personnel and Pay process incorporated into this document is also a subset of the BEA Record Time and Attendance model and reflects the initial steps to Manage Personnel and Pay. Manage Personnel and Pay is further broken down into DFAS lower-level processes. 23.2Time and Attendance Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the T&A DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 23.3Release 6.0 Scope 23.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 23.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 touch points between the functions. 70
    • 23.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 23.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 included requirements that were reclassified as being out of scope for T&A. These requirements were identified and considered for inclusion in another team’s functional requirements. 23.3.5 Perform Team Quality Review of Requirements In Release 6.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. 23.3.6 Develop Additional Process Models The T&A team developed additional process models for Release 6.0. 23.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 23.3.8 Compare Requirements to DoD Transaction Library The T&A requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 71
    • 24.0Travel Concept of Operation In October 2008, the SSD was tasked to establish a set of functional requirements for Travel. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed. First, the working group gathered existing Travel functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. Next, Travel SME’s were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The Travel functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SME’s felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. The Travel working group mapped the standard functional requirements to the applicable process step. The review of processes and mapping of functional requirements to business processes served to identify: 1) gaps in the objects and related descriptions included in the diagram, 2) the need for further decomposition or changes to the BEA baseline diagram, and 3) the need for additional functional requirements to complete the standard requirements package. The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate BEA process flows/steps. 24.1Travel Functional Overview Functional requirements developed for Travel are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Travel business processes. When needed, the BEA processes are further broke down to provide additional detail and to ensure that a standard comprehensive process is defined. As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Perform Travel Pay), BEA process name (e.g. Define Travel Pay Model) and the DFAS process name (e.g. Identify Travel Pay Costs). As an incremental project, the Travel FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail. 72
    • It should be noted that only the process steps associated with Travel are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Travel requirements defined to date. Release 6.0 contains the following process models: →Perform Travel Pay →Define Travel Pay Performance Model* →Populate Travel Pay Model** * The Define Travel Pay Performance Model process incorporated into this document is a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Define Travel Pay Performance Model and establishes Travel Pay Accounting. ** The Populate Travel Pay Performance Model process incorporated into this document is also a subset of the BEA Perform Travel Pay model and reflects the initial steps to Populate Performance Model. 24.2Travel Accounting Practices The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Travel DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies. 24.3Release 6.0 Scope 24.3.1 Map Requirements to BEA Processes During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.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 integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. 24.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 touch points between the functions. 24.3.3 Validate Requirements Source Information Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews. 24.3.4 Assign Reclassified Requirements to Other Core Teams Release 6.0 included requirements that were reclassified as being out of scope for a specific functional area. These requirements were identified and considered for inclusion in another team’s functional requirements. 73
    • 24.3.5 Perform Team Quality Review of Requirements In Release 6.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. 24.3.6 Develop Additional Process Models Travel did not develop additional process models. 24.3.7 Close Out Open Issues Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE 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. 24.3.8 Compare Requirements to DoD Transaction Library The Travel requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events. 74
    • 25.0Shared Services Points of Contact 25.1Shared Services Division Hotline Email The SSD has established a hotline email address which may be used to provide comments or request information regarding the use of the functional requirements and FRD. The Shared Services Hotline email is fmcoesharedservices@dfas.mil. 25.2World Wide Web The FMCoE, SSD has established a web site titled "Standard Finance & Accounting Requirements" which may be used to access the functional requirements documentation. The web site URL is: http://www.dfas.mil/more/fmcoe/standardfinanceaccountingrequirements.html 25.3Scenario Database In Release 4.0, Shared Services implemented a Scenario Database for writing, storing, updating and retrieving the functional requirements for mapping to various Scenarios. Requirements for all functional areas are included in the Database. Tailored Access Reports are available for staff use; however, tailored Access Reports can be made available for customer use upon request. 25.4BEA 6.0 Architecture Below is the link to the BEA 6.0 architecture where you can view diagrams, processes, and activity models. http://www.bta.mil/products/bea/html_files/dodaf.html 75
    • Appendix 1 – Acronyms AP Accounts Payable AR Accounts Receivable BEA Business Enterprise Architecture BEIS Business Enterprise Information System BEP Business Enterprise Priority BID Business Integration Division BPM Business Process Model BPN Business Partner Number BPR Business Process Reengineering BTA Business Transformation Agency CA Cash Accountability CCB Configuration Control Board DDRS Defense Departmental Reporting System DEAMS Defense Enterprise Accounting and Management System DFAS Defense Finance and Accounting Service DISB Disbursing DMI Desktop Management Initiative DOORS Dynamic Object-oriented Requirements System DoD Department of Defense ERP Enterprise Resource Planning FASAB Federal Accounting Standards Advisory Board FASB Financial Accounting Standards Board FBS Functional Business Support FMCoE Financial Management Center of Excellence FMR Financial Management Regulations FR Financial Reporting GAAP Generally Accepted Accounting Principles GAO Government Accountability Office GFEBS General Fund Enterprise Business System GL General Ledger HPO High Performing Organization IG Intra-Governmental IGE Intra-Governmental Eliminations IT Information Technology JAD Joint Applications Development MCA Managerial Cost Accounting OA Operational Architecture OMB Office of Management and Budget SME Subject Matter Expert SSD Shared Services Division TFM Treasury Financial Manual WBS Work Breakdown Structure 76