Functional Requirements to Ensure the Creation, Maintenance, and Preservation of Electronic Records
One of the foundations for Models for Action was the Functional Requirements for Recordkeeping 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). The Models for Action Project staff began by developing a set of functional requirements for electronic records management based on the results from the Pittsburgh Project, 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 Recordkeeping, the Models for Action functional requirements focused on the system-level (policy, management, and technology) strategies that create records rather than on 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 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 US 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 Recordkeeping; and the work of a number of other institutions.
The initial Models for Action Functional Requirements contained five requirements, each comprised of a number of sub-requirements, and each containing a brief justification statement. The major elements are shown in the figure below.
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 further, 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 Co-ordination of Information Systems (ACCIS) and that more recently used by the Pittsburgh Project.2
A second modification to the Functional Requirements was the elimination of the requirement of Compliant. It became clear that Compliance is not an independent requirement. 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 Functional Requirements.
A third modification was the combination of the requirements - Records Maintained and Records are Useable. 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 requirements Records Are Maintained and Records are Useable were combined to create a new requirement - Records are Maintained and Accessible.
The process of developing the RREC, therefore reduced the number of Functional Requirements from five to three. The three remaining requirements are summarized in the figure below.
As indicated, the changes made to the Functional Requirements were done so in the process 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.
1The use of the term best practices refers to practices formally adopted or generally accepted by a profession or discipline. Examples of best practices include General Accounting Practices, American Health Information Association information and documentation recommended practices.
2See ACCIS, Management of Electronic Records: Issues and Guidelines (New York: United Nations, 1989), pp. 27-28, 35-36; "University of Pittsburgh Recordkeeping Functional Requirements Project: Reports and Working Papers," Pittsburgh: University of Pittsburgh, 1994, p. 25. The only possible variation taken by Models for Action is that "transaction" has been squarely defined as the larger business transaction that may be made up of a number of components (defined as sub-tasks in RRAIT). For example, all the steps in the issuance of a land use permit from receipt of application to actual issuance of the permit is treated as one business transaction and all the information necessary to serve as evidence of the issuance of the permit is the record of the transaction.