MoReq2 - Model requirements for Electronic Records Management
The Genesis of MoReq2
The MoReq2 development process during 2007 was highly communal - with more than 200 volunteer individuals and organizations participating. The volunteers came from every sector - user
organizations, consultants, integrators, academics, and software suppliers.
Importantly, the volunteers included virtually all the significant suppliers of electronic records management systems in Europe, from the very largest multinational players to small companies
active in only one region. During the consultation process, the MoReq2 development team received and processed thousands of comments, which makes MoReq2 the most comprehensive and usable electronic
records management specification yet.
The guiding principle for MoReq2 was evolution, not revolution. It is an evolutionary step from MoReq - not a radical change. The basic ideas in MoReq - documents, records, files, classes, and the
like have been supplemented rather than replaced.
The Purpose of MoReq2
MoReq2 is intended to be useful to a wide community of stakeholders in electronic records management:Users of electronic records management, who can customise MoReq2 to guide specification and procurementVendors of electronic records management software and services, who can use MoReq2 to drive software developmentEducators, who can use MoReq2 as a tool to teach and train the records managers of the future
MoReq2 is intended as a specification for electronic records management systems - namely, applications that are intended for the management of electronic and physical records. Such records are, for
the most part, "unstructured" e-mail messages, text documents, scanned documents, and so on. MoReq2 is not intended to specify the management of records in "legacy" applications (such as human
resources or manufacturing applications), and is it not intended to specify how a system is implemented.
Key Differences Between MoReq and MoReq2
MoReq2 differs from MoReq in four ways:
Unlike DoD 5015.2 and PRO 2002, MoReq did not have a testing scheme. MoReq2 was designed and written expressly with testability in mind, and it was published along with extensive test data and test
scripts. A by-product is that the language in MoReq2 is much clearer, with less room for ambiguity.
MoReq was effectively "orphaned" soon after its production. Not only did it not have a testing scheme, it was not maintained or controlled, despite its popularity (and probably because its
worldwide popularity came as a surprise). The DLM Forum, an independent stakeholder group that first conceived MoReq, is working on a governance regime to control MoReq2, to monitor translations
and extensions to it, and to manage a testing plan across Europe. This is expected to be in place by the end of 2008.
MoReq2 has three structural innovations.
1. It allows for any country to add a "chapter zero" to explain language differences (such as the tricky idea that the English word "records" does not exist in most other European languages),
national laws, and regulations.2. It is modular, consisting of a core module of requirements that addresses specifically records management requirements and 13 optional modules that address closely related requirements that are
essential to many groups of users. The 13 modules include, for example, collaborative working, distributed systems, fax integration, offline and remote working, and workflow.3. The metadata model has grown to such large proportions that it has been split off into an appendix that is published alongside MoReq2 as a separate document. Few users of MoReq2 will need to
refer to the metadata model, partly because an XML schema will be published later in 2008 for MoReq2. This will provide a way for electronic records, with their metadata and audit trails, to be
transferred between disparate electronic records management systems without loss of records management functionality as long as both systems are MoReq2-compliant and respect the MoReq2 schema.
The requirements specified by MoReq2 contain several enhancements and additions. Some of these are described below.
The Components of MoReq2
MoReq2 uses a new entity-relationship model, one that is clearer and more straightforward than MoReq's model, but at the same time richer. This is because MoReq2 manages without the confusing
concept of "hybrid" files (those files that contain both electronic and physical records) and because it adds two new entities and a few new relationships.Instead of recognizing hybrid files, MoReq2 simply recognizes that any file indeed, any aggregation - can contain any combination of physical and electronic records. This greatly simplifies the
model and allows the language of the specification to be clearer and simpler.
The first new entity introduced with MoReq2 is called "sub-file." This is a subdivision of a file; the idea is that some files (not necessarily all files) can be divided in a way that supports its
business use. For example, the client files in an accounting firm might be divided into sub-files for client correspondence, audit reports, working papers, and internal correspondence. Sub-files
will be useful mainly, though not only, in case management environments.
This new facility is in addition to the existing requirement to be able to divide files into "volumes." Not surprisingly, dividing some files into sub-files, and dividing some sub-files into
volumes, could be too complex for some smaller organizations. Therefore, MoReq2 requires that the electronic records management system must be able to be implemented with either sub file, or
volumes, or both, or neither, implemented.
The second new entity is the "component." A component is a separate electronic entity that makes up an electronic record. The obvious example arises in web pages, which are usually made up of
several "files" (in the computer sense, not in the records sense).By way of illustration, at the time of this writing, the ARMA International website home page showed it consisted of two cascading style sheet files, 41 GIF and 10 JPEG image files, and four
MoReq2 includes several requirements for the management of components to allow complex records to be managed properly, in particular as it regards long-term preservation. Those concerned about
long-term access should look to components to become more and more important.
The underlying model for MoReq2 also provides greater flexibility in managing retention and disposal, a core records management function. Retention rules can be applied to classes and files, as
before; but they can also now be applied, if needed, to sub-files, volumes, and even to individual records.
In another new departure, they can also be applied to "record types," a feature that could be useful when implementing retention and disposal rules for records that include personal information.
MoReq2 also specifies how the system must behave if it encounters a conflict between retention rules.
Another addition to the model has proved to be contentious: the ability to "store" records directly in a class, without the need for the records to be allocated to a file. This is intended for use
in environments that process large numbers of very simple cases - something like permit applications, perhaps. In a paper world, it is possible that the application forms would be processed and
filed in a filing cabinet, without a file being opened for each form; this feature in MoReq2 mimics this behaviour.
The feature is intended only for this niche situation, and it is expected to be used rarely. It would be poor practice to use it in any other setting, so MoReq2 requires that the system must allow
the ability to store records directly into a class to be configured off during implementation.
Classification Scheme Integration
MoReq2 provides a lot more detail than its predecessor about the requirements for importing and exporting parts of classification schemes from other systems, which will facilitate mergers and other
First, there are explicit requirements for the handling of the metadata associated with all the entities being exported or imported. For example, MoReq2 specifies that the system must not ignore
the fact that "mandatory" metadata is missing from imported records or classes; it must handle it in a suitable way.
Also, MoReq2 allows for the possible naming and numbering clashes that the import of classes can lead to. And, on a related note, the requirements for moving parts of the classification scheme
moving a class to another point in the classification scheme - have been tidied up and comprehensively re-worked.
Vital Records Requirements
In the MoReq2 chapter dealing with controls and security, the sections on access controls and audit trails are perhaps the least-changed sections - though even here the language has been tightened
up, clarifying the distinction between roles, users, and groups, for example. However, there is a new section that should please many records managers - namely, one that defines requirements for
managing vital records (perhaps a "first" in the world of electronic records management).
E-Mail, Scanning Integration
The core module includes requirements for integration to e-mail systems and scanning sub-systems. These requirements have been the subject of some disagreement, though many believe that the
majority of electronic records management implementations and the overwhelming majority of systems will need to integrate both with e-mail and with scanning. As elsewhere in MoReq2, the
requirements for this integration are specified in more detail than before; in the case of e-mail, there is even a detailed mapping of the records management metadata requirements to the formal
definitions of e-mail header metadata.
MoReq2 is much clearer on how entities such as records and aggregations are to be named and numbered. Globally unique identifiers are recommended but not required, and there is more flexibility for
naming, especially useful for case files.
The long-term preservation and accessibility of electronic records is becoming an increasing cause for concern - and quite rightly. MoReq2 introduces a new requirement to support long-term
preservation, including a requirement to be able to convert records to a preservation format at time of capture and a rather complex set of requirements for the migration of selected components to
preservation formats when required. This, too, is a first in electronic records management, but it undoubtedly marks no more than one step in what will be a long and difficult journey.
Ease of Use
One of the distinguishing features of MoReq2 (and of MoReq before it) is that it includes requirements for ease of use. Novelties in MoReq2 include requirements that allow users to suspend, or
interrupt, a process - say to look something up - and then to return to that process without having to start all over again. MoReq2 also considers accessibility for users with the widest range of
needs and abilities, making reference to appropriate standards. These and other new requirements related to usability will contribute to the future acceptance of electronic records management
Why So Many Changes?
This is a selective sampling of some of the main changes in MoReq2. There are many more - not only in the core requirements touched on above and in the optional modules not described above, but
also in nine appendices that provide extensive supporting references and cross-references.
In the handful of years since MoReq was published, two developments have been influential. First, office software has evolved, bringing novelties such as collaboration software, more pervasive use
of e-mail, electronic signatures, and soon.
Second, many of the difficulties encountered by MoReq clients with early-generation electronic records management software have been solved with MoReq2. As a result, MoReq2 is significantly longer
than its predecessor, but this is inevitable for a specification that sets out to be completely generic, usable in organisations large and small, usable in the public, private, or non-profit
sector, usable in a centralised or distributed architecture, and usable in any country.
Where to Find MoReq2
MoReq2 can be downloaded freely from the MoReq2 project website, www.moreq2.eu. The site also contains the testing framework documentation, the XML schema, frequently asked questions, and other
supporting collateral. More supporting material will be added as MoReq2 users demand it and so it will evolve.
At the Core of this Article
• Identifies who will benefit from using MoReq2
• Describes how MoReq2 was developed
• Highlights key enhancements to the model requirements
MoReq2 is intended as a specification for electronic records management systems - namely, applications that are intended for the management of electronic and physical records.
MoReq2 includes several requirements for the management of components to allow complex records to be managed properly, in particular as it regards long-term preservation.
National Archives. Requirements for Electronic Records Management Systems. Kew, Surrey, United Kingdom: Public Record Office, 2002. Available at www.nationalarchives.gov.uk/
Serco Consulting. Model Requirements for the Management of Electronic Records. Hook, Hampshire, United Kingdom: Serco Consulting, 2008. Available at www.moreq2.eu/ downloaashtm.
U.S. Department of Defense. DoD 5015.02-STD Electronic Records Management Software Applications Design Criteria Standard. Washington, D.C.: U.S. Government Printing Office, 2007. Available
Marc Fresko is a director at Serco Consulting the company that produced MoReq2. (Serco acquired Cornwell Management Consultants, the company that wrote MoReq, in 2007.) Fresko led the MoReq and
MoReq2 development projects, and he is responsible for Serco's consultancy in electronic document and records management. He may be contacted at Marc.Fresko@serco.com.
MoReq2 Glossary A to C
MoReq2 Glossary D to P
MoReq2 Glossary Q to Z
What are Records