Everything you wanted to know about DoD 5015.2: the standard is not a panacea or a guarantee, but it is a tangible contribution in a field hungry for guidance.

• Author: Gable, Julie

At the Core

This article:

* Defines DoD 5015.2 and its requirements

* Explains the standard's certification process

* Analyzes strengths and weaknesses of the standard

The U.S. Department of Defense's (DoD) Design Criteria Standard for Electronic Records Management Software Applications, better known as DoD 5015.2, debuted in 1997. Since then, it has become a de-facto standard that government agencies, including the National Archives and Records Administration (NARA), readily endorse. Private sector businesses routinely use standard certification--or lack thereof--as a way to shortlist records management software for potential purchases. DoD 5015.2 is also the starting point for such benchmarks as the United Kingdom's Public Record Office (PRO) standard and the European Union's Model Requirements (MoReq).

Outside the DoD, however, the standard is not necessarily well understood. Ask attendees at any electronic records seminar whether they are aware of the standard and nearly all raise their hands. Ask whether they want software that is certified to the standard and, again, the majority assent. Ask how many have actually read the standard, however, and the percentage drops significantly. Given the short-staffed nature of most records programs and the subsequent time crunch it produces, such a response is understandable.

But is it realistic to assume that software configured to a federal department's specification applies just as well to commercial enterprises? More importantly, is it correct to assume that whatever software vendors develop to obtain certification automatically becomes part of their products? Does the dictum "Must be DoD 5015.2-certified" in a request for proposal shortcut the need for analyzing an organization's needs in more depth? Not all business customers require certification; not all software vendors seek it. Why?

The Standard Evolves

The standard's origins provide a partial answer and illustrate the key role that archival principles played in its evolution. In 1993, a DoD records management task force that included representatives from NARA, the U.S. Army, the U.S. Air Force, and the Army, Research Laboratory began the work of re-engineering records management processes. In doing so, the task force considered research and theoretical constructs from the University of British Columbia and the University of Pittsburgh that focused on assuring the reliability and authenticity of electronic records. (See sidebar on page 36.)

Two years later, the task force published its findings in the report "Functional Baseline Requirements and Data Elements for Records Management Application Software." The report circulated to several federal and DoD agencies, as well as to software vendors, soliciting comment on the 47 requirements identified.

With the task force's charter fulfilled, the DoD turned to the Defense Information Systems Agency (DISA), the unit responsible for acquiring and managing shared office information systems, to continue the work. DISA relied on its testing and evaluation component, the Joint Interoperability Test Command (JITC), to clarify the report's requirements and establish a certification testing program.

"In 1996, Steve Matsuura, my boss at JITC, and I began to draft the standard," recalls Bill Manago, currently product manager for MDY Advanced Technologies, who was then in the armed forces. "We took into account NARA and other federal RM directives, incorporated research provided by Australian and Canadian standards, and developed requirements for managing e-mail as records." The result was DoD 5015.2, Design Criteria Standard for Electronic Records Management Software Applications. JITC remains responsible for maintaining the standard and administering the software certification testing program.

What the Standard Is

Revised in June 2002, the DoD 5015.2 standard defines mandatory functionality for records management application (RMA) software used within the DoD. Each mandatory functional requirement is included because it relates to U.S. federal regulation and/or NARA policy; these are listed in the standard document's references section. The standard's glossary of terms, as well as its list of acronyms and abbreviations, is useful for anyone not familiar with records management. Newly added to the June 2002 version is Chapter Four with requirements for records management applications supporting classified (i.e., secret) records. Other differences from the 1997 version include expanded requirements for audit, more functionality for user-defined metadata fields, and additional e-mail requirements.

Figures 1 and 2 list the requirements of 5015.2's 2002 version. Each mandatory requirement has several subparts, and each subpart specifies particular functionality. Required functionality reflects the way basic electronic recordkeeping...