RFI_Attach_5_ONRR_IT_Modernization_Requirements_Document_Final_1.pdf

U.S. Department of the Interior

Office of Natural Resources Revenue

IT Modernization Requirements Document

Prepared by Booz Allen Hamilton

December 22, 2021

ONRR IT Modernization Requirements Document

This document is confidential and intended solely for the client to whom it is addressed i

Executive Summary

Requirements gathering is a critical piece of planning and analysis in the software development life cycle (SDLC). The Requirements Team (the Team) for the Office of Natural Resources Revenue (ONRR) began identifying, vetting, and validating requirements for a new enterprise mission information technology (IT) system in 2020. Now complete, this expansive effort covered 39 future state or “To‐Be” business processes and reflects eight targeted software systems or “functional modules.”

This report finalizes information previously shared in three interim reports and summarizes critical aspects and outcomes of requirements development. Together with the final requirements, it serves as a useful tool for product owners, IT project managers, developers, and leadership engaged in the ONRR digital transformation.

Information provided herein for each of the To‐Be processes, Reference Data, covers process goals, process steps, and the supporting IT requirements. Requirements all trace back to the business process maps and narratives developed by ONRR during business process reengineering (BPR). All but four of the 39 To‐Be processes were addressed by the Team. The ONRR Data Governance team (Data Governance) addressed requirements for those four processes inherent to data design. Links to the collaboration pages used to document use cases, requirements, and other outcomes can be found within this report, too.

Higher‐level requirements for each of eight Functional Modules (Financial Management, Case Management System (CMS), Customer Relationship Management (CRM), Mission Assist Desk, Self‐Service Portal (SSP), Business Intelligence (BI), Risk, and Data Management) were developed, too, and have been summarized herein. These additional requirements address a more holistic view of the system business need and IT vision and ensure no gaps in functionality once the eight functional modules are implemented.

The Team also conducted a traceability analysis to further ensure that functionality gaps will not exist in the new system. Coupled with a robust quality assurance (QA) conducted on all requirements, the Team has provided ONRR high quality, comprehensive requirements as a foundation for a modern, highly effective, new mission IT system.

This document is confidential and intended solely for the client to whom it is addressed ii

Table of Contents

1.0 Purpose

1.1 Background

1.2 ONRR IT Modernization and the SDLC

1.3 Stakeholders

2.0 Requirements Approach

2.1 Inputs

2.2 Outputs

2.2.1 Use Cases

2.2.2 Requirement Types

2.3 Requirements Development Approach

2.3.1 Preparation and Due Diligence

2.3.2 Preplanning Meeting

2.3.3 Overview Meeting

2.3.4 Requirements Documentation

2.3.5 Compilation and Validation

2.4 Sequencing

2.5 Requirements Traceability

2.6 Data Governance Activities

2.7 Policies and Procedures Activities

3.0 Non‐Functional Requirements

3.1 Attributes

3.2 Types and Definitions

3.3 Non‐Functional Requirements

4.0 Requirements by To‐Be Process

4.1 Address Compliance Finding

4.2 Address Missing Report

4.3 Analyze Dispute

4.4 AR Monthly Balance & Quarterly Reporting

4.5 Assist New Reporter

4.6 Assist STRAC Partners

4.7 Collect Debt

4.8 Conduct Audits & Targeted‐Scope Reviews

4.9 Continuous Improvement

4.10 Create, Adjust, or Remove Policy

4.11 Develop Comprehensive Compliance Strategy

4.12 Develop Unbundling Cost Allocation

4.13 Disburse Money to Federal Fund Recipients

4.14 Distribute Indian Disbursement Data

4.15 Educate Stakeholder

4.16 Enhance and Create Data

4.17 Financial Statement Reporting

4.18 Formal Tribal Consultation

4.19 Handle Inquiries

4.20 Identify Potential Case Assignment

4.21 Investments

4.22 Issue Civil Penalty

This document is confidential and intended solely for the client to whom it is addressed iii

4.23 Manage Exemptions

4.24 Manage Funds

4.25 Manage Invoice

4.26 Manually Capture Data

4.27 Process Refund Request

4.28 Provide ONRR Guidance

4.29 Pull Data

4.30 Push Data

4.31 Reconcile Payments to Receivables

4.32 Set Up and Maintain Stakeholder

4.33 Treasury Financial Reporting

4.34 Update Data

4.35 Validate Data

4.36 Data Metadata

4.37 Data Quality

4.38 Data Security

4.39 Data Store‐Manage

5.0 Reference Data

6.0 Requirements by Functional Module

6.1 Business Intelligence Requirements

6.2 Case Management Requirements

6.3 Customer Relationship Management Requirements

6.4 Data Management Requirements

6.5 Financial Management Requirements

6.6 Mission Assist Desk Requirements

6.7 Risk Analytics Requirements

6.8 Self‐Service Portal Requirements

7.0 Quality Assurance

8.0 Conclusion

Appendix A – Requirements Development Approach .............................................................................. A‐1 Appendix B ‐ Confluence and Jira Guide .................................................................................................... B‐1

This document is confidential and intended solely for the client to whom it is addressed iv

Acronyms

AoA Analysis of Alternatives

AI Artificial Intelligence

AP Accounts Payable

