Professional Documents
Culture Documents
Designing Record Keeping Systems
Designing Record Keeping Systems
2002 Version
The Indiana University Electronic Records Project
Several phases and tasks for the methodology have been identified. Involvement in the
information system’s design stage makes the process much easier to implement. In most
cases, designing a new system involves incorporating your requirements or specifications
and the results of your business process models into the design of the new system.
More specifically, steps for designing new systems include 1) a description and analysis
of the business processes by means of a technique known as “modern structured
analysis,” and 2) recommendations for implementing the Functional Requirements for
Recordkeeping and the Metadata Specifications.
Record creation occurs at the event or transaction level, and the actual records to be
analyzed are those documents received as inputs to the system and those records created
as a result of the outputs or elementary processes generated in response to the external or
temporal event. For example: The business event “processing an appeal” is initiated or
triggered by a student or his/her parents, and the input document is the appeal letter
received from the student or the parents. The outputs or elementary processes of this
event are 1) Making and recording a decision on the appeal, 2) Modifying the student’s
financial aid data based on the appeal decision, and 3) Notifying the student about the
decision. The appeal letter, the decision document, the modified student record, and the
notification are the records of the process.
Eventually all this business process information is described or depicted in models or
representations that illustrate, usually through the use of pictures or symbols, the various
components and relationships of the processes. Models designed to “depict the system
independent of any technical implementation” are known as logical models or essential
models. (Whitten and Bentley, Systems Analysis and Design Methods, 4th ed., p. 210.)
And of the logical models, it is the opinion of the Archives staff that the most valuable
models for archivists are those that focus on system processes, specifically business
function decomposition diagrams, business event diagrams, and business process data
flow models. In the IU methodology, staff normally create functional decomposition and
business event diagrams.
What types of information are contained in these models, and what do the models look
like? To answer these questions, let us review the products Archives personnel created
for the business function “Student Recordkeeping.” As a first step, business processes for
this function are defined in a short narrative statement. Eventually this information is
used to generate a functional decomposition diagram for the function. A partial diagram
for the function “Student Recordkeeping”contains the following information and is
represented in the following manner.
Function: Student
Recordkeeping
Sub-Function:
Semester Data
Maintenance
Sub-Function:
Student Record
Maintenance
Sub-Function:
Grade and Credit
Posting
Event Process: Event Process: Event Process: Event Process: Event Process:
Assign Grade for Assign Grade for Assign Grade for Assign Grade Assign Grade for
Withdrawal Completion Transfer Work Changes Other Credit
Sub-Function:
Degree Recording
Sub-Function:
Academic Profile
Maintenance Sub-Function:
Sub-Function:
Enrollment Degree Certification
Certification
Event Process:
Create Academic
Event Process: Profile Event Process: Post
Event Process: Post
Modify Academic Dept. List of Degree
Degrees From
Profile Recipients
IUCare Application
Once the functional decomposition diagram is created, staff generate descriptions of the
business event processes, including information on the inputs and the various elementary
processes or outputs. Initially this data is captured in a simple form that includes the
following categories of information for each event process: Name of process, input
activities, input record, output activities, and output record(s). Once this data is gathered,
staff creates business event diagrams for each of the sub-functions. For the event
processes “department modifies course inventory,” and “processing an appeal received
from a student,” the models contain the following information and are represented in the
following manner.
Inventory Updates
System Containing
Course Inventories
Business Event Diagram - Sub-Function -
Financial Aid Awards - Event Process:
Processing an Appeal Received from a Student
Notification of Decision
Student
Appeal Notification Process Appeal
System Containing
Student's Financial Aid
Record
WORK STEPS:
1. Project staff selects a business area for analysis.
2. Analyst reviews existing functional decomposition models, process models or data
flow models, event diagrams or event lists, and other available documentation describing
business processes. It is particularly important to review process models created when
the system was designed.
3. Analyst conducts interview(s) with one or more staff from the business area to gather
information about major business functions and event processes. Again it is extremely
important to keep in mind that what we are asking staff to describe are business
requirements and not a list of implementation procedures. Initially, staff to be
interviewed should understand the responsibilities of the entire business unit for
identification of higher-level functions and events. As needed, other staff may be
identified as appropriate resources for identification of elementary processes.
Questions to be asked in every case:
** What are the major business functions and sub-functions of this business unit?
** What are the business processes undertaken to implement these functions? In other
words, what are the event processes or transactions involved in performing this function?
** What are the business events that trigger an activity and cause records to be produced?
** What are the elementary processes that are initiated in response to these events?
These processes will include: creating a new occurrence of an entity (add); updating an
occurrence of an entity (change or modify); and deleting an occurrence of an entity.
4. Analyst creates a narrative statements describing 1) the various business processes for
the function(s) under review, and 2) each event process transaction, including information
on the name of the event process, input activities, and output activities.
5.Analyst creates a functional decomposition diagram that depicts the relationships
between and among functions and business events or transactions for the function(s)
under review.
6. Analyst creates models or depictions of the business event processes, including
information on the inputs and the various elementary processes or outputs.
7. Analyst creates a list of the records that are created as products of the processes under
review.
8. Analyst compares any logical models of business processes created when the system
was designed with the business models generated during interviews with system
managers and identifies and describes any differences in the two models.
9. If there are differences in the definition of processes and records creation, the analyst
will work with record creators and data managers to reconcile difference and come to a
agreement on the products of the business processes.
Examine functions proposed at a particular level to see if they fit within a higher
level function. Even a major business area typically has only six to twelve first-
level functions. Second-level functions typically have between three and eight
third-level functions. (Low numbers are very common.)
REQUIRED MATERIALS:
1. Functional Decomposition models, Process models, or other descriptions of the
business requirements.
2. Other documentation that depicts or models the business requirements, such as Event
lists, Event-Response models, and Data Flow models.
DELIVERABLES:
1. Decomposition descriptions and diagrams of business functions, event processes or
transactions, and elementary processes currently being undertaken.
2. Lists of the records that are being received into the system and that trigger event
processes and of the records that are presently being produced by the elementary
processes.
3. If required, descriptions or depictions of how the current business processes differ
from the set of business requirements created in the systems design stage.
4. If required, a description of how differences in the analysis of business processes
were resolved.
The goal of this step is to determine how the records received or generated by each
business event process described in Step 1 should be managed and documented by the
new system. To determine this, the analyst develops design specifications derived from
the IU Functional Requirements document. The Functional Requirements are system
level requirements, and therefore are meant to be applied at a much higher level than the
individual record. In other words, for all the Functional Requirements the analyst will
begin by reviewing and analyzing how the requirement should be met at the highest-level
sub-function for the business function under review. For example, in the decomposition
model depicted above, this would mean analyzing as a body all records produced by the
three sub-functions and the six business transactions for the high-level sub-function
“Degree Recording.” If during the analysis it becomes clear that the records produced in
the course of completing lower-level sub-functions should be managed differently than
the records of related sub-functions, the analyst will then proceed to analyze the records
at the next lower level. For example, in reviewing the system for the requirement
“Authenticity,” the analyst discovers that rules for modification of records for the sub-
function “Enrollment Certification” should be different than for the sub-function “Degree
Certification.” Once this difference is discovered, the analyst would immediately adopt a
strategy of reviewing separately the products of business processes for each of the lower-
level sub-functions. Similarly, if different procedures should be undertaken at the level of
the business transaction, then the analyst will begin the analysis of the system for that
requirement at the level of the business. However, this will be a rare occurrence. In the
vast majority of cases, the analysis of the system in terms of the IU Functional
Requirements will be at the highest sub-function level.
WORK STEPS:
1. Analyst gathers available documentation on systems, standards, procedures, retention
schedules, etc. Prominent categories of documentation include: Processing descriptions
with models, if available; procedure manuals and workflow models relating to routing,
inputting, updating, saving and deleting records; procedure manuals relating to backing-
up, migrating, purging, exporting and restoring data; documentation on data and data
models to determine what types of informational value may be present in records;
procedures that define access and use of records, and training procedures; existing
disposition schedules and laws, policies and best practices related to recordkeeping;
policies and procedures dealing with security and authorization mechanisms;
documentation describing predefined reports and inquiries; and documentation
describing specific applications that are part of the system, including on-line processing
transactions and batch jobs.
2. Where documentation is unavailable or lacks details, the analyst interviews staff and
administrators who are familiar with the how the system processes and manages data and
records.
3. Using the functional decomposition analyses and system documentation, the analyst
reviews how the system should be managing records in accordance with the
“Requirements for Electronic Records Management Systems.”
REQUIRED MATERIALS:
1. Functional decomposition analyses from step 1.
2. System documentation.
3. Other documentation (e.g., procedure manuals, policies, retention schedules).
4. Notes from interview with staff and administrators
5. IU Functional Requirements statement.
DELIVERABLE:
1. Responses will be organized at the highest level sub-function, and only will include
analysis at lower levels as needed. Within each sub-function, the responses will be
arranged according to the list of Functional Requirements and will address the issues
defined for each requirement. For each requirement, prepare a brief narrative statement
describing how the system should be meeting the requirement.
The goal is to define the type of “evidence” required to document the records outlined in
step 1. In determining how the system should be documenting records, the analyst will
be guided by the specifications for recordkeeping listed in the Metadata Specifications
statement. Records within business events and even business sub-functions often will
include the same types of metadata. This is particularly true for so-called “management”
metadata that document why and how records will be accessed and used, disposed of, and
preserved. In most cases, the type of metadata collected to document these activities will
be the same for many, many records within a business process. Even audit trail metadata
documenting activities performed on individual records is predictable because so much of
this type documentation is collected automatically by the system and applied to many
records within a business process. Finally even types of metadata that are unique to a
specific record, such as the unique identifier, can be analyzed at the aggregate level by
asking the question: for records of this class or function, does the system assign a unique
identifier. Again, it is important to remember that what we are analyzing is whether the
system collects or creates this category of metadata and not whether the metadata value is
correct or not. Accordingly, as with the functional requirements, the analyst will begin by
reviewing and analyzing how the metadata specification should be met at the highest-
level sub-function for the business function under review. If during the analysis it
becomes clear that the records produced in the course of completing lower-level sub-
functions should be documented differently than the records of related sub-functions, the
analyst will then proceed to analyze the records at the next lower level. For example, in
reviewing the system for “Disposition” metadata, the analyst discovers that retention
periods for records within the sub-function “Enrollment Certification” are different than
for records in the related sub-function “Degree Certification.” Once this difference is
discovered, the analyst would immediately adopt a strategy of reviewing separately the
products of business processes for each of the lower-level sub-functions. Similarly, if
types of metadata collected at the level of the business transaction should be different,
then the analyst will begin the analysis of the system for that specification at the level of
the business event or record level.
WORK STEPS:
1. Analyst gathers available documentation on how the system will document data and
records. Prominent types of documentation include business process models, data
models, and data dictionaries.
2. Where documentation is unavailable or lacks details, the analyst interviews staff and
administrators who are familiar with the how the system documents data and records.
3. Analyst reviews how the system should be documenting records in accordance with
the IU Recordkeeping Metadata Specifications.
REQUIRED MATERIALS:
1. Functional decomposition analyses from step 1.
2. Documentation on how the system will be documenting records.
3. Notes from interview with staff and administrators
4. IU Metadata Specifications document.
DELIVERABLE:
Responses will be organized at the highest level sub-function, and only will include
analysis at lower levels as needed. Within each sub-function, the responses will be
arranged according to the list of Metadata Specifications and will address the issues
defined for each specification. For each specification, prepare a brief narrative statement
describing how the system should be meeting the metadata specification.