A Methodology for Evaluating Existing Information Systems As Recordkeeping

Systems 2002 ersion

!he Indiana "niversity Electronic Records #ro$ect
I%!R&'"(!I&%
In using this methodology it is important to recognize the collaboration between archivists
and the IT community, whose vocabularies at times do not quite match. This methodology
is centered around archival and recordkeeping concepts, but facilitated by practices
common to the IT community. Perhaps the language is most at odds with the term record.
In the IT context a record might be thought of as a data structure representing an element
of a file. owever, in the context of this methodology, a record is evidence of a business
transaction. !n understanding of this usage of record is essential for success with the
methodology, as is an understanding of other terms "which can be found in the glossary
and throughout the text# and of the $unctional %equirements and &etadata 'pecifications
"also in the appendix and discussed later in the text#. In general, the focus here is on
information as it satisfies requirements of authenticity and evidence.
'everal 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. !
methodology for analysis of new systems is outlined in a separate document. !nalysis of
existing systems is normally a more time consuming, more difficult process. It involves
not only specifying requirements and metadata specifications and a list of records to be
captured. It also requires an analysis of how the present system is managing the data. In
essence, the process involves analysis of )what is* as depicted by models and system
documentation with )what should be* as defined by the requirements, specifications and
models. &ore specifically, analysis of existing systems includes the following activities+
,# a description and analysis of the business processes by means of a technique known as
)modern structured analysis,* -# a description of how the information system is presently
managing records of the identified processes, .# an evaluation of the information system
against the $unctional %equirements and &etadata 'pecifications in the context of the
identified business processes, and /# recommendations for intervention to satisfy the
$unctional %equirements and &etadata 'pecifications.
!lthough represented in the text as distinct phases, the reality is that thought processes
don0t necessarily work in a step1by1step fashion. ! methodology may portray a progression
through specific steps, but a person using the methodology should be able to consider
multiple factors at any point through that progression. The entire methodology document
and supporting materials should be reviewed and understood before proceeding with its
use.
1
Step )* 'ES(RI+I%, A%' M&'E-I%, +"SI%ESS #R&(ESSES
In this initial step of the methodology, the primary goal is to construct a representation of
the logical processes of the business, i.e., to create a conceptual model of the work or
activities that must be undertaken no matter how the information system is implemented or
who does the work. To identify these processes, the methodology uses concepts derived
from 2modern structured analysis2 techniques such as those advocated by 'tephen
&c&enamin, 3ohn Palmer, and 4dward 5ourdan. This form of analysis has been defined
as )a process1centered technique that is used to model business requirements for a system.
The models are structured pictures that illustrate the processes, inputs, outputs, and files
required to respond to business events.* 63effrey 7. 8hitten and 7onnie 9. :entley,
'ystems !nalysis and 9esign &ethods, /
th
ed. ":oston+ &c;raw1ill, ,<<=#, p. ,--.
9escription of the business requirements is undertaken by means of a process known as
decomposition . This process is a means of developing a top1down analysis of the
business system, and of breaking down the business system into smaller and smaller
processes and sub1processes. In accordance with )modern structured analysis*
techniques, the I> methodology decomposes logical processes "business activities that
must be undertaken no matter how one implements the system# into three components+
.unctions/ Event #rocesses or !ransactions/ and Elementary #rocesses0 In other
words, business systems are comprised of functions, which are decomposed into business
processes, which ultimately are reduced to business events, which normally represent a
single process responding to external and temporal inputs and result in one or more
outputs known as elementary processes.
In the decomposition process, the activities at the highest end of the business system are
known as 1usiness functions. ! function is a )set of related and on1going activities of the
business. ! function has no start or end? it @ust continuously performs its work as needed.*
"8hitten and :entley, 'ystems !nalysis and 9esign &ethods, p. -,=#. $unctions normally
are decomposed into sub1functions or into a more discrete and related set of on1going
activities. $unctions are named with nouns that describe the entire set of activities.
4xamples of functions and sub1functions from the business area of Affice of the %egistrar
include+ $unction+ 'tudent %ecordkeeping 1 'ubfunctions+ Afficial student record
maintenance, student degree maintenance, current semester information maintenance.
$unctions consist of business processes that respond to business events. ! 1usiness event
is )something that Bhappens,( and that causes business data to change.* 8hitten and
:entley, 'ystems !nalysis and 9esign &ethods, .
rd
ed., p. C-/#. !n event )is a logical unit
of work that must be completed as a whole. !n event is triggered by a discrete input and
is completed when the process has responded with appropriate outputs. 4vents are
sometimes called transactions.* "8hitten and :entley, 'ystems !nalysis and 9esign
&ethods, p. -,=#. There are three basic types of inputs that will trigger a business event
or transaction+ an external event that is initiated by agents outside the system being
reviewed, a temporal event that is triggered by the arrival of a predetermined point in
time, and a state event that is triggered by a system(s change from one state or condition
to another. &ost events or transactions are represented by a single process, although
occasionally, the event may include two or three processes. !n event process or
transaction is described in a single sentence that identifies the individual or agency
initiating the action "sub@ect1phrase#? the official action "verb1phrase#? and the individuals
2
or ob@ects acted upon or interacted with "ob@ect1phrases#. 4xamples of event processes or
transactions taken from the Affice of the %egistrar work area include+ $or 'ubfunction+
'tudent grades and credit maintenance, the event processes or transactions include+ ,#
Post grades for students upon completion of course work "Input+ grade roster from faculty
member, and Autput+ Dreate a grade and credit record#? -# !ssign credit for student work
done at other academic institutions "Input+ %ecord of work completed at another
institution, and Autputs+ Dreate a credit articulation or evaluation report, and modify
student record to reflect the decision#.
!n event process is further decomposed into elementary processes, which are defined as
)discrete, detailed activities or tasks required to complete the response to an event.*
"8hitten and :entley, 'ystems !nalysis and 9esign &ethods, /
th
ed., p. -,<.# In other
words, elementary processes are the outputs generated by the business event. Types of
elementary processes 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. The
methodology omits any processes that do nothing more than move or route data, thus
leaving the record unchanged. 4lementary processes are named with a strong action verb
followed by an ob@ect clause that describes the work being performed. 4xamples of
elementary processes from the $inancial !id work area include+ Dreate report listing
federal aid recipients with unsatisfactory academic progress, record appeal information in
student(s financial aid record, complete work1study verification form received from
employer, and provide certification information to the lender.
%ecord 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. $or example+ The business event )processing an appeal* is initiated or
triggered by a student or hisEher 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 ,# &aking and recording a decision on the appeal, -# &odifying the student(s
financial aid data based on the appeal decision, and .# Fotifying the student about the
decision. The appeal letter, the decision document, the modified student record, and the
notification are the records of the process.
4ventually 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. &odels designed to )depict the system
independent of any technical implementation* are known as logical models or essential
models. "8hitten and :entley, 'ystems !nalysis and 9esign &ethods, /
th
ed., p. -,G.#
!nd of the logical models, it is the opinion of the !rchives 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 I> methodology, staff normally create functional decomposition and
business event diagrams.
8hat types of information are contained in these models, and what do the models look
likeH To answer these questions, let us review the products !rchives personnel created
for the business function )'tudent %ecordkeeping.* !s a first step, business processes for
this function are defined in a short narrative statement. 4ventually this information is used
3
to generate a functional decomposition diagram for the function. ! partial diagram for the
function )'tudent %ecordkeeping*contains the following information and is represented in
the following manner.
Function: Student
Recordkeeping
Sub-Function:
Semester Data
Maintenance
Event Process: Dept.
Modif ies Course
Inventor.
Event Process:
Facu!t Modifies
C!ass Sc"edu!e
Event Process:
Student Modif ies
Course Se!ections
Sub-Function:
Student Record
Maintenance
Sub-Function:
#rade and Credit
Posting
Event Process:
$ssign #rade for
%it"dra&a!
Event Process:
$ssign #rade f or
Comp!etion
Event Process:
$ssign #rade for
'ransfer %ork
Event Process:
$ssign #rade
C"anges
Event Process:
$ssign #rade for
(t"er Credit
Sub-Function:
Degree Recording
Sub-Function:
$cademic Prof i!e
Maintenance
Sub-Function:
Enro!!ment
Certification
Sub-Function:
Degree Certification
Event Process:
Create $cademic
Prof i!e Event Process:
Modif $cademic
Prof i!e
Event Process: Post
Dept. Certif ication
Data
Event Process: Post
Certif ication From
I)Care $pp!ication
Event Process: Post
Dept. *ist of Degree
Recipients
Event Process: Post
Degrees From
I)Care $pp!ication
Ance 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+ Fame of process, input
4
activities, input record, output activities, and output record"s#. Ance this data is gathered,
staff creates business event diagrams for each of the sub1functions. $or 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.
+usiness Event Diagrams - Sub-function:
Semester Information Maintenance - Event
Process: Department Modifies Course
Inventor
Inventory Updates
Updates to Course Inventory
Modification Confirmation
Process: Modif Course
Inventor
Sstem Containing
Course Inventories
$cademic )nit
5
+usiness Event Diagram - Sub-Function -
Financia! $id $&ards - Event Process:
Processing an $ppea! Received from a Student
Record Appeal Information into Student's Record
Record Decision on Appeal into Student's Record
Modify Student's Record
Appeal Notification
Notification of Decision
Student
Process $ppea!
Sstem Containing
Student Financia! $id
Record
Sstem Containing
Student,s Financia! $id
Record
Sstem Containing
Student,s Financia! $id
Record
2&R3 S!E#S*
,. Pro@ect staff selects a business area for analysis.
-. !nalyst 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.
6
.. !nalyst conducts interview"s# with one or more staff from the business area to gather
information about ma@or business functions and event processes. !gain 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
higher1level functions and events. !s needed, other staff may be identified as appropriate
resources for identification of elementary processes.
Iuestions to be asked in every case+
JJ 8hat are the ma@or business functions and subfunctions of this business unitH
JJ 8hat are the business processes undertaken to implement these functionsH In other
words, what are the event processes or transactions involved in performing this functionH
JJ 8hat are the business events that trigger an activity and cause records to be producedH
JJ 8hat are the elementary processes that are initiated in response to these eventsH 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.
/. !nalyst creates a narrative statements describing ,# the various business processes for
the function"s# under review, and -# each event process transaction, including information
on the name of the event process, input activities, and output activities.
C.!nalyst creates a functional decomposition diagram that depicts the relationships
between and among functions and business events or transactions for the function"s# under
review.
K. !nalyst creates models or depictions of the business event processes, including
information on the inputs and the various elementary processes or outputs.
L. !nalyst creates a list of the records that are created as products of the processes under
review.
=. !nalyst 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.
<. 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.
2&R3 S!E#S* !I#S
4xamine functions proposed at a particular level to see if they fit within a higher
level function. 4ven a ma@or business area typically has only six to twelve first1
level functions. 'econd1level functions typically have between three and eight
third1level functions. "7ow numbers are very common.#
:e as comprehensive and complete as possible. !ssure that the list adequately
accounts for all ma@or activities of the area. !n outline form is appropriate for
representing the relationships between functions and sub1functions. !s with an
7
outline, balance is expected but not symmetry. $unctions at the same level should
have roughly the same significance, complexity, etc. owever, one second1level
function may have two or three third1level functions while others may have eight
or nine.
8ithout experience it is difficult to tell when the functional decomposition is
complete. The function list should be reasonably complete, but will not be
exhaustive. In general a third1level decomposition should be sufficient, but it may
be necessary to go further to gain enough detail for the identification of
transactions in the next task.
RE4"IRE' MA!ERIA-S*
,. $unctional 9ecomposition models, Process models, or other descriptions of the
business requirements.
-. Ather documentation that depicts or models the business requirements, such as 4vent
lists, 4vent1%esponse models, and 9ata $low models.
'E-IERA+-ES*
,. 9ecomposition descriptions and diagrams of business functions, event processes or
transactions, and elementary processes currently being undertaken.
-. 7ists of the records that are being produced by the elementary processes.
.. If required, descriptions or depictions of how the current business processes differ from
the set of business requirements created in the systems design stage.
/. If required, a description of how differences in the analysis of business processes were
resolved.
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect analyst
%eviewed by+ pro@ect staff, business area staff
!pproved by+ pro@ect staff
Information resources+ business area staff
8
Step 2* A%A-56I%, !7E S5S!EM I% !ERMS &. !7E I" RE(&R'3EE#I%,
RE4"IREME%!S
The goals of this step in the methodology are twofold+ a# describe or model how the
existing system is presently managing the records created by the business processes
identified during the analysis conducted in 'tep ,? and b# analyze these results in terms of
the I> $unctional %equirements.
In defining how the system is presently managing records, the analyst will rely heavily on
relevant documentation on system functionality and operations. 8here documentation is
non1existent or lacks detail, the analyst will interview knowledgeable staff who understand
how data is processed and managed in the system.
The goal in this step is to determine how the system is how the system is managing the
records under review. To determine this, the analyst will ask a series of questions derived
from the I> $unctional %equirements document. The $unctional %equirements 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 $unctional %equirements the analyst will
begin by reviewing and analyzing how the requirement is met at the highest1level sub1
function for the business function under review. $or example, in the decomposition model
depicted above, this would mean analyzing as a body all records produced by the three
sub1functions and the six business transactions for the high1level sub1function )9egree
%ecording.* If during the analysis it becomes clear that the records produced in the
course of completing lower1level sub1functions are managed differently than the records of
related sub1functions, the analyst will then proceed to analyze the records at the next
lower level. $or example, in reviewing the system for the requirement )!uthenticity,* the
analyst discovers that rules for modification of records for the sub1function )4nrollment
Dertification* are different than for the sub1function )9egree Dertification.* Ance this
difference is discovered, the analyst would immediately adopt a strategy of reviewing
separately the products of business processes for each of the lower1level sub1functions.
'imilarly, if different procedures are 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 event or record level. owever, this will be a rare occurrence. In the vast
ma@ority of cases, the analysis of the system in terms of the I> $unctional %equirements
will be at the highest sub1function level.
2&R3 S!E#S*
,. !nalyst 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 backing1
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?
9
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 on1line processing transactions
and batch @obs.
-. 8here 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.