AR Accounts Receivable

BAWG Business Analysis Working Group

BI Business Intelligence

BIA Bureau of Indian Affairs

BLM Bureau of Land Management

BOEM Bureau of Ocean Energy Management

BPC Business Planning and Consolidation

BPR Business Process Reengineering

BTFA Bureau of Trust Funds Administration

CARS Treasury Central Accounting System

CATSR Conduct Audits and Targeted Scope Reviews

CEVA Coordination, Enforcement, Valuation, and Appeals

CFO Chief Financial Officers

CMS Case Management System

COOP Continuity of Operations

COTS Commercial Off‐the‐Shelf

CRM Customer Relationship Management

CSGB Compliance Strategy Governance Board

CSP Compliance Strategy Partnership

CSV Comma‐Separated Values

DBMS Database Management System

DOI Department of the Interior

E2E End‐to‐End

EIRF Environmental Improvement and Restoration Fund

EOP Explanations of Payment

ERP ECC Enterprise Resource Planning Central Component

ETL Extract, Transform, and Load

FAQ Frequently Asked Questions

FBMS Financial and Business Management System

FBwT Fund Balance with Treasury

FSIO Financial Systems Integration Office

FMP Facility Measurement Point

GL General Ledger

GTAS Government‐wide Treasury Accounting Symbol Adjusted Trial Balance System

GVS Gas Verification System

HTML HyperText Markup Language

IIBA International Institute of Business Analysis

IPAC Intra‐Government Payment and Collection

IPT Integrated Project Team

IT Information Technology

JQL Jira Query Language

LOE Level of Effort

LVS Liquid Verification System

NFR Non‐Functional Requirement

NONC Notice of Non‐Compliance

OCM Organizational Change Management

OCS Outer Continental Shelf

OLT ONRR Leadership Team

OMB Office of Management and Budget

ONRR Office of Natural Resources Revenue

PaaS Platform as a Service

PASR Production Allocation and Schedule Report

PII Personally Identifiable Information

QA Quality Assurance

RACI Responsible, Accountable, Consulted, Informed

ROW Rights of Way

RUE Use and Easement

SaaS Software as a Service

SDLC Software Development Life Cycle

SF Standard Form

SME Subject Matter Expert

SOP Standard Operating Procedure

SPS Secure Payment System

SQL Structured Query Language

SSN Social Security Number

SSoT Single Source of Truth

SSP Self‐Service Portal

STRAC State and Tribal Royalty Audit Committee

TROR Treasury Report on Receivables

UI User Interface

URL Uniform Resource Locator

USSGL United States Standard General Ledger

XML Extensible Markup Language

VPN Virtual Private Network

This document is confidential and intended solely for the client to whom it is addressed 1

1.0 Purpose

This document provides an overview of the requirements captured to support the modernization of the Office of Natural Resources Revenue’s (ONRR) mission information technology (IT) system. These requirements are based on a reengineered set of business processes that streamline mission‐essential work and leverage current and developing technologies. With the support of Booz Allen Hamilton (Booz Allen), ONRR business users, systems managers, and Data Governance staff developed the requirements documented herein based on the reengineered processes, leveraging their expertise in systems design, technologies, and ONRR’s business needs to do so.

The ultimate goal for requirements development is to provide robust information aligning business needs with system capabilities. ONRR can then use this information to procure vendor support to design and develop a new IT system. The modernized system will enhance revenue collection and disbursement, compliance and enforcement activities, and reporting.

1.1 Background

ONRR is modernizing its mission IT system to address legacy issues and take advantage of new technologies. This multi‐year, multi‐phased digital transformation will explore, identify, develop, and implement new capabilities to enhance ONRR’s ability to perform revenue collection and disbursement, production and royalty reporting verification, compliance analysis, and workload management.

In 2018, ONRR completed an Analysis of Alternatives (AoA) study that evaluated several notional IT solutions for modernization. ONRR subsequently selected the “ONRR‐centric” option (known as Alternative II) as the guiding high‐level architecture for a new mission IT system.

ONRR then engaged in Business Process Re‐engineering (BPR) to modernize and streamline its business processes and drive those new system requirements. Anticipated benefits of BPR included:

Reduced technical complexity of business rules, business processes, and data

Reduced costs to the agency for equipment, development, business operations, information technology, and staffing

Reduced burden to the reporting community, industry operators, and payors

Clarified and streamlined data needed for ONRR and for sharing with other Department of the Interior (DOI) entities

Improved business process flow, significantly reduced customized coding, and maximized value of delivered software

ONRR BPR Vision

Empowering ONRR to drive from great to excellent and to build the ONRR of the future by harnessing our collective brainpower, leveraging technology, simplifying requirements, and eliminating organizational silos

This document is confidential and intended solely for the client to whom it is addressed 2

Gained advantages from automation to reduce or eliminate duplication, unnecessary business functions, systems external stand‐alone databases, and the manual manipulation of data external to the system of record

Identified data needs to accomplish ONRR’s mission

Outcomes from BPR will inform the design of ONRR’s new mission IT system, beginning with requirements development.

1.2 ONRR IT Modernization and the SDLC

Requirements development is step 3 within phase I of the software development lifecycle (SDLC). Figure 1 illustrates how ONRR has progressed from AoA to BPR and then Requirements Development.

