Electronic Records Management Guidance on Methodology for Determining Agency-unique Requirements

Electronic Records Management (ERM) Initiative
August 23, 2004

1 INTRODUCTION

         Application of This Guidance Document
         ERM Applications - Background/Context
         The DOD 5015.2-STD - a Current Requirements Standard

2 SECTION 1 - REQUIREMENTS GATHERING BEYOND 5015.2

         Step One - Determine ERM Scope
         Step Two - Review Infrastructure/IT Architecture
         Step Three - Review Agency Records and Information Resources Management (IRM) Guidance and Directives
         Step Four - Review Available Standards

3 SECTION 2 - REQUIREMENTS ANALYSIS

         Step One - Review Requirements
         Step Two - Requirements Classification
         Step Three - Stakeholder Review

4. CONCLUSION

         GLOSSARY
         APPENDIX

Methodology for Determining Agency-unique Requirements

1. INTRODUCTION

The strategic focus of the Office of Management and Budget's (OMB) Electronic Government (E-Gov) Initiatives is to utilize commercial best practices in key government operations. The National Archives and Records Administration (NARA) is the managing partner for the Electronic Records Management (ERM) E-Gov Initiative. NARA's ERM Initiative will provide a government-wide policy framework and guidance for electronic records management.

This guidance document is one of a suite of documents to be produced under NARA's ERM Initiative that, when taken together, form the structural support for ensuring a level of uniform maturity in both the federal government's management of its electronic records and its ability to transfer electronic records to NARA. For further information on the ERM Initiative and the guidance documents produced for the Initiative, please see http://www.archives.gov/records-mgmt/initiatives/erm-overview.html.

This document is the second of four documents to be produced under the Enterprise-wide ERM Issue Area. The Enterprise-wide ERM documents are aimed at helping agencies understand the technology and policy issues associated with procuring and deploying an enterprise-wide¹ ERM system.² They include guidance for evaluating Capital Planning and Investment Control (CPIC) proposals; guidance on developing agency-specific functional requirements for ERM systems; guidance on developing and launching an ERM pilot project; and a "lessons learned" paper from the Environmental Protection Agency's proof of concept ERM pilot as well as other agencies' implementation experiences.

Application of This Guidance Document

This document is intended to help agencies manage and scope the requirements analysis step of an enterprise-wide ERM acquisition project. It provides a process for identifying potential ERM system requirements that are not included in the Design Criteria Standard for Electronic Records Management Applications, DOD 5015.2-STD (v.2) (http://jitc.fhu.disa.mil/recmgt/standards.html), which has been endorsed by the Archivist of the United States for civilian agency use (http://www.archives.gov/records-mgmt
/bulletins/2003/bulletin-2003-03.html). As a product of the ERM E-Gov initiative, this guidance should be interpreted as a "best practice" that agencies should adhere to when deciding to customize 5015.2-certified RMA software.

Differences in agency cultures, business needs, and technology infrastructure may generate unique RM requirements for an enterprise-wide implementation of ERM systems that the DOD standard doesn't address. Furthermore, enterprise-wide ERM systems may interact with other record-producing, enterprise-wide applications, including document management, correspondence tracking, content management, and workflow systems. These additional requirements are not addressed in DOD 5015.2-STD, as they are outside of the RM scope of the design standard.

The primary audience for this document is the project management team of those federal agencies that have already made the decision to acquire and implement an ERM system. This document makes a number of assumptions (detailed below) about the level of knowledge of ERM systems and about the capabilities an agency possesses to acquire and implement an ERM system. Those agencies that are contemplating implementation of an ERM system should use this guidance document in their early planning efforts. The assumptions are:

