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 procurement
  • Vendors of electronic records management software and services, who can use MoReq2 to drive software development
  • Educators, 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:

    Testability

    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.

    Governance

    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.

    Structure

    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.

    Content

    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.

    New Entities

    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

    JavaScript files - a total of 57 components. All of these components must be kept in correct context for that page to be managed as an electronic record.

    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.

    Retention

    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

    organizational change.

    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.

    Naming, Numbering

    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.

    Long-term Preservation

    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

    systems.

    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.

    Reference

    National Archives. Requirements for Electronic Records Management Systems. Kew, Surrey, United Kingdom: Public Record Office, 2002. Available at www.nationalarchives.gov.uk/

    electromcrec.ordslreqs2002ldefaut.htm.

    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

    atwww.dtk.mil/whs/direcrives/cones/pdf/501502stdpdf.

    Author Affiliation

    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

    For a FREE copy of the MoReq2 Specification document, please enter

    Please note that all fields followed by an asterisk must be filled in.

    Please enter the word that you see below.

      


    Home Page
    Records Management
    What are Records