Figure 1. Requirements Development represents a critical juncture in the ONRR IT Modernization SDLC, as outcomes will drive the implementation of the new IT system.

1.3 Stakeholders

Ten stakeholder groups played a part in collecting and documenting requirements. Table 1 summarizes each group’s roles and responsibilities using RACI terminology:

Responsible – Does the work and/or makes decisions

Accountable – Ensures and is held responsible for completion of the work

Consulted – Assists with getting the work done

This document is confidential and intended solely for the client to whom it is addressed 3

Informed – Is kept aware of progress or deliverables as outcomes affect them.

Table 1. Stakeholders

Stakeholder Group

RACI Role

Project Sponsor Accountable The Project Sponsor understood and approved requirements, which defined the overall scope of the project.

Requirements Integrated Project Team (IPT)

Responsible The Requirements IPT championed the requirements development process, guided the requirements gathering and documentation process, and supported the organizational change management (OCM) team by informing them of ongoing efforts. The Requirements IPT determined optimal focus group attendees to include business users, Systems Team, and Data Governance. Additionally, select Requirement IPT members co‐facilitated use case and requirements development sessions. The Requirements IPT reviewed and approved requirements documents.

Requirements Focus Groups

Consulted Requirements Focus Groups were small groups formed to develop use cases and requirements at a To‐Be process or functional module level. These groups typically contained a BPR lead, systems lead, representative business subject matter experts (SMEs), Systems Team, and Data Governance.

Upon completion of use case and requirements development, these groups also conducted requirements validation.

Systems Team Consulted The Systems Team provided business user and technical knowledge as well as background regarding ONRR mission systems.

Data Governance Team

Responsible Data Governance provided input into data requirements, consistencies, and definitions. The Data Governance Team researched and provided business and technical metadata and shared data improvement efforts with sister bureaus across

DOI.

Business/ Stakeholder Manager

Consulted The Business/Stakeholder Manager reviewed process descriptions and automation requirements. He/she provided input on requirements priorities and ensured focus group participants stayed focused on BPR goals.

Business SMEs Consulted Business SMEs provided user‐level context and help defined what the system must do from a business perspective.

BPR Steering Committee

Responsible Informed regularly of progress, the BPR Steering Committee occasionally weighed in and made decisions on far‐reaching requirements impacts, product vision, or policy and procedure issues.

ONRR Leadership Team (OLT)

Informed The OLT team of senior managers was informed of progress to ensure that requirements development stayed aligned with ONRR‐wide priorities.

Business Analysis Working Group

(BAWG)

Consulted The BAWG was consulted on issues that needed to be raised to a higher level for decision‐making. Generally, these issues affected multiple processes and required a policy decision.

This document is confidential and intended solely for the client to whom it is addressed 4

In addition, other key user groups, working groups, and committees were engaged, as appropriate, to identify synergies with, inform, and be informed by other ONRR initiatives.

This document is confidential and intended solely for the client to whom it is addressed 5

2.0 Requirements Approach

This section describes the high‐level approach used to develop a robust set of requirements, beginning with essential inputs and outputs (see Appendix A for the full requirements development approach). Figure 2 diagrams the flow and reflects the iterative nature of requirements gathering. This approach applies leading practices for business analysis and requirements development that were successful for other entities. It also incorporates standards recommended by the International Institute of Business Analysis (IIBA).

Figure 2. The Requirements Development Approach, including inputs and outputs.

2.1 Inputs

The approach begins with a framework of information needed to build requirements. For ONRR, those critical inputs are captured above in Figure 2. To‐Be process documentation provides fundamental information to structure requirements identification, especially process maps. Process maps for the future system developed during the ONRR‐wide BPR effort provide an overview of how the BPR IPT members intend processes will work in the To‐Be state. The maps guided the ONRR SMEs through use case and requirements development. In addition, existing information from the current state was important for many aspects of requirements development, including, but not limited to: data dictionaries, data input forms, flat files, standard reports, edits, static code tables, standard operating procedures (SOPs), systems design documents, and existing business rules.

This document is confidential and intended solely for the client to whom it is addressed 6

2.2 Outputs

Requirements development generates two forms of output: use cases and requirements. Every To‐Be process contains one or more use cases describing the necessary steps to complete within the process.

Use cases also provide the contextual information necessary to implement functional modules. Each step in a use case that utilizes the system contains one or more requirements. The Team identified eight types of requirements, described further in section 2.2.2.

2.2.1 Use Cases

Uses cases bridge the gap between process flows and the functionality needed for a system to support that process. The use cases detail the interaction between a user and the system. They help express the process flow in the To‐Be process maps while decomposing each step into business, data, and functional requirements, as well as non‐functional and other types of requirements where needed.

The advantage of having well‐documented use cases that support To‐Be process maps is building a complete picture for the integrator when clarification is needed with requirements.

By having use cases available that are directly connected to requirements, developers will be able to better understand the intent of requirement statements without having to leverage ONRR SMEs. Additionally, use cases can then be fit to the functional modules (e.g., financial management, customer relationship management (CRM), case management system (CMS), data management) that ONRR will need to acquire for its new system. The requirements tied to those use cases and processes can then be applied to those selected application(s).