.. >sing the functional decomposition analyses and system documentation, the analyst
reviews how the system is managing records in accordance with the )%equirements for
4lectronic %ecords &anagement 'ystems.*


RE4"IRE' MA!ERIA-S*
,. $unctional decomposition analyses from step ,.
-. 'ystem documentation.
.. Ather documentation "e.g., procedure manuals, policies, retention schedules#.
/. Fotes from interview with staff and administrators
C. I> $unctional %equirements statement.

'E-IERA+-E*
,. This document will be organized at the highest level sub1function, and only will include
analysis at lower levels as needed. 8ithin each sub1function, the responses will be
arranged according to the list of $unctional %equirements and will address the issues
defined for each requirement. $or each requirement, prepare a brief narrative statement
describing how the system does or does not meet the requirement.
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect analyst
%eviewed by+ pro@ect staff, business area staff, computing services staff
!pproved by+ pro@ect staff
Information %esources+ business area staff, computing services staff
S!E# 8* A%A-56I%, 7&2 !7E S5S!EM IS '&("ME%!I%, RE(&R'S I%
!ERMS &. !7E I" ME!A'A!A S#E(I.I(A!I&%S
10
The goals of this step in the methodology are twofold+ a# describe or model how the
existing system is presently documenting the records created by the business processes
identified during the analysis conducted in 'tep ,? and b# analyze these results in terms of
the I> &etadata 'pecifications.
In essence the goal is to determine if the )evidence* required to document the business
transactions exists and in what form. In other words, the primary ob@ective is to
determine whether the metadata category or element exists for that record or class of
records. The goal is not to determine whether the value provided for that metadata
element is correct or incorrect. !s in the previous step, the analyst will rely heavily on
relevant documentation to determine how the system is presently documenting records.
8here documentation is non1existent or lacks detail, the analyst will interview
knowledgeable staff who understand how data is processed and managed in the system.
In reviewing the documentation and determining how the system is documenting records,
the analyst will be guided by the specifications for recordkeeping listed in the &etadata
'pecifications statement. %ecords within business events and even business sub1functions
often will include the same types of metadata. This is particularly true for so1called
)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. 4ven
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. $inally 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. !gain, 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. !ccordingly, as with the functional requirements, the analyst will
begin by reviewing and analyzing how the metadata specification is met at the highest1
level sub1function for the business function under review. If during the analysis it becomes
clear that the records produced in the course of completing lower1level sub1functions are
documented differently than the records of related sub1functions, the analyst will then
proceed to analyze the records at the next lower level. $or example, in reviewing the
system for )9isposition* &etadata,* the analyst discovers that within the sub1function
)4nrollment Dertification* retention periods are specified, while for the related sub1
function )9egree Dertification* retention metadata is not present. Ance this difference is
discovered, the analyst would immediately adopt a strategy of reviewing separately the
products of business processes for each of the lower1level sub1functions. 'imilarly, if
types of metadata collected at the level of the business transaction are different, then the
analyst will begin the analysis of the system for that specification at the level of the
business event or record level.
11
It is also important to determine the nature of the logical relationship between the record
content and the metadata. Is the metadata part of the recordH Is it electronically linked
to the recordH Is the metadata a paper record whose location is electronically linked to
the recordH Ar is there no logical relationship between the metadata and recordH

