Skip to main content
Models for Action: Developing Practical Approaches to Electronic Records Management and Preservation

Functional Requirements for Electronic Records Management

One of the foundations for Models for Action was the Functional Requirements for Record keeping developed in "Variables in the Satisfaction of Archival Requirements for Electronic Records Management," a research project of the School of Library and Information Sciences at the University of Pittsburgh (Pittsburgh Project). Based on the results from the Pittsburgh project, staff began by developing a set of functional requirements for electronic records management that could subsequently be translated into sets of questions or cues that facilitate the identification of technology, management and policy strategies to meet each requirement.

Although largely based on Functional Requirements for Record keeping, the Models for Action functional requirements focused on the system level (policy, management and technology) strategies that create records rather than at the record level. The definition of a record used in the development of the functional requirements is the following: "any information received in the normal course of business and retained as evidence of organization, function, policies, decisions, procedures, operations or other activities, or because of the information contained therein." This definition is a generalized version of the legal definition of record for management and archival preservation as it appears in New York State law as well as laws in many other states. The Models for Action functional requirements were also informed and influenced by "Preservation of the Integrity of Electronic Records," a research project of the University of British Columbia; the U.S. Department of Defense Records Management Application Functional Baseline Requirements; the National Archives and Records Administration's (NARA) instructional guide for Federal agencies, Records Management Requirements for Electronic Record keeping; and the work of a number of other institutions.

The initial Models for Action Functional Requirements contained five categories of requirements, each comprised of a number of requirements and sub-requirements, and each containing a brief justification statement. The major categories are shown on the next page. The use of the term best practices refers to practices formally adopted or generally accepted by a profession or discipline. Examples of best practices include Generally Accepted Accounting Practices and American Health Information Association information and documentation recommended practices. The initial Functional Requirements document was reviewed by the project's Advisory Committee, comprised primarily of practitioners and information resource managers in public and private sector organizations in New York State. Based on feedback from the Advisory Committee, the Functional Requirements were modified and the revised version was subsequently sent to experts in the archival and records management communities for comment.

The next step in the project was to develop a practical tool that translates the project's Functional Requirements into questions or cues that elicit application-specific records management requirements. This modified set of functional requirements was used as the basis for the development of an initial set of questions or prompts, subsequently named Records Requirements Elicitation Component (RREC) of the project's broader product the Records Requirements Analysis and Implementation Tool (RRAIT), which will also include technology, management and technology mechanisms for addressing records requirements.

While developing the RREC, it became clear that the Models for Action Functional Requirements needed substantial revisions. The process of crafting a workable tool based on the theoretical construct (the Requirements) created a synergy that helped generate very creative solutions.

The first significant change to the Functional Requirements was a redefinition of record. It was recognized that the original definition was too vague to be implementable in a practical tool. Project staff therefore decided to define record as "the complete set of documentation required to provide evidence of a business transaction." This definition is built around the concept of business transaction which provides a substantially better fit between the definition of a record and business process analysis concepts and is more likely to be understood by a wide audience. The revised definition is also similar to that recommended by United Nations Advisory Committee for Coordination of Information Systems (ACCIS) and that more recently used by the Pittsburgh Project.

A second modification to the Functional Requirements focused on the requirement category, Compliant. Insight gained in the process of developing the RECC led us to believe that compliance is not best regarded as an independent category. Rather, it is an attribute achievable through the effective identification, implementation and subsequent monitoring of the specific records management requirements associated with a business process. These specific requirements were accounted for in the remaining four categories of Functional Requirements.

A third modification was the combination of two categories of requirements - Records Maintained and Records Are Usable. Project staff found that Records Maintained contained requirements already accounted for in Records Capture. Therefore, redundant requirements were eliminated or integrated into Records Capture. The categories Records Maintained and Records Are Usable were combined to create a new category of requirement - Records Maintenance and Accessibility.

The process of developing the RREC, therefore, reduced the number of categories of Functional Requirements from five to three. The three remaining categories are in the figure below.

As indicated, the changes made to the Functional Requirements were done in the process of developing the records requirements analysis component of RRAIT. It is likely that additional changes will be made as the tools are used and evaluated throughout the course of the project.