Use cases were not documented as part of the BPR effort. Given that they are critical inputs, the Requirements IPT and the Team identified and vetted use cases as a precursor to capturing requirements for each To‐Be process.

2.2.2 Requirement Types

Requirement development includes identifying specific types of requirements. Table 2 lists the requirement types and definitions. These types provide ONRR with the necessary information for scoping its new system. All requirement types, except non‐functional requirements (NFRs), were collected during the requirements working sessions. NFRs were identified before the requirements working sessions as a backdrop for the other requirement types and then updated as the Team learned more through the development of requirements. An overview of NFRs can be found in Section 3.0 and the NFRs can be found in the Non‐Functional Requirements Document or on Jira.

This document is confidential and intended solely for the client to whom it is addressed 7

Table 2. Types of Requirements

Requirement Type Definition Business Defines the high‐level business needs. These requirements answer the basic question of “what does the business want to do?” They are broad and high level, written from the point of view of the client, and directly connected to the mission and goals of the organization.

Functional/System Defines the functions required by the system to fulfil the business needs.

These requirements answer the basic question of “what should be done?”

These requirements are written from the point of view of the system.

Non‐Functional Defines system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system.

Business Rule Defines specific instructions or constraints on how certain actions are performed. These rules capture the way the organization functions or conducts its business.

Reporting Defines any applicable laws, rules, regulations, instruments, orders or directives, or supervisory organization that mandate reporting. These requirements reflect the necessary information required to effectively conduct business processes. This information is often required within a certain period of time and within a specific format.

Data Defines the data elements necessary for the business process to function and be reliable from end‐to‐end (E2E).

Workflow1 Defines the system automated routing needs between entities, either users or processes. These requirements define transition between different entities.

Integration1 Defines the necessary data interactions with both internal and external systems for the business to conduct business.

2.3 Requirements Development Approach

Developing requirements followed five steps:

1. Preparation and Due Diligence

2. Preplanning Meeting

3. Overview Meeting

4. Requirements Documentation

5. Compilation and Validation of Requirements

Where possible, steps were combined to promote efficiency.

1 Workflow and Integration are a subset of Functional/System Requirements. These two types are typically identified during design and development, but, in select instances, were identified by the Team to provide additional clarity for a few requirements. However, inclusion of these three requirements subtypes was not exhaustive. Ultimately, it will be up to the design team(s) to build workflows, identify optimal integration configuration, and define all user access rights.

This document is confidential and intended solely for the client to whom it is addressed 8

This approach provided flexibility for processes that required multiple working sessions or revisiting after several other processes were complete. For example, Validate Data employed many iterative meetings with ONRR SMEs due to the large volume of requirements needed by the process. Additionally, Enhance and Create Data was actively updated and re‐validated as requirements for other financial processes were documented. Typically, a process took two or three requirements documentation meetings.

The sections below summarize important aspects of each of the five steps. Appendix A contains a guide the Team shared with the Requirements IPT and SMEs to communicate the approach in advance of working sessions.

2.3.1 Preparation and Due Diligence

First, the Team built a Confluence page to house use cases, preliminary requirements, and other contextual information. Next, preliminary data elements, requirements, and use cases were drafted from process maps and narratives developed during BPR. Where available, documented requirements from other To‐Be processes were used, too. Contextual information included a background and summary of the process and its goal, related statutes, regulations, and policies, and the standard vision and goals for BPR. Finally, the Team scheduled a pre‐ planning meeting with the BPR, Requirements, Data Governance, and Systems Team leads assigned to the process.

2.3.2 Preplanning Meeting

The Team met with the BPR, Requirements, Data Governance, and Systems Team leads to review the process map and Confluence page. This review served as an opportunity to identify and adjust preliminary requirements, use cases, goals, or any other content on the Confluence page. The resulting content provided a framework for SMEs to understand the scope and purpose of the process during requirements gathering. The BPR and Requirements IPT leads worked together to identify key SMEs for requirements gathering and select a time for the overview and requirements gathering meetings.

2.3.3 Overview Meeting

The BPR and Requirements IPT leads met with the SMEs to present the To‐Be process or functional module. They walked through the process map, discussed its context within ONRR’s value chain, and defined goals for the To‐Be design such as using certain technologies or eliminating manual steps. SMEs had the opportunity to ask questions and discuss the process ahead of requirements documentation. Note that this meeting was often combined with the first Requirements Documentation meeting.

2.3.4 Requirements Documentation

The Team scheduled meetings with all participants to walk through each use case for the process and document requirements aligned to each process map step. Ahead of each meeting, all participants received a copy of the process map and Confluence page containing context, This document is confidential and intended solely for the client to whom it is addressed 9 use cases, and preliminary requirements. Multiple meetings were required depending on the complexity of the process and the number of use cases. The Requirements IPT leads sometimes divided SMEs into smaller groups to tackle a specific scenario or use case for very complicated processes, such as Enhance and Create Data or Validate Data. SMEs were actively encouraged to think about what functionality and data they needed in the future to complete the process.

The BPR and Requirements IPT leads ensured the discussion stayed focused on what is needed rather than how the system might work. The Team documented requirements according to the predefined eight types (section 2.2) and applicable attributes. Every requirement contains multiple attributes which tie it to the To‐Be processes and functional modules. Requirement attributes include:

Summary – a 255‐character description of the requirement itself

Issue Key – a unique ID for the requirement within the Jira Project

Issue ID – a unique ID for the Jira issue across the whole system

Epic Link – links a requirement issue type to an epic

Functional Module – describes which of the eight identified functional modules the requirement aligns to

Requirement Type – indicates what type of requirement it is

Process – the process(es) where this requirement applies

Process Map Step – the step(s) in the business process where this requirement applies

Use Case – the use case(s) in the business process where this requirement applies

The Team also documented data elements to share with Data Governance. Action items and ONRR policy decisions were identified during the meeting. Policy issues were escalated to the BAWG for resolution. One‐off discussions with a select group of SMEs were scheduled as needed to address outstanding items.

2.3.5 Compilation and Validation

The Team compiled requirements gathered on the Confluence page once the participants finished discussing all steps in every use case for the process. The Team then conducted an internal review to validate and touch up the content on Confluence before sending out materials for review by all participants. The review materials included a copy of the process map and the Confluence page, as well as a comment tracker and general guidelines for good requirement statements. Participants had one to two weeks to provide feedback on the Confluence page and requirements. Reminders were used to encourage SME feedback.

The Team addressed SME feedback after the review period. If necessary, outreach to SMEs or the BPR or Requirements IPT leads was done to resolve issues. The Requirements IPT could sign‐off once all feedback was addressed. The Team then provided the final list of data elements to Data Governance and uploaded the validated requirements to Jira.

This document is confidential and intended solely for the client to whom it is addressed 10

2.4 Sequencing

With input from the ONRR Modernization Project leads and Requirements IPT, the Team developed a logical order for gathering requirements. The To‐Be processes were organized into five tracks described below in Table 3 which lists their sequence, completion date, and status. A complete list that includes supporting SMEs is located here.

Table 3. Process Tracker

Section Process Status Start Finish

Finance Track

4.27 Process Refund Request Completed Aug‐2020 Aug‐2020

4.21 Investments Completed Oct‐2020 Nov‐2020

4.23 Manage Exemptions Completed Nov‐2020 Jan‐2021

4.14 Distribute Indian Disbursement Data Completed Jul‐2021 Sep‐2021

4.4 AR Monthly Balance & Quarterly Reporting Completed Jun‐2021 Jul‐2021

4.17 Financial Statement Reporting Completed Jun‐2021 Aug‐2021

4.33 Treasury Financial Reporting Completed Jul‐2021 Aug‐2021

4.13 Disburse Money to Federal Fund Recipients Completed Jul‐2021 Sep‐2021

4.24 Manage Funds Completed May‐2021 Sep‐2021

4.16

Create Data and Enhance Data ‐ Create Data ‐ Enhance Data

Completed Completed

May‐2021 Sep‐2021

Oct‐2021 Oct‐2021

4.31 Reconcile Payments to Receivables Completed Aug‐2021 Oct‐2021

4.7 Collect Debt Completed Sep‐2021 Nov‐2021

4.25 Manage Invoice Completed Jul‐2021 Sep‐2021

4.12 Develop Unbundling Cost Allocation Completed Oct‐2021 Oct‐2021

Compliance Track

4.11 Develop Comprehensive Compliance Strategy Completed Aug‐2021 Oct‐2021

4.6 Assist STRAC Partners Completed Sep‐2020 Oct‐2020

4.10 Create, Adjust, or Remove Policy Completed Oct‐2020 Nov‐2020

4.15 Educate Stakeholder Completed Oct‐2020 Jan‐2021

4.5 Assist New Reporter Completed Nov‐2020 Dec‐2020

4.20 Identify Potential Case Assignment Completed Dec‐2020 Mar‐2021

4.8 Conduct Audits & Targeted‐Scope Reviews (formerly Analyze Case) Completed May‐2021 Jul‐2021

This document is confidential and intended solely for the client to whom it is addressed 11

Section Process Status Start Finish

4.2 Address Missing Report Completed Jun‐2021 Jul‐2021

4.28 Provide ONRR Guidance Completed Jul‐2021 Aug‐2021

4.1 Address Compliance Finding Completed Jul‐2021 Aug‐2021

4.22 Issue Civil Penalty Completed Aug‐2021 Sep‐2021

4.3 Analyze Dispute Completed Aug‐2021 Sep‐2021

Data and Reporting Track

4.32

Set Up and Maintain Stakeholder ‐ Industry ‐ Sister Bureaus and Tribes

Completed Completed

Mar‐2020 Sep‐2021

Mar‐2020 Nov‐2021

4.29 Pull Data Completed Aug‐2021 Sep‐2021

4.26 Manually Capture Data Completed Sep‐2021 Oct‐2021

4.35 Validate Data Completed Jan‐2021 Sep‐2021

4.34 Update Data Completed Sep‐2021 Oct‐2021

4.30 Push Data Completed Aug‐2021 Sep‐2021

Data Governance Track

4.36 Data Metadata Not Applicable2

4.37 Data Quality Not Applicable2

4.38 Data Security Not Applicable2

4.39 Data Store‐Manage Not Applicable2

Other Processes Track

4.19 Handle Inquiries Completed Oct‐2021 Nov‐2021