2&R3 S!E#S*
,. !nalyst gathers available documentation on how the system documents data and
records. Prominent types of documentation include business process models, data models,
and data dictionaries.
-. 8here documentation is unavailable or lacks details, the analyst interviews staff and
administrators who are familiar with the how the system documents data and records.

.. !nalyst reviews how the system is documenting records in accordance with the I>
%ecordkeeping &etadata 'pecifications.

RE4"IRE' MA!ERIA-S*
,. $unctional decomposition analyses from step ,.
-. 9ocumentation on how the system is documenting records.
.. Fotes from interview with staff and administrators
/. I> &etadata 'pecifications document.
'E-IERA+-E*
%esponses will be organized at the highest level sub1function, and only will include
analysis at lower levels as needed. 8ithin each sub1function, the responses will be
arranged according to the list of &etadata 'pecifications and will address the following
questions+ a# 9oes the metadata existH :# 8hat is the logical relationship between the
metadata or a citation to the metadata and the record contentH
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect analyst
%eviewed by+ pro@ect staff, business area staff, computing services staff
!pproved by+ pro@ect staff
Information %esources+ business area staff, computing services staff
12
Step 9* EA-"A!E !7E S5S!EMS I% !ERMS &. !7E :."%(!I&%A-
RE4"IREME%!S .&R EI'E%(E I% RE(&R'3EE#I%,:
ow effectively does the existing system satisfy the requirements of a recordkeeping
systemH In this step, the results of the analyses conducted in steps , and - are evaluated in
terms of various categories of compliance.

2&R3 S!E#S*
,. Pro@ect staff review documentation produced by analyst in previous steps.
-. Pro@ect staff interview analyst, if necessary.
.. It may be necessary to conduct additional interviews with record creators or to review
the documentation so as to gather more specific or detailed information. 4ven with the
best efforts of the analyst in preparing documentation for the evaluation, the evaluator"s#
may require additional information or interpretation in order to evaluate correctly the
evidence collected during the previous analyses.
/. $or each sub1function the pro@ect staff evaluates the systems according to the following
criteria+ ow effectively does the system satisfy the requirements of a recordkeeping
systemH $or each of the Indiana >niversity $unctional %equirements, what evidence is
there that the system satisfies that %equirementH 9o not respond with a simple yes or no?
generate a brief narrative statement with specific examples of evidence that the
requirement is fulfilled or not fulfilled. In addition, classify the level of compliance in
terms of one of the following three categories+ ,# satisfied, -# partially satisfied, and .# not
satisfied.
RE4"IRE' MA!ERIA-S*
,. 9ocumentation from steps , and -.
-. Ather supporting documentation accumulated in previous phases.
.. Indiana >niversity versions of $unctional %equirements.
'E-IERA+-E*
,. ! document that for each high1level sub1function that describes the nature and level of
compliance with each of the I> $unctional %equirements.
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect staff
%eviewed by+ archivist
!pproved by+ archivist
Information resources+ pro@ect analyst
13
Step ;* EA-"A!E !7E S5S!EMS I% !ERMS &. 7&2 2E-- !7E5 MEE!
!7E I" ME!A'A!A S#E(I.I(A!I&%S
ow effectively does the existing system satisfy the I> &etadata 'pecifications. In this
step, the results of the analyses conducted in steps , and - are evaluated in terms of
various categories of compliance.

2&R3 S!E#S*
,. Pro@ect staff review documentation produced by analyst in previous steps.
-. Pro@ect staff interview analyst, if necessary.
.. It may be necessary to conduct additional interviews with record creators or to review
the documentation so as to gather more specific or detailed information. 4ven with the
best efforts of the analyst in preparing documentation for the evaluation, the evaluator"s#
may require additional information or interpretation in order to evaluate correctly the
evidence collected during the previous analyses.
/. $or each business event the pro@ect staff evaluates the systems according to the
following criteria+ Is the appropriate metadata "context, structure, and content# being
captured and preserved inviolate by the existing systemH $or each of the Indiana
>niversity &etadata 'pecifications, what evidence is there that the system satisfies the
'pecificationH !gain, do not respond with a simple yes or no. Dreate a brief narrative
statement with specific examples of compliance or non1compliance. In addition, classify
the level of compliance in terms of one of the following categories+ a# &etadata is
available electronically with use of record? b# &etadata is available in electronic or paper
format, and there is a logical relationship between the metadata or a citation to this
metadata and the record itself? c# &etadata is available in electronic or paper format, but
there is no logical relationship between the metadata or a citation to the metadata and the
record itself? d# &etadata is not available anywhere.

RE4"IRE' MA!ERIA-S*
,. 9ocumentation from steps , and -.
-. Ather supporting documentation accumulated in previous phases.
.. Indiana >niversity versions of the &etadata 'pecifications
'E-IERA+-E*
,. ! document that for each event process or transaction describes the nature and level of
compliance with the I> &etadata 'pecifications.
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect staff
14
%eviewed by+ archivist
!pproved by+ archivist
Information resources+ pro@ect analyst
Step <* RE(&MME%'A!I&%S
Ance the analysis of how the information system is managing records of the various
business processes is completed, staff meet to determine what recommendations will be
made for improving the performance of the system. 8e recognize that not all the problems
identified in the evaluation process will be of equal rank or of the same level or degree of
seriousness. Therefore there are three categories or levels of recommendations+ ighest
Priority %ecommendations, Doncerns, and $or 5our Information. 8hen making
recommendations for changes to recordkeeping systems keep in mind the costsErisks and
benefits associated with implementing that particular recommendation. 8e also recognize
that institutions will not likely implement every recommendation we make. The decision to
implement will be based on a variety of factors, including an appraisal of the value of the
records, costs and benefits, risk of retaining or disposing of documentation, and
organizational needs and priorities.
2&R3 S!E#S*
,. Pro@ect staff reviews the evaluation document for evidence of functional requirements
and metadata specifications that have not been met.
-. Pro@ect staff prepares a set of recommendations for improving the system based on the
three categories listed above.
.. Pro@ect staff prepares a report and presents the recommendations to appropriate
parties.
RE4"IRE' MA!ERIA-S*
,. The evaluation document from 'tep ..
-. 9ocuments from other phases if necessary
'E-IERA+-ES*
%eport of recommendations in the following format+
Introductory statement describing the scope and ob@ectives of the evaluation process
'pecific recommendations organized into the categories of+ ighest Priority
%ecommendations, Doncerns, and $or 5our Information. 4ach recommendation will
include an explanation of the problem and recommendations on how the unit might
15
address it. This document along with a short cover letter outlining the process is then
forwarded to the appropriate data stewards and managers for their review. 'oon after
transmittal of the report, a meeting will be scheduled to discuss the various
recommendations and implementation strategies.
R&-ES A%' RES#&%SI+I-I!IES*
Donducted by+ pro@ect staff, pro@ect analyst
%eviewed by+ archivist, business area staff
!pproved by+ archivist
!ccepted or %e@ected by+ business area staff
Information resources+ pro@ect analyst
16