• An enterprise-wide ERM system is being planned and has successfully emerged from the capital planning investment process (http://www.whitehouse.gov/omb/circulars/a11/current_year/s300.pdf).
   
• Enterprise-wide deployment of an ERM system is accounted for in the agency enterprise architecture and conforms to the Federal Enterprise Architecture Framework (FEAF). http://www.whitehouse.gov/omb/egov/a 1 fea.html
   
• The agency records officer has an understanding of ERM (purpose, components, and functionality) and how it differs from paper recordkeeping.
   
• Some enterprise-wide analysis of business process has already gone on and ERM was selected, among other business processes, for enterprise-wide automation. These include, but are not necessarily limited to, business process re-engineering and cost/benefit analysis that would be part of making the value proposition substantiating a enterprise-wide move towards ERM.
   
• The agency will incorporate all of the mandatory requirements of the Design Criteria Standard for Electronic Records Management Applications, DOD 5015.2-STD into their ERM system. The agency will also incorporate applicable DOD 5015.2-STD non-mandatory requirements (e.g., relating to national security classified information)³.

This guidance was developed from the experience of federal agency managers whose aim was to have one enterprise-wide ERM system but found the need to incorporate additional, agency-unique requirements beyond those contained in the 5015.2 (v.2) specification. It is intended to assist other agencies as they plan and design their own enterprise-wide ERM systems.

Gathering requirements is just one of the steps in implementing an ERM system or any information technology (IT) system. Prior steps may include program creation, business case analysis, enterprise architecture analysis, and business process analysis. Further steps may include product evaluations, cost-benefit analysis, pilots, and implementation. Each organization must map out its own process for implementing an ERM system.

This methodology provides additional guidance, based on the experience of one federal agency, regarding the requirements gathering step. While every organization will perform this step, each may perform it differently and will obtain different results. This methodology discusses the process of gathering requirements at a high level so that each organization can apply it to their own environment.

A glossary is included at the end of this document for the general understanding of the terms and concepts used throughout this document.

ERM Applications - Background/Context

The ERM requirements addressed in this document will be used to implement an ERM application⁴, using DOD 5015.2 (v.2) as a requirements baseline. ERM applications provide the business logic required to capture, control, maintain and dispose of electronic records. They provide the user the ability to declare electronic files as records and associate them to a file code and corresponding disposition authority. DOD 5015.2-STD-certified ERM applications (http://jitc.fhu.disa.mil/recmgt/register.htm) accomplish such in a manner that guarantees conformance with federal recordkeeping statutes and regulations.

Using ERM applications, agencies can implement file plans, control dispositions and access agency records. Initially, these products were standalone systems. Recently, some electronic document management (EDM) companies and enterprise content management (ECM) vendors have acquired ERM products and integrated their records management capabilities into their products. In these cases, the ERM application provides the records management logic and the EDM or ECM system supports such tasks as document capture, storage, search, access, and workflow.

The capabilities of some ERM products have been extended to include many of the functions commonly associated with EDM or ECM products. An ERM product may offer workflow and versioning tools, in addition to its standard records management functions.

Market forces continue to drive ERM/EDM/ECM software producers to develop systems with various combinations of document, content and records management capabilities. Agencies will have to decide which product combinations best meet their business needs and information architecture. The process outlined in this document for identifying agency-unique requirements is applicable to any system, or combination of systems, that is intended to implement records management capabilities.

The DOD 5015.2-STD - a Current Requirements Standard

In November 1997, the Defense Department (DOD) released the Design Criteria Standard for Electronic Records Management Applications, DOD 5015.2-STD. This standard described the minimum requirements derived from federal statute and regulation that an ERM application must support for use within DOD. DOD revised 5015.2 in June 2002 to include additional requirements including classified markings, access control, declassification, and downgrading. The DOD Joint Interoperability Test Command (JITC) has also developed a test program to certify products against 5015.2.

The 5015.2 standard sets minimum functional requirements for ERM applications. It specifies design criteria needed to identify, mark, store, and dispose of electronic records. It does not define how the product is to provide these capabilities. It does not define how an agency manages electronic records or how an ERM program is to be implemented. Its original purpose was to specify mandatory and optional design requirements that a commercial off-the-shelf (COTS) product must support before DOD components could use it.

While 5015.2 mandates ERM application requirements for DOD, it has become the recommended standard for the rest of the federal government. Many agencies and government organizations, including the Department of Education, the Environmental Protection Agency, Department of Energy, the Federal Deposit Insurance Corporation, Social Security Administration, U.S. Patent and Trademark Office, and others, require 5015.2 certification in selecting ERM applications. As part of the ERM Initiative, NARA Bulletin 2003-03, released January 2003, recommends that all agencies use the second version of the 5015.2 standard and the DoD-certified products as a baseline when selecting an ERM application to manage the agency's electronic records.

DOD 5015.2 provides a generic set of requirements for ERM applications. These requirements may not be sufficient for use by other agencies or organizations. An organization will want to start with the 5015.2 requirements as a baseline and then determine if they have additional specific requirements.

The steps in Section 1 will assist in identifying agency-specific ERM requirements by examining project scope, existing electronic records systems, information technology architecture, and information policies. After a list of non-5015.2 requirements is identified, each requirement will be reviewed for inclusion in the ERM system (Section 2).

While the intent is to develop an enterprise-wide system, some agency records may not be managed by the ERM for operational reasons (e.g., budget, security). The goal of this step is to gather basic information on what records the system will (and won't) manage. Defining the scope will establish what end users can expect the system to accomplish.⁵

• Even if an ERM system is implemented enterprise-wide, it may not be practical or cost-effective to manage all records in all formats. You should identify the various types of agency-specific records that are created.

           Record formats to consider including:

                - E-mail
                - Office automation software suites
                - Forms (including electronic)
                - Web content
                - Paper
                - Faxes
                - Output and transactions from agency information systems

• Who will use the system? These stakeholders need to be consulted on how the system will create, capture, maintain, disseminate, and dispose of the records they generate in the course of agency business. Stakeholders may be able to identify unique business processes or activities that some ERM systems may not be able to manage.

           Stakeholders with potential requirements:

                - Chief Information Officers (CIOs)
                - Record keepers
                - Records officers
                - Agency program staff
                - Other Governmental agencies with which your agency interacts
                - Citizens and other interested parties
                - IT staff

• Agencies will have a variety of records that include national security classified or sensitive information.

           What types of sensitive information will the system include?

                - Privacy Act systems of records
                - Freedom of Information Act (FOIA)-exempt
                - Confidential business information
                - Litigation
                - Law enforcement

• All organizations have existing systems that create or store electronic records. Most of these are not designed to provide basic recordkeeping functionality, such as file plan organization and disposition. Once systems that create or store electronic records are identified, the decision to migrate⁶ or integrate⁷ them into an ERM system may generate agency-specific requirements. An existing system that creates electronic records may require a specific type of application programming interface (API) to integrate properly with the proposed ERM.

           Review existing systems to determine:

                - What information systems create or contain records?
                - What types of records do they create or contain?
                - What records management functionality do they provide?
                - Will legacy systems be integrated or migrated?⁸
                     o If integrated, what functionality between the legacy system and ERM application should integration support?
                     o If migrated, what legacy system functionality should be replicated in the ERM system?

For each item found to be in-scope, determine if the 5015.2 requirements adequately address the business processes of the organization. If not, a new requirement may need to be defined.

Identify unique agency infrastructure or architecture that could result in unique requirements for the ERM system. Agencies should have an enterprise-wide IT architecture that provides the baseline for the existing infrastructure and lays the foundation for future infrastructure improvements. Any ERM system must fit within the existing infrastructure and the organization must incorporate ERM into the enterprise architecture.

Items to review include:

• Network - servers and system software
• Security
• Desktop applications
• Standard desktop configuration

An ERM system managed at the agency level will have different IT architectural implications than one managed at the branch level. For example, an agency-level ERM system might require different server resources or architecture than a system for a single division or branch.

• At what organizational level will the system be administered?

                - Agency or at a lower level (e.g., sub-agency, program, division, branch)

Organizations have records and organizationally-unique IRM policies that support paper records. Some organizations have organizationally-unique RM policies to address a limited set of electronic records (e.g., e-mail). Any ERM system should be required to support those provisions.

For example, an agency might have a very detailed file plan that doesn't work effectively with certain ERM systems. This may force the agency to decide which approach is more productive; changing the file plan to accommodate the ERM, or finding an ERM that works better with the existing file plan. If the decision is to have an ERM that will accommodate the file plan, a new requirement may need to be defined.

Items to review include:

• RM policies
• IRM policies (including when there is a need for business process re-engineering and/or business case requirements such as determining a value proposition, determining a return on investment, or conducting cost/benefit analyses)
• Security policies, including policies and procedures for protection of national security classified information
• File plans⁹
• Schedules - Disposition and Retention

In addition to 5015.2, there are standards available or under development that may also provide requirements, guidance, or insight into ERM systems. While these standards will not be agency specific, they represent proven ideas and best practices within the industry and by other organizations in addressing an ERM system implementation.

Standards to review include:

• Model Requirements for the Management of Electronic Records (MoReq) http://europa.eu.int/idabc/en/document/2631
       

• AIIM Standards Committee on Integrating Records Management and Document Management Requirements
       http://www.aiim.org/standards.asp?ID=24484

• Reports by Doculabs on ERM, EDM, and ECM systems
       http://www.doculabs.com

• International Standard ISO 15489-1: Information and Documentation - Records Management
       http://www.iso.ch/iso/en/ISOOnline.frontpage

After completing the steps in Section 1, a list of potential new requirements has been generated. Now each requirement must be analyzed to determine if it will be included in the final list of ERM system requirements. The following steps outline the analysis process.

Review the characteristics of each requirement according to the following questions. The answers to these questions will determine which requirements need to be revised or eliminated.

• Tests of a well written (clear and effective) requirement:

                - Does it describe a system functionality?
                - Is it clear?
                - Is it concise?
                - Is it testable or verifiable?
                - Does it express a single idea?
                - Does it map clearly to specific organizational goals?
                - Does it map directly to business processes or policies?
                - Does it describe the user's needs?
                - Does it identify expected performance targets or measurable value?
                - Describe high-level functionality (too vague)?
                - Describe low-level functionality (too implementation dependent)?
                - Describe the right level functionality (can be used to evaluate solutions)?

To prioritize requirements, assess the functionality of each additional agency-unique requirement as to whether:

• The system cannot function without it
• It provides significant savings in time or resources
• It smoothes the path for the end-user
• It provides the records manager with useful tools
• It provides the system manager with additional auditing capabilities beyond those specified in C2.2.8
• It reduces risks to future access to the information

Requirements that meet the first criterion are mandatory. Requirements that meet the next five criteria are optional and may be judged on a sliding scale depending on the individual priorities of the agency.

It is important to give the stakeholders an opportunity to review additional, agency-unique requirements after they have been drafted. Several methods are available in order to facilitate this exercise:

• Walk through with stakeholders how requirements map directly to identified goals.
• Ask stakeholders to rank the impact and risk of each organizational process, then use the mapping between requirements and business processes to rank critical requirements.
• Ask stakeholders to identify their "Most Wanted" and/or "Least Wanted" requirements in the context of organizational value and risk.
• Ask stakeholders to rank requirements in terms of importance on a sliding scale.
• Present the stakeholders with a picture of the system as it could be built from the requirements and request that they critique it.
• Arrange a stakeholder meeting to assess the requirements either in detail or as a whole.
• Publish the draft requirements and request written comments.

Once stakeholder comments or opinions are known, it is possible to broaden the mandatory requirements to include those requirements of most use to stakeholders, to re-write requirements as needed, and to prioritize optional requirements according to their usefulness.

Depending on the extent and substance of stakeholder comments, the requirements may be re-written and resubmitted for stakeholder evaluation. In the event of the previous existence of legacy systems, this may be an especially important step for the owners and operators of those systems. Where there are many competing voices to be heard, an iterative process or re-write, re-prioritizing, and review is needed to sufficiently refine the requirements.

Part of the review process includes a re-assessment of requirement priorities in terms of a cost-benefit analysis and in terms of available resources.

Final requirements should only be valid for a given interval, and should be periodically reviewed until the system they describe has been built.

A disciplined step-by-step approach to identifying and defining system requirements is necessary to provide the building blocks for agency ERMs. Using the guidance provided by this document, agencies can develop requirements that:

• support the agency's fully identified business processes,
• make the best use of its resources,
• harmonize with its current systems, and
• produce a system that provides tangible benefits to the organization and end users.

Agency-specific requirements can be used in combination with the 5015.2 standard to acquire a COTS ERM system or to develop a custom ERM system. For COTS acquisition, the requirements will be used to develop selection criteria. COTS products will be evaluated against the criteria to determine which product best fits the agency needs. For custom development, the requirements will be used in the design of the system.

¹"Enterprise and Enterprise-wide" - Deployment or use of a single software application throughout all subdivisions or components of an organization.

²"ERM system" - A collection of hardware, software, staff, policies, and procedures that work in concert to enable an agency to manage records electronically.

³Where an agency has a need for a non-mandatory requirement covered in DOD 5015.2-STD, the agency should use the 5015.2 requirement and not develop their own wording. This guidance document addresses requirements that are in addition to those included in DOD 5015.2-STD.

⁴"ERM Application" - A software product that identifies, classifies, and disposes of records according to specified records disposition policies.

⁵5015.2-certified software automates many, but not all, recordkeeping requirements mandated in statutes and regulations. For an overview of the totality of records management requirements please see 36 CFR Part 1222 Subparts B &C (see Code of Federal Regulations (CFR)).

⁶"Migrate" - Records are moved from the legacy system to the ERM application and use of the legacy system is discontinued

⁷"Integrate" - Records remain in the legacy system with record status information maintained by the ERM application

⁸The results of the cost-benefit analysis between integrating or migrating legacy systems will inform the decision

⁹A file plan is a document containing the identifying number, title or description, and disposition authority of files held in an office.

GLOSSARY

• DOD 5015.2 or Design Criteria Standard for Electronic Records Management Applications, DOD 5015.2-STD - A DOD and NARA approved set of requirements for ERM applications.
   
• Enterprise Content Management (ECM) - An automated system with the functionality to capture, manipulate, retrieve, and publish the entire inventory of digital assets (e.g., web pages, office documents, databases, scanned images, e-mail) created by an organization.
   
• Electronic Document Management (EDM) - Functionality to support the computerized management of electronic and paper-based documents. Associated components include a system to convert paper documents to electronic form, a mechanism to capture documents from authoring tools, a database to organize the storage of documents, and a search mechanism to locate the documents.
   
• Electronic Records - Information, in an electronic state, that is determined to be a record.
   
• Electronic Records Management (ERM) - Functionality to support record collection, organization, categorization, storage of electronic records, metadata, and location of physical records, retrieval, use, and disposition.
   
• Enterprise and Enterprise-wide - Implementation of a single software application throughout all levels and components of an agency or organization.
   
• Federal Enterprise Architecture (FEA) - A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs. It is a representation or blueprint.
   
• Federal Enterprise Architecture Framework (FEAF) - An organizing mechanism for managing development, maintenance, and facilitated decision making for federal information technology resources. The framework provides a structure for organizing federal resources and for describing and managing Federal Enterprise Architecture activities.
   
• Program-specific - Pertaining to a single or local organization. Within Department of Interior (DOI), a system for the Bureau of Land Management (BLM) might be characterized as program-specific as it would not necessarily be affected by the other DOI bureaus.

APPENDIX - RESOURCES FOR IDENTIFYING ERM REQUIREMENTS

• Model Requirements for the Management of Electronic Records
  
  
• AIIM Standards Committee on Integrating Records Management and Document Management Requirements
       http://www.aiim.org/standards.asp?ID=24484
   
• Reports by Doculabs on ERM, EDM, and ECM systems
       http://www.doculabs.com
   
• International Standard ISO 15489-1: Information and Documentation - Records Management
       http://www.iso.ch/iso/en/ISOOnline.frontpage

Page updated: April 25, 2019