4.18 Formal Tribal Consultation Completed Oct‐2021 Oct‐2021

4.9 Continuous Improvement Not Applicable3

2.5 Requirements Traceability

Traceability connects a requirement to the specific business process, step, and use case where it is needed in ONRR’s operations. This ensures that ONRR can trace the need for each system function back to a specific business activity. It also allows the implementation team to better understand the entire scope of system functionality during development.

2 ONRR Data Governance developed requirements for these processes independently of the To‐Be process effort.

3 Continuous Improvement does not require bespoke system functionality; the team did not hold requirements sessions for it.

This document is confidential and intended solely for the client to whom it is addressed 12

Draft requirements were documented in Confluence during requirements development sessions. Once validated, the team transferred each requirement statement to Jira along with additional metadata including three fields which facilitate traceability:

Process – captures the To‐Be process to which the requirement is associated

Process Map Step – captures the specific step within the process map to which the requirement is associated

Use Case – captures the number of the use case documented in Confluence to which the requirement is associated

Requirements content (e.g., the requirement statement, process and step alignment, type) in Jira is considered final and may not align exactly with the pages in Confluence. These discrepancies occurred when updates were made in Jira after validation due to quality assurance activities.

There are a number of requirements that address features for each of the eight functional modules. These requirements do not align to specific processes, steps, and use cases due to their generic nature. Each general functional module requirement includes a label (GeneralFunctionalModuleRequirement) which identifies it as such.

Each To‐Be process is aligned to one or more As‐Is processes in the As‐Is to To‐Be Crosswalk available on SharePoint. This document enabled ONRR to validate that all current business function IT needs were captured within the requirements.

2.6 Data Governance Activities

The Team met bi‐weekly with Data Governance to collaborate on data requirements. Data Governance supported requirements gathering by providing information on the data needed to support each process and its source. A To‐Be Data Glossary (Data Glossary) was created to document every data element and their associated attributes necessary for the modernized system. The Data Glossary also tracks the data as it flows through the ONRR value chain. The Team populated the Data Glossary through requirements documentation efforts and worked with Data Governance to validate data requirements.

The Data Governance team led requirements development for four data‐centric To‐Be processes (Data Metadata, Data Quality, Data Security, Data Store‐Manage), which are included in sections 4.36, 4.37, 4.38, and 4.39.

2.7 Policies and Procedures Activities

ONRR established an implementation team referred to as the BAWG to conduct evaluations of bold BPR recommendations requiring feasibility assessments. Team activities of the BAWG included selection of an owner for each issue to lead the research, identification of potential solutions, and presentation to a decision‐making authority, such as the Modernization Steering Committee, for resolution. In total, the BAWG identified 34 issues requiring some type of internal or external coordination. Four of the 34 issues require a regulatory change in addition to internal or external coordination efforts.

This document is confidential and intended solely for the client to whom it is addressed 13

Policies and procedures are at the forefront of ONRR’s efforts to reengineer core business processes and implement a new mission IT system. Addressing these issues continues to be fundamental to achieving ONRR’s future state vision. To progress on each issue, Booz Allen recommends ONRR:

Make decisions on whether to move forward with any issue requiring a regulatory change

Determine how to engage DOI bureaus and other government agencies in design for external coordination issues

Determine the level of effort (LOE) for what’s next for each issue, focusing first on issues requiring action prior to system design and development

Develop a schedule to address each issue

For more details, see the final Policies and Procedure Deliverable #3.

This document is confidential and intended solely for the client to whom it is addressed 14

3.0 Non‐Functional Requirements

During the initial phase of requirements gathering, Booz Allen developed a Microsoft Excel‐ based spreadsheet for Non‐Functional Requirements. The Non‐Functional Requirements spreadsheet captures the baseline set of requirements that were identified, reviewed, vetted, and clarified with the ten stakeholder groups. The NFRs listed in the spreadsheet are intended to define the requirements needed to achieve the target‐state vision for the system and set the foundation for further requirements development. They have since been loaded into Jira and are available here.

3.1 Attributes

The Non‐Functional Requirements spreadsheet contains the attributes listed in Table 4 below.

Table 4: Non‐Functional Requirements Attributes and Descriptions

Attribute Description Requirement ID Requirement ID number

Non‐Functional Requirement Type See Table 5

Requirement Unique non‐functional feature, need, and/or capability that is required to meet the vision and business objectives for the application(s)

Additional Detail for the Requirement

The sub‐requirement specifications that add context and detail to the requirements

Throughout the product lifecycle, additional attributes may be added to the spreadsheet to support additional traceability and reporting requirements, including aligning the requirements to the target‐state vision for ONRR’s modernized IT system.

3.2 Types and Definitions

The development of NFRs required taking a holistic view of different attributes that affect ONRR's future modernized IT system. These different attributes have been categorized and defined to suit the wide range of considerations for ONRR. Table 5 lists the NFR types determined to be most relevant and applicable to ONRR's modernized IT system.

Table 5: Non‐Functional Requirements Types and Definition

Non‐Functional Requirement Type

Definition

Availability / Reliability

The degree (in terms of percentage of total possible time or hours per measurement period) to which a system or component can be accessed and exercised to perform the primary and derived business functions for which it is intended. For example: The ability to readily obtain data when needed.

