1.1 System Objectives
The Serial Control Record(SCR) Builder is a software system which will
provide librarians of the University of Southern California(USC)
an automated tool to build the SCR database. The SCR
database is a database used by SIRSI library information system, and contains
information about the serial publications like journals and magazines.
The USC libraries have three different input sources for the
serial publications information - USC Record, Orion Record, and FAXON Record.
Each record has its own format, and contains different information about
a serial publication. The SCR Builder is an
automatic translator which converts the three legacy record formats
into the SCR format.
Currently, the conversion from the legacy data into the SCR data is
done manually by the librarians. Currently, there are over 15,000 records
to enter into the database. And each Serial Control Record has
about 80 data fields to be filled. Because of this, it is very time consuming
and has a high possibility of inaccurate and inconsistent conversion due to
the human error.
The SCR Builder is composed of a record converter(batch processor, BP),
mapping table editor, and exception editor. The record converter is a
batch processing
program which automatically converts the three legacy record formats into the
SCR format. By using the mapping table editor, the user can adjust the
mapping conditions to improve the conversion quality.
The exception editor is a convenient tool to browse and edit
the records which cannot be correctly converted into the SCR
records by the batch processor. A Serial Control Record contains several
required fields which are essential for a serial publication. If
one of the required fields of a record cannot be filled by the
record converter, the record is marked as an exception record and then
the librarian is notified of the exception record which the librarian has
the option to manually edit.
All the components of the SCR builder have graphical user
interfaces(GUIs), by which the librarians can interact with the system
in a user-friendly manner to start, adjust and monitor the converting
process, and browse and edit the exception records. The conversion
status monitor, the mapping table editor, and the exception record
editor interfaces are the major user interfaces of the SCR
builder.
The BP status monitor provides the user
an interface to specify the conversion process and start or stop the
process. Also it shows the user the current status of the conversion
process like the number of records processed, the number of exception
records generated, the number of errors occurred, the time elapsed,
etc. By using this interface, the user can manage and monitor the
conversion process.
Through the mapping table editor, the librarians can adjust the
conversion process by editing the mapping table. When a test run of
the record converter generates a lot of exception records, the users
can specify specific mapping conditions through this interface to
reduce the number of exception records in the real conversion process.
This can make the conversion process more flexible.
By using the exception editor, the users can browse and print the
exceptions and system errors which are generated during the current
conversion process. The user can select an exception record and fill
the unconverted fields of the record manually. This editing
function makes the SCR building job more robust and flexible.
The SCR builder will provide the USC libraries a fast, flexible,
accurate, and user friendly software system to build the SCR database
for the serial publications.
1.2 System Scope and Context
Figure 1.1 is the high-level block diagram of the system and shows the
system scope of the SCR Builder and the users of
the system. The dotted-box indicates the system scope. Four major
components are inside the system - the record converter, mapping table
editor, exception editor, and serial control record database.
The record converter gets input data from the three major input
sources, converts the data formats into the SCR format and stores the
data into the SCR database. By using the mapping table editor, the
user can adjust the mapping conditions to corrdinate the conversion
process. The users can browse all the exceptions
and system errors generated during the conversion process by using the
exception editor, and edit the exception records manually and store
them into the SCR database. The users of the SCR builder will be the
USC librarians who are in charge of the building the SCR database.
The USC Record, Orion Record, and FAXON Record are the three major
legacy record formats of serial publications which need to be
converted into the SCR format. These input record formats are
different from each other and electronically available.
Figure 1.1 System Scope Block Diagram
Outside the system scope, there are the existing SIRSI interface and
the computing infrastructure. The existing SIRSI interface allows the
librarians to access the SCR database and
provide the librarians the tools to manage the SCR database. The
general USC library patrons(students, faculty and staff) can access
the catalog of the serial publications through the USC library Web
site which interacts with the SIRSI interface.
The USC UCS(University Computing Services) computing environment is
the basic infrastructure for the library information system. All the
servers and the network systems are operated and managed by the
UCS.
Figure 1.2 represents the use cases of the system. There are five
stakeholders who work with this system. The record conversion
operator initiates the conversion batch processor, the SCR editor
staff uses the exception editor and edits the exception records which are
generate by the batch processor, and the exception records are managed
by the exception record database manager. The mapping coordinator
adjust the mapping table by using the mapping table editor to improve
the mapping quality and the system manager monitors and maintain the
system and ensures the normal function of the system.
Figure 1.2 System Use Case Diagram
3.1 Current System Overview
The large number of serial publications like journals and magazines
are received each day by the USC libraries. So the libraries need a
database of serial publications to maintain information about
the journals and magazines, and keep track of currently available
issues. The Serial Control Record database is the database for the
serial publications and is now in the process of being built. The
SIRSI library information system accesses this SCR database, and
provides catalog services to the library patrons.
In order to put correct information about a serial publication into the
SIRSI's SCR database, several different input sources should be referenced
up and searched. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. These input sources are taken from different
institutes who use different record formats. The order and
representation of the data items for a serial publication are
different among the input sources.
Figure 3.1 Current System Block Diagram
Figure 3.1 shows the block diagram of the current system.
Currently, the SCR database is constructed manually by the librarians.
The librarians take a look at the actual journal and bibliographic
information of the publication and collect data for the SCR.
Our product will automate the conversion process which is being done
manually by the librarians. The dashed-box in the figure indicates the
part of the current system which will be replaced by the automated system.
After building the SCR database, the information about
the serial publications is available to the library patrons
through the SIRSI interface. The library patrons like students,
faculty, and staff of USC can see the catalog of the serial
publications through the USC library Web site. Also the librarians can
manage the SCR database after loading by using the the SIRSI user interface.
They may add a new record, delete a record, or modify the information
of a record through the SIRSI user interface.
3.2 Current System Shortfalls
The current manual conversion system has several shortfalls which are
originated from the nature of human behavior or resulted from human
faults. The conversion process is a mechanical and repeted task, and
the amount of the data to be converted is very huge. So it will take
unreasonable amount of time and efforts to finish the conversion task.
Also for this kind of mechanical and repeated task, people can easily
be mannered by the work and make them to generate many errors during
the task. Followings are the summary of the shortfalls of the current
system.
There are about 15,000 records of the serial publications which need
to be entered into the SCR database.
And each Serial Control Record has about 80 data fields which should
be filled after the conversion process. So the manual
process is a very time consuming job which will take more than
10 years to complete.
To reduce the database building time, USC libraries needs more
librarians to do the process in a parallel
manner, and this will increase the costs of the SCR database
building process.
The manual process of building SCR database may lead the
database to contain incorrect information due to human mistakes.
It is possible that the librarian misinterprets the
information of the serial publication and puts the information
into the database incorrectly.
When the conversion process is done by several librarians in a
parallel manner, the conversion result may be inconsistent.
Even though they use the same decision procedure for the
conversion, some data fields of the SCR need human decision to be
filled with certain data which should be selected from several
choices.
As a result of the WinWin negotiation, we decided the changes to
the current system for automating the current manual process and
providing efficient tool to build the SCR database. Following sections
are the description about the changes, priorities, rationale, and
changes rejected.
4.1 Description and Prioritization of Changes
Priority: Essential
The record converter of the SCR Builder performs the automated
record conversion job. It accepts data with the legacy record formats
and converts them into the SCR format data. This automatic conversion
capability will help the USC libraries to build the SCR database
quickly and correctly.
Priority: Essential
The user can browse the exception records and system errors through
the exception editor. The exception editor explains the cause of
an exception by pointing out all the missing fields which are required
to convert the input record into the Serial Control Record. And the
user can edit the missing fields manually by using this editor.
Priority: Desired
Through the mapping editor, the user can specify specific mapping
conditions for a conversion process to reduce the exception records
and improve the accuracy of the conversion. This capability will make
the conversion process flexible enough to adjust the mapping condition
of the record converter depending on the information quality of the
input sources.
Priority: Essential
The record converter shows the status of the conversion process refers
to the progress as to how much records have been processed, how
many exceptions and errors have occurred, how long it has been working
and other important information.
The user may need these metrics not only as an indicator that
processing is going on but also to measure the efficiency of the
system.
Priority: Essential
The system provides the facility to print out
the exception records generated and system errors happened.
The contents of the result records will be printed in the human
readable form.
Priority: Desired
This system may be developed as a general record converter
which is able to solve a general mapping problem. But the
general mapping problem is not currently required by the USC
libraries. Also, to develop the general mapping system,
more time and efforts should be spent. So, instead of
providing the general converter, we will make the system
as general as possible to adapt the basic algorithm to other
products or easily extended for future demands.
Priority: Essential
This program provides the hypertext help system to assist users to
interact with this system easily and correctly. All the help messages
are descriptive enough to be understood by the users - the USC
librarians.
Priority: Essential
Only authorized users are able to access the system because this system
deals with important data related to the serial publications.
The users of the system will be registered and managed by an
authentication subsystem. The system will provide a log-in
session prior to access the system to prevent unauthorized
accessing of the system.
The working environment of the system which the library client
offered is based on the computer
and campus network environment which is supported by the USC UCS.
The record converter batch-processor will run on the
library's dedicated server which is a SUN Ultra Enterprise 4000.
And the record converter client interface and the exception
editor will run on a Mac or a PC.
So, the developer should consider the UNIX environment for the
batch processor and TCP/IP for the communication between
client programs and the server program.
There are approximately 15,000 records to be converted into
the SCR format.
Currently, there are at least three different input sources
for constructing the SCR database. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. To improve the quality of the record conversion,
the user may add extra input sources to the converter.
This software system automates the record conversion process
hence the SCR database construction process will be done
in a faster way than the current manual process.
This determines whether or not the system is usable to the
librarians. Currently, the quality of the converted data
depends on the librarians who use it and the input sources.
By automating the conversion process, the quality will not
depend on human error. Also the user can add another input with
another format which is different from the three major formats
when the mapping process generates too many exceptions and
cause the results to be unacceptable.
This is related to the second capability rationale, and allows
the user to adapt the mapping table to the specific input
source they have at hand. An efficient description mechanism
is needed to express the relationship among input sources and
among fields in a record which should be considered while
converting the record.
The capability of allowing several input sources is required
because not one format contains all the necessary information
to convert a record successfully.
When the conversion batch processor generates data for a field of a
SCR, it should consider the three input
sources in a prioritized order to avoid conflicts among
the different input sources.
The user can prioritize the input sources for a SCR field by
using the mapping table editor.
The system will take in priorities of the input sources and based
on those priorities, resolve any conflicts that arise from the
different input formats.
The potential users are the USC librarians including
library staff and faculty. They
are experts on library systems but they may not be proficient with
computer systems. Therefore, all
the user interfaces of the system will be presented with
GUIs(Graphic User Interfaces) which look and feel like the
current SIRSI's Unicorn editor. This will have an impact on the
amount of training needed and consistency of user interface.
This is necessary since we would like to have more than one
staff member work on the exception records. This also
includes the fact that we want the library staff (or the
users) to be able to edit the SCR directly if there is no
automatic way to map the available data.
The system has the capability to explain the cause of exceptions
which occur during the conversion process. The
explanation of an exception will help users edit
the record efficiently. The
explanation will point out all the missing fields which are required to
transform the input record into the SCR format record.
For major hardware related faults, the record conversion
process will stop, produce an error message and exit cleanly.
For minor problems that will not can be recovered from, the
system will just log the error in some error file and explain
the cause of the error.
The system will provide capability of browsing system
error messages to check the error messages which occurred
during the conversion process. The user may browse the error
messages during or after the conversion processing in order to
check the mapping process.
The system provides an authentication subsystem to permit only
authorized users to access the system.
The system provides the on-line help subsystem to support
users the hypertext help messages. All the help messages are
descriptive enough to assist users to use the system
properly.
The context sensitive help would be very useful to the user. However,
for this system, user is aware how they do with this
system, therefore context sensitive help may not necessary.
Also, in order to build the context sensitive help system, more time
and effort is required. So the system will support the plain
hypertext help system.
It was considered to save old master files and maintain
transaction files to rebuild the result file rapidly after a
system crash. However, the time for the automatic conversion
is relatively very short time than the time for manual
conversion. Also it is more important to improve the
success rate of the conversion than to maintain the tracsaction file.
If the success rate is high enoght to generate small number of
exception records, it will take short time to do again the
transactions for editing exception records after a system
crash. So we decide to focus more on improving the success
rate than the recovery mechanism.
5.1 Operational Overview
Figure 5.1 Operational Overview Diagram
Figure 5.1 shows the operational overview of the SCR Builder. The
upper half part of the diagram is the part for this system.
The conversion batch processor in the record converter gets input data
from the three major input sources, converts the data formats into the
SCR format.
The result of the batch processing is not stored directly into the SCR
database. The converted Serial Control Records are first collected
into the Specific Data Format(SDF) files which are the intermediate
results of the conversion. After editing the exception
records and veryfying the correct conversion of the source records, the SDF
files are loaded into the SCR database by the Automatic Generator
which is a batch loading program.
The potential users of this system will be the USC librarians who are
in charge of the SCR database building work.
The user can indicate specific mapping conditions to the conversion
process by using the mapping editor interface provided by the
conversion editor. And during the
conversion processing, the user can monitor the current conversion
status through the status monitor interface of the record converter.
The status information
consists of the number of records processed, the number of exception
records generated, the number of errors occurred, the time elapsed,
etc.
During and after the conversion processing, the user can browse and
print all the exceptions and system errors generated during the conversion
process by using the browsers in the exception editor, and edit the
exception records manually and store them into the SDF files.
The user should give some authentication information before login into
the system. Only authorized users are able to access the system.
The authentication system provides a mechanism to manage the user
accounts and a system manager can add, delete or modify the user
information.
Also this program provides the hypertext help system to assist users to
interact with this system easily and correctly. The users can access
the help system any time they want. This help system is not described
in the figure as a separate component, but all the components in the
system includes their own help system.
5.2 Operational Stakeholders
The potential users of the SCR builder will be the USC
librarians including the library faculty and staff
who are in charge of the SCR database building process. This
system is not a system which provides services to the general
library patrons.
Among the system users, the record conversion operators are
the people who initiate the conversion batch processor and
keep track of the correct operation of the conversion
processing by checking the status messages generated.
These are the people among the system users who can determines
the mapping conditions and adjust the mapping table by using
the mapping table editor. The mapping conditions are depend on
the type of the input sources.
These are the librarians who can decide reasonable information
need to be filled into the exception records. They are the users for
the exception editor. They also can figure out the major
exception patterns and inform the mapping coordinator to
adjust the mapping conditions to reduce the exceptions.
These librarians manage the exception record database and load
the SDF files into the existing SIRSI's SCR database after
finishing all the conversion process. They will manage the SCR
database to insert a new record, delete a obsolete record, and
modify incorrect records.
The USC library has one computer programmer who can manage and
develop computer softwares for the library information
system. This person will be the major system manager of the
SCR database builder. He will manage all the server and client
site programs and detects abnormal operations of the system.
He/She can solve minor problems on the computer system or the
software system, and in case of the major software problems,
he/she can contact to the system developer to solve the
problem. Also the system manager will manage the user accounts
of the system. He/she can add, modify, or delete a user
by interacting with the authentication subsystem.
All the system working environment including the servers and
the network systems are operated and managed by the UCS people.
people. They are usually experts on computer systems and
network systems.
The potential users of this SCR builder are not experts on computer systems,
but they may be familiar with the existing SIRSI system.
So, this system will provide the users GUIs which look and feel like the
current SIRSI's interface. The users can easily and quickly learn
these interfaces after several trials. All the messages from the
system will be descriptive enough to be understood by the users. Also
the hypertext style help system will be included into the system.
The record mapping coordinators may have deep knowledge about the
different record formats of the serial publications. They can define
the mapping
conditions and adjust the condition depending on the quality of the
input sources. Also they will use the exception editor to convert
manually the exception records which cannot be converted by the
automatic converter. They will decide which data is most appropriate
for a certain data field of a exception record.
The system manager is proficient with computer systems
and software systems. He can detect problems on the computer or
network systems and solve minor problems or report major problems to
the UCS. Also he can manage the large scale software systems.
The SCR database builder will be used at the first step of the SCR
database construction work. After loading the SDF files into the
SIRSI's SCR database, this system may not be needed to be used again,
but this system may be used for the other record conversion works in the
future by modifying small portion of the program and mapping conditions.
Figure 5.3 Data Flow Diagram
Figure 5.3 show the overall data flows of the system. The input records
are converted into the SCR format data by the conversion batch processor.
The batch processor need the mapping table to decide the mapping conditions
for the conversion process. The mapping table can be modified by using the
mapping editor. All the records which are successfully converted
into the SCR format is stored into the SDF files. The exception records
which cannot correctly be converted into the SCR format are saved in the
exception record file which will be accessed by the exception editor. And all
the system errors generated during the batch process will be logged into
the system error log file. The user can see the error messages by using the
error browser. Through the exception record editor, all the
exception records are manually edited and added into the SDF files. The SDF
files which are the results of the conversion batch processing will be loaded
into the SIRSI's SCR database by the automatic generator which is a program
component of the SIRSI system.
Figure 5.4 State Transition Diagram
The major system states and transitions among the states are summarized in
Figure 5.4. By entering the user authentication information, the users can
log-in to the program component they want to work on. They can run the user
manager program to manager the user accounts or run the mapping editor to
adjust the mapping conditions. Also they can start the conversion batch
processor and monitor the status of the conversion process through the
status monitor. The conversion batch processing will be end after converting
all the records in the source record files. During or after the conversion
processing, the users can browse and edit the exception records. Also they can
browse all the system errors generated.
When the record conversion operator initiate the conversion batch
processor, both the conversion status monitor and the conversion engine
will start. The batch processor fetches the input file format
specification which indicates the next input source to be
converted. The records in the input source are converted into SIRSI's
SCRs by using the mapping table. All the exception records which
cannot be converted into SCRs are saved into the exception record
repository. The user can monitor the current conversion status and may
stop the process when the status shows an unacceptable low performance
or critical system errors. Also the user can make the conversion
process to resume to the point where it is stopped after adjusting the
mapping conditions or fixing the system problems.
Figure 5.5 shows the sequence diagram of the record conversion operation.
The SCR editor staff can login to the exception record editor, edit the
exception records and store the modified record into the SCR database.
Each exception records are verified by the user, and fetched into the
exception editor, edited by the user, and stored into the database.
He/She also can browse the reason of exceptions and print the
exception records. The SCR editor staff can get help messages about
browsing and editing exception records.
Figure 5.6 Sequence Diagram of Editing Exception Records
The mapping coordinator can edit the mapping table to improve the
conversion quality by using the mapping table editor. The mapping
table editor opens the mapping table as following the user's request
through the mapping interface, and modifies the fields and conditions in
the table with the new values given by the user. The user can
manipulate the mapping conditions either by creating new mapping table or
opening existing table.
Figure 5.8 Sequence Diagram of System Monitoring
The account management mode can be operated independently from the
record conversion process. All the valid user accounts are managed at
this mode. The system manager can add, delete or modify the user
account information through the authentication system.
The conversion batch processor also can be run in the command-line mode
other than the GUI mode. The user can log-in and execute the batch processor
in the command-line mode and monitor the conversion status through the text
mode interface.
All the operation mechanism and system status are same as the GUI
mode. The user can select the interface mode when he/she runs the
conversion batch processor by specifying an option. If the user want
to run the program through a text mode terminal, he/she can select the
text-mode interface instead of the GUI. Figure 5.9 is the
additional state diagram which shows the selection of the interface
mode before login to the system.
The purpose of this system is to automate the record conversion process for
building the SCR database which is currently done by human. So the system
should be more efficient and correct than the current human processing.
The followings are the quality attribute goals of the system in the viewpoints
of the performance, correctness, consistency, flexibility,
portability, security, availability, maintainability, and usability.
The automated record conversion should be faster than
the current manual conversion system. Currently, the manual conversion
takes about 15 minutes to convert a record.
Also there are about 15,000 records to be converted into the SCR format
records. So it will take very long time to complete the conversion
work by human. By using the automated system, the conversion work
should be able to finish in several days including the exception
editing process.
The librarian suggested a guideline of the success rate of
the record conversion. It is about 70% of the total
records from the source files. The record conversion
process should satisfy this guideline and generate
exception records less than 30% of the total records.
The current manual conversion may not convert all the records
correctly, because there may be some human mistakes while the
conversion process. It may be possible that the librarian
misinterprets the mapping table and puts incorrect data into the
target record fields. Also the mistyping is one of the major
mistakes which can be happened during the human conversion process.
The automated system should be able to avoid all these human mistakes
and convert all the source records into the desired format records
correctly.
To reduce the total time for the conversion process, several people may
work together. In that case, it is possible that different person
converts a same field of a record differently by applying
different possible mapping conditions.
The automatic converter should contain a well-defined rule to apply
the mapping conditions to a conversion consistently.
The mapping tables for the automated conversion process will be
built by the record mapping coordinators. They have to test
their mapping tables and check whether the conversion process works
well with the mapping tables before adapting those tables at the
real conversion. In the case of inefficient conversion, they
need to adjust their tables to reduce the number of exception records.
So, the system should be flexible enough to work with various mapping
tables and provide the way to modify the mapping tables.
The libraries have different types of machines to execute the client
programs of the system - the conversion status monitor and the
mapping editor. Those client programs should be portable enough to be
run on the different machines in the libraries. The SUN workstations,
Mac's and PC's are the machine types which will be used to run the
client programs.
The system should provide an authentication mechanism to protect
invalid operations on the system. Only the authorized users should
be able to use the system.
In Major Hardware failure, the system should log an error and
quit processing while in a minor subsystem failure, we can log
an error and still continue processing. So the system should
be as available as possible and after a major
failure the system should be able to continue processing from
where it left off.
By using the mapping table editor, the user can change the
mapping conditions to improve the success rate of the
conversion. Also the user can indicate more input sources and
prioritize the input sources to improve the efficiency of the
conversion process.
The mapping table editor should be easy to use and
the exception editor should be similar to the current editor
in use, SIRSI's Unicorn Editor, because the users are familiar
with this existing editor. These features will make the users
to interact with the new system efficiently. Also the batch
processor must have both command-line based and GUI based
interface, because a user may run the conversion batch
processor either through a terminal which provides a windowing
system or through a remote dummy terminal.
The library expect the system to be run on the current
computing environment in the libraries.
The current working environment of the system is based on the computer
and campus network environment which is supported by the USC UCS.
The record converter batch-processor will run on the
library's dedicated server which is a SUN Ultra Enterprise 4000.
And the record converter client interface and the exception
editor will run on a Mac or a PC.
So, the developer should consider the UNIX environment for the
batch processor and TCP/IP for the communication between
client programs and the server program.
There are approximately 15,000 records to be converted into
the SCR format.
Currently, there are at least three different input sources
for constructing the SCR database. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. To improve the quality of the record conversion,
the user may add extra input sources to the converter.
The system manager will be responsible for managing all the server and client
programs and detecting abnormal operations of the system. The system manager
should be able to solve minor problems on the computer system or the
software system, and in case of the major software problems, he/she can
contact to the system developer to solve the problem.
The SIRSI's Automatic Generator(AG) is located out of the scope of our
system, but it will make the result of the conversion process
available to the library patrons. The SDF files which are the result
of the conversion process will be loaded into the SIRSI's SCR database
by this AG.
All the system working environments including the servers and the network
systems are operated and maintained by the UCS. They will fix all the problems
related to the computer and network systems on which the SCR builder system
works.
6.1 Mainstream Scenarios
Figure 6.1 Log-in
Figure 6.2 Start/Stop/Resume Batch Processor
Figure 6.3 Editing Mapping Conditions
Figure 6.4 Editing Exception Records(The first page of the interface)
Figure 6.5 Browse and Print Exception Records
Figure 6.6 Browse and Print System Errors
The user can log-in to the conversion batch processor under the
command line and do the operations in the text mode. The
authentication step can be done by putting the user ID and
password as following the directions from the system. And user
can start the conversion batch processor by sending a
command and check the conversion status through the text
mode monitor interface.
Figure 6.7 User Account Management
7.1 Operational Impacts on the System
This system will automate the current manual conversion works and the SCR
database can be built in a shorter time and will contain more accurate
data of the serial publications.
7.2 Operational Impacts on Stakeholders
By automating the record conversion process, the large amount of time and
efforts of the librarians to convert the huge number of records can be saved.
And more accurate informations about the serial publications will be available
to the library patrons more early.
7.3 Impacts during Development
All the feed-back information from the librarians about this system will be
considered carefully to develop more efficient and usable system.
Also the frequent interaction between the developers and the library
customers will help us to detect and correct the incorrectly designed parts of
the system as soon as possible.
The SCR builder will automates record conversion works and provide
the USC libraries a fast, flexible, accurate, and user friendly software
system to build the SCR database for the serial publications.
The initial prototype is developed to demonstrate the GUIs and show
the operation mechanism of the SCR builder. The prototype can be
tested through the Web browsers by connecting to the following address.
http://nunki.usc.edu:8082/~cs577/team3/prototype/LCA/team3.html
4.2 Assumptions and Constraints
4.3 Rationale for New Capabilities
4.4 Changes Considered but Not Included
5.2.2 Operational Assumptions
5.3.1 Viewpoint of Record Conversion
Figure 5.5 Sequence Diagram of Record Conversion
5.3.3 Viewpoint of Editing the Mapping Table
5.4 Operational Modes
5.5 Quality Attribute Goals
5.6 Operational Policies and Constraints
5.7 Support Concepts
6.2 Variant Scenarios
6.3 Exception-Handling Scenarios
6.4 Support Scenarios