Performance The amount of time it takes for a system and the components of a system to perform a requested function and respond to the requestor with the results of the requested action.

This document is confidential and intended solely for the client to whom it is addressed 15

Non‐Functional Requirement Type

Definition

Interoperability / Compatibility / Portability

The ability of a system to share information and exchange data with other systems and external hardware. The degree to which the solution operates effectively with other components in its environment, such as one process with another. Established in terms of operating systems, hardware devices, browsers, software systems, and their versions. The degree to which a solution or component can be transferred from one environment to another. Defines how a system or its element can be launched in different environments.

Established in terms of operating systems, hardware devices, browsers, software systems, and their versions. It also prescribes how well system elements may be accessed and may interact from two different environments.

Scalability The ability of a system or component that is being subjected to increasing functional demand to continue to provide processing throughput at a rate that is constant or resists degradation.

Accessibility The ability of a system to be usable by people with any type of disabilities.

Adaptability / Flexibility / Configurability

The capacity of the native version of a system or software package to perform a range of functions related to its core business purpose; to be configured easily to perform business‐related activities; to be compliant with factors such as laws, regulations, and policies; to be modified efficiently when business needs or constraining circumstances change; and to be adaptable with minimal or no software modification or customization.

Capacity The maximum of one or more specified levels of capability that a system can reach while reliably performing functionality. Capabilities can be number of connections, amount of data that may be accessed in real time, etc.

Usability The ability of a system to provide a condition for its users to perform functions safely, effectively, and efficiently while providing a satisfactory experience.

Regulatory / Certification

The ability of the system to meet many federal IT regulations to ensure information security and appropriate identification and management of risks.

Constraints on the solution that are necessary to meet certain standards or industry conventions.

Recoverability The ability of a system or component to return or to be returned to the most recent or a selected stable state following any interruption of processing; or, detection of a malfunction during which processing continued

Documentation Necessary training for personnel to perform tasks and stay current with the technological needs of ONRR.

Security (Access, System, and Data)

The ability to protect the system and the data from theft, malicious use, corruption, disruption, or misdirection. The ability of a system to apply appropriate protection to information assets (i.e., accounts, data, databases, documents, etc.)

This document is confidential and intended solely for the client to whom it is addressed 16

Non‐Functional Requirement Type

Definition

Modernization / Implementation

Achieving modernization goals of ONRR by aspects of the implementation. The ability of the system to support organizational strategic initiatives and goals, including modernization.

Environmental The ability of the system to limit the effect that changes to the environment has on system performance.

3.3 Non‐Functional Requirements

The Non‐Functional Requirements Spreadsheet is available on the Final Requirements spreadsheet.

This document is confidential and intended solely for the client to whom it is addressed 17

4.0 Requirements by To‐Be Process

The following section provides a summary table of each To‐Be process, including its value chain, status, links to the Confluence pages used to document use cases, and a brief description of each use case. This snapshot of the process also describes how the process ties to other To‐Be processes and lists which functional modules it leverages. The To‐Be processes are listed alphabetically, except for the four Data Governance Processes, which are at the end. As such, the numbering of processes within this report may not match the Confluence page numbering.

4.1 Address Compliance Finding

The goal of Address Compliance Finding is to establish a consistent and efficient approach to determining whether a finding can be resolved via an Order or needs to be referred to the Office of Enforcement for resolution. A finding is a behavior that is outside of what is reasonably expected per the regulations (e.g., inaccuracy in production or royalty reporting that was not caught during data validation). Findings that trigger the issuance of Official Correspondence are curable violations (i.e., not knowing or willful). Non‐curable violations include violations subject to steeper penalties by the Office of Enforcement.

Address Compliance Finding Summary Table

Value Chain Ensure Compliance

Links Confluence

Status Complete

Associated Process(es)

Conduct Audit and Targeted Scope Analysis (CATSR) – findings of a case identified during a full or targeted scope analysis is forwarded to Address Compliance Finding

Develop Comprehensive Compliance Strategy – throughout the year, the Verify/Compel SME compiles and analyzes SME guidance requests during the Develop Comprehensive Compliance Strategy process

Issue Civil Penalty – handles findings that are not resolved by the due date

Address Missing Report – missing report/information that are not received by the due date are handled in Address Compliance Finding

Other Processes – any compliance findings identified during any ONRR processes are handled in Address Compliance Finding

Functional Module(s)

CMS – tracks the development of a compliance case along with its findings

CRM – tracks and stores communications such an Orders, Notice of Non‐ Compliance (NONC), and Civil Penalty in a centralized, secure repository that any authorized staff can access

Use Case(s)

1. Curable Violation – ONRR identifies and resolves a non‐compliance issue that qualifies as a Curable Violation

2. Non‐Curable Violation – ONRR identifies and resolves a non‐compliance issue that qualifies as a Non‐Curable Violation

This document is confidential and intended solely for the client to whom it is addressed 18

3. Missing Report/Information – Office of Enforcement issues a NONC because the reporter does not respond to the courtesy notice in a satisfactory way or within the allotted time for a Missing Report/Information case

4.2 Address Missing Report

The goal of Address Missing Report is to establish a consistent and efficient approach to determining, preparing, and issuing formal/informal communications seeking to compel compliance from external parties. The trigger for this process is that a missing report/information is identified by the system or ONRR analyst. This process addresses the flow of events after any report/information is determined missing.

Address Missing Report Summary Table

Value Chain Ensure Compliance

Links Confluence

Status Complete

Associated Process(es)

Validate Data – Customer reports not submitted by their due dates are handled in Address Missing Report

Reconcile Payments to Receivables – report/information identified missing during Reconcile Payments to Receivables are handled in Address Missing Report

CATSR – data requests not received by their due dates during a full or targeted‐scope analysis are handled in Address Missing Report

Address Compliance Finding – the steps after ONRR sends a NONC when a missing report/information is not received satisfactorily is provided in Address Compliance Finding

Functional Module(s)

CMS – tracks the activities to resolve a missing report/information case

CRM – tracks and stores communications such as NONC and Courtesy Notice in a centralized, secure repository that any authorized staff can access

Use Case(s)

1. Missing Report/Information – Customer misses a report or requested information deadline

4.3 Analyze Dispute

When a Notice of Appeal is given to ONRR, an Appeals Analyst performs analysis, consults with the appellant, and recommends a solution to resolve the dispute. Orders, demands, invoices, and denials can all be subjects of an appeal. This process aims to issue the correct response to an appeal in a timely manner the first time.

Analyze Dispute Summary Table

Value Chain Ensure Compliance

Links Confluence

Status Complete

This document is confidential and intended solely for the client to whom it is addressed 19

Associated Process(es)

Reconcile Payments to Receivables – communication exists between these processes regarding any payments due or on hold in correspondence with the appeal

Functional Module(s)

CMS – manages and tracks documentation regarding an appeal

CRM – facilitates communication with the appellant

SSP – collects submission of documents relevant to an appeal, such as the Notice of Appeal and Statement of Reasons

Use Case(s)

1. Analyze Dispute – ONRR receives an appeal, manages the dispute, and works towards a resolution

4.4 AR Monthly Balance & Quarterly Reporting

Financial Management performs monthly accounts receivable (AR) balancing activities and generates an AR Monthly Balance report on the first business day of each month. This report informs department‐level reporting in the Financial Statement Reporting process. Each quarter, ONRR uses the three most recent AR Monthly Balance Reports to prepare the U.S. Treasury (Treasury) Report on Receivables (TROR). This report explains what money was collected and distributed by ONRR in the past quarter and contains accounts receivable information, balances, and aging.

AR Monthly Balance & Quarterly Reporting Summary Table

Value Chain Collect and Disburse Funds

Links Confluence

Status Complete

Associated Process(es)

Enhance and Create Data – provides receivable data

Manage Funds – provides receivable data

Financial Statement Reporting – consumes AR Monthly Balance and TROR reports generated in this process

Reconcile Payments to Receivables – provides receivable data

Functional Module(s)

Financial Management – contains the data and tools necessary to prepare reports

CMS – allows accountant to track their work generating each report

Use Case(s)

1. Monthly AR Balancing – accountants develop the Monthly AR Balance Report

2. Quarterly TROR Submission – accountants utilize Monthly AR Balance Reports and additional data from the Financial Management module to prepare and submit the TROR to Treasury

This document is confidential and intended solely for the client to whom it is addressed 20

4.5 Assist New Reporter

This process formalizes ONRR’s approach to assist new reporters when they begin submitting royalty and production reports, and payments. This process applies to the individuals within a company, rather than the whole organization, to ensure those responsible for information submission to ONRR know how to do so. An individual is considered a new reporter for their first year of interaction with ONRR for a given responsibility (e.g., production and royalty reports, payments). Assist New Reporter is considered ONRR’s most efficient method to achieve compliance due to its proactive nature.

Assist New Reporter Summary Table

Value Chain Ensure Compliance

Links Confluence

Status Complete

Associated Process(es)

Set Up and Maintain Stakeholder – precedes this process and functions to set up the new reporter with system access and initial training materials.

Provides ONRR with necessary contact and role data for each new reporter so that the office knows their responsibilities

Identify Potential Case Assignment – refers cases to Identify Potential Case Assignment where the problem can be assigned and addressed through further analysis and enforcement

Functional Module(s)

CMS – document assistance rendered for a new reporter’s first report or payment, and in response to issues later identified

CRM – facilitates and documents interactions between ONRR and industry providing a record of communication which may be used in downstream enforcement activities

SSP – provides a means for the new reporter to access and submit data to ONRR systems

Mission Assist Desk – may provide additional resources or direct a new reporter to this process

Data Management – enables the access and storage of reports, payments, and educational materials by both ONRR and the new reporter

Use Case(s)

1. First Report – the very first report an individual makes to ONRR

2. First Payment – the very first payment an individual makes to ONRR

3. Issue Identified – either an ONRR Analyst or the system identify a problem with a report or payment submitted by a new reporter within their first year

4. Time Elapses – ONRR Analyst periodically checks‐in with new reporter to ensure they feel comfortable reporting and/or paying

This document is confidential and intended solely for the client to whom it is addressed 21

4.6 Assist STRAC Partners

This process provides State and Tribal Royalty Audit Committee (STRAC) partners with the relevant information, answers to questions, and solutions to problems for which they need assistance.