Systems Analysis
for
Library Management
Robert M. Hayes
2002
Summary of Modules











Module 0.
Module 1.
Module 2.
Module 3.
Module 4.
Module 5.
Module 6.
Module 7.
Module 8.
Module 9.
Module 10.
Summary & Overview
Conceptual Framework
Supporting Software
Structure of Systems Analysis
Objectives & Requirements
Methods for Analysis
The Library Planning Model
Requests for Proposal
Measures of Performance
Issues in Determining Costs
Details of RFP
Module 0. Summary & Overview
Summary
 Contexts for Library Systems Analysis
 Methods for Dealing with such Tasks
 Supporting Software Tools




System Schematics
Steps in Systems Analysis
Stages in Systems Analysis
Approaches to Systems Analysis
Summary (cont.)




Definition of Objectives
Determination of Requirements
Functional Requirements
Methods for Analysis




Approaches to System Design
Requests for Proposal
Assessment of Effectiveness
Assessment of Costs
Overview
A. CONCEPTS, REQUIREMENTS DEFINITION, SCOPE
1. Introduction & Overview
2. Systems Analysis Concepts
3. Scope & Requirements
B. METHODS OF ANALYSIS
4. Dimensions of Analysis & Design
5. Data Structures
6. Description of Relationships among Dimensions
C. METHODS OF DESIGN & EVALUATION
7. Systems Design
8. Measurement of Effectiveness
9. Measurement of Cost
D. PROJECT MANAGEMENT
10. System Implement, Project Manage, Monitor
11. Software
Module 1. Conceptual Framework
Contexts for Library Systems Analysis









Implement Library Automation
Evaluate a New Library Service
Determine Staffing Assignments
Compare Alternative Means for Storage
Adapt to Institutional Priorities
Justify Budget Submittals
Plan a New Library Building
Develop Inter-Library Cooperation
Support National Library Policies
Methods for Dealing with such Tasks
Experience and Intuition
Politics and Negotiation
Trial and Error
Systems Analysis
Hermeneutics
Analogy
Systems Analysis
SYSTEMS ANALYSIS is derived from scientific and mathematical tradition. It
attempts to understand a phenomenon – which it calls a system – by breaking
it into successively more detailed component parts – the process of analysis –
until the parts can be understood in themselves, without further stages of
analysis.
The great strength of systems analysis is its ability to deal with exceptionally
complex phenomena and to provide means for dealing with them, especially
for pragmatic purposes.
The great deficiency of systems analysis is inherent in the very process of
analysis: The approach to analysis predetermines the final picture of the
phenomenon; the phenomenon as a whole may be destroyed; and essential
inter-relationships among component parts may be lost.
Of course, the methodology can in principle compensate for the deficiency by
providing means to reconstruct relationships and to identify larger contexts.
Hermeneutics
HERMENEUTICS is derived from theological and philosophical tradition.
Originally, it was a methodology for Interpretation, especially of scriptural
text. It attempts to understand a phenomenon by identifying its
relationships to other phenomena, ultimately encompassing the entire
universe.
The great strength of hermeneutics is its emphasis on inter-relationships
and the resulting ability to interpret interactions and to see the effects on
the whole.
The great deficiency of hermeneutics is that it provides no means to delve
into the structure of a phenomenon or to set boundaries on the scope of
inter-relationships to be considered. Inevitably, it thus must encompass the
universe.
Of course, the methodology can in principle compensate for the deficiency
by incorporating some methods of analysis and by setting boundaries on
the scope of phenomena to be inter-related.
Analogy
ANALOGY is derived from mathematical and pragmatic tradition. It
attempts to understand a phenomenon by identifying its similarities to
other phenomena, drawing analogies from them to suggest form, structure,
function, and operation.
The great strength of analogy is its ability to draw upon past experience
and bring it to bear on new situations without the delays that arise from
other approaches to dealing with new phenomena.
The great deficiency of analogy is that it fails adequately to deal with
essential differences, treating similarities as though they reflected identity.
As a result, it can lead to serious mis-understanding and disastrous results.
Of course, the methodology can in principle compensate for the deficiency
by assuring that essential differences are recognized and even emphasized
in developing understanding and, especially, in use of the understanding.
Module 2. Supporting Software
Supporting Software Tools




Word Processing, for Reporting
Spreadsheets, for Data Analysis
Database Management, for Data Storage
PowerPoint, for Data Presentation
 Computer Aided Systems Analysis, for Methods
 The Library Planning Model, for Evaluation
 Project Managers, for Planning & Control
Computer Aided Analysis Methods






Flow charting
Data Flow Diagrams
State Transition Diagrams
Structure Charts
Entity-Relationship Diagrams (ERDs)
Data Dictionaries
The Library Planning Model










Represent Workloads in User Services
Represent Workloads in Technical Processing
Estimate Staff Requirements for Workloads
Account for Overhead, G&A, and Expenses
Determine Requirements for Facilities
Allocate to Means for Storage and/or Access
Apply various Models of Library Operations
Optimize Means for Inter-Library Cooperation
Evaluate Future for Information Distribution
Assess National Information Development
Project Management





Establish Work Breakdown Structure
Determine Task Inter-Relationships
Schedule Sequence of Tasks
Assign Resources
Identify Schedule Conflicts
Module 3. Structure of Systems Analysis
Information System Schematic
Input
Communicate
Storage
Process
Feedback
Objectives
Communicate
Output
Hierarchy of Systems
National Policies
Cooperation Context(s)
Information Technologies
Political Context(s)
Information Sources
User Context(s)
Information Facilities
Administrative Context(s)
The Library as System of Focus
Sub-System 1
Sub-System 3
Sub-System 2
Sub-System 4
Steps in Systems Analysis








Define the problem, its scope and focus
Determine the needs
Analyze the data, operations, components
Synthesize alternative systems
Evaluate and make decisions
Iterate these steps until satisfied
Implement the selected system
Monitor its operation
Stages in Systems Analysis








(1) Analyze Feasibility
(2) Specify Requirements
(3) Detailed Design
(4) Develop Software
(5) Develop Procedures
(6) Functional Test
(7) Implement and Install
(8) Monitor & Maintain
(1) Analyze Feasibility





Estimate development costs
Check reasonableness of estimates
Prepare summary budget plan
Estimate current and future costs
Prepare cost/effectiveness evaluation
(2) Specify Requirements






Determine detailed requirements
Analyze contexts
Determine hardware & software needs
Compare alternative systems
Prepare performance specs
Assure concurrence of policy makers
(3) Detailed Design




Determine specific equipment
Determine details of activity
Determine details of response times
Determine details of operating environment
(4) Develop Software
(5) Develop Procedures
(6) Functional Test
 Produce software specifications
 Review and evaluate available software
 Analyze make-or-buy
 Develop Procedures
 Functional Test
(7) Install & Implement
(8) Monitor & Maintain







Install Hardware
Install Software
Prepare Documentation
Train Staff
Convert Data Files
Convert Operations
Orient Users
 Monitor Operations
 Maintain Hardware, Software, Procedures
Module 4. Objectives & Requirements
Definition of Objectives










 MANAGEMENT OBJECTIVES
Strategic and Contextual Objectives
Tactical Objectives
Operational Objectives
 TECHNICAL OBJECTIVES
Functional Requirements
Performance Requirements
Cost & Budget Requirements
 POLITICAL OBJECTIVES
Administrative Responsibilities
Professional Concerns
Capital Commitments
Personal Perspectives & Goals
Determination of Requirements




Performance Expectations
Boundary Conditions
Functional Requirements
Political Factors
Performance Expectations
Level of Performance
Resource Implications
High Performance
Resource Exploitation
Frugal
Resource Creation
Subsistence
Resource Preservation
Boundary Conditions
Issue
Boundary Conditions
Funding
Available Resources
Staffing
Maintain, Reduce, Reallocate?
Equipment
A Means or an Objective?
Alternatives
Prescribed or Proscribed?
Functional Requirements
Context
Requirement
Operating Procedure
Formalize
Reporting
Identify Formats
ad hoc Procedures
Establish Means
ad hoc Requirement
Isolated Event?
Political Factors
Context
Political Issue
Capital Commitments
Reluctant to Change
Administrative
Responsibilities
Protect Authority
Professional Perspectives
Maintain Commitments
Personal Objectives
Hidden Agendas
Contexts for Determining Requirements
 Past Experience
 Present Operations
 Future Operations
Sources for Data on Past Operations
Specifics
Examples and components
Internal, Informal
Memos, ad hoc reports,personal
databases
Internal, Formal
Reports, database files, procedures
manuals, documentation,
organization charts
External, Formal
Publications, national databases
External, Informal Exchanges with colleagues
Present Operations
Specifics
Examples and components
Walk-Throughs
Observe forms and documents,
procedures, individual persons
Statistics
Transactions, files, reports
Survey Instruments
Questionnaires, Interviews,
Surveys
Use Logs
Monitoring online operations,
recording transactions
Close observation, Experiments
Time & Motion Study
Future Operations
Specifics
Examples and components
Critical Incident
Technique
Specific need, antecedent context,
means used, outcome
Delphi Technique
Discussion, Questionnaires,
Statistics, commentary, Iteration
Scenarios
Teams: Identify Needs,Postulate
System, Describe Events, Assess
Project Statistics
Time Horizon, Alternative Bases for
Projecting
Module 5. Methods for Analysis
Alternative Approaches
 Evolution from Current Operations
 Maintains consistency in operations
 Builds upon data from actual experience
 Tends to perpetuate existing assumptions and
deficiencies
 Determination of Objectives in terms of User Needs
 Aims to avoid pre-existing assumptions
 Builds upon studies of users and their needs
 Is difficult to identify what are “real” objectives
 Revolution to a Brave New World
 Looks to an ideal system
 Builds upon models and hypothetical data
 Tends to create its own assumptions and deficiencies
Alternative Approaches
There are two dramatically different approaches to determination of the
requirements for an information system and, as a consequence, to the entire
concept of system analysis: the evolutionary approach and the revolutionary
one.
The former starts from the existing operation, determines what it does and
how it does it, then uses the resulting picture as the basis for identifying
requirements, extrapolating from current needs, usually as represented by
workloads.
The latter tries to create a more conceptual picture of an ideal or total set of
requirements, determined not by examination of any current operation or the
needs it serves but by an examination of users themselves, focusing on the
functions they perform and determining requirements from them.
Between them lies an approach that mixes the two extremes, by starting from
the Evolutionary approach but placing special emphasis on needs of users.
The Evolutionary Approach
Underlying the evolutionary approach are several rationales. First, whatever
the new system may be, there must be a process of transition from the
existing system; therefore, at least the implementation stage of the systems
analysis process must be designed around that necessity. Second, the existing
system presumably reflects a pragmatically determined set of requirements,
with which users are familiar and with which they expect to be served;
determination of requirements must, at some stage, recognize and deal with
those expectations. Third, like it or not, the existing system is the only source
for real data about actual experience in meeting requirements; those data are
crucial if any new design is to have a basis in facts rather than mere
conjectures or speculations. Finally, users are difficult to examine,
remarkably variable in their behaviors, so any attempt to investigate their
"true needs" is fraught with difficulty and likely to be idiosyncratic; in
contrast, an existing operation is comparatively easy to examine, and the
results are likely to be much more robust.
The Revolutionary Approach
Underlying the revolutionary approach are two fundamental rationales.
One rationale is the perception that any existing system pre-determines
what needs it will serve by the very nature of what it provides; therefore,
if there is to be any possibility of recognizing unmet needs, one cannot
start by accepting the existing set. The second rationale is embodied in the
"total systems concept" which argues that a new system should be
conceived and implemented as an integrated whole rather than as a set of
relatively isolated sub-systems; only by looking at requirements external
to the means for implementation can such integration be achieved. In a
very real sense, the second reflects the addition of a hermeneutic element
to the process of systems analysis.
My Choice of Approach
These are not necessarily exclusive alternatives. In fact, in each
approach there will be elements of analysis that are best handled by
the other. But each systems analyst does adopt one or the other as the
basis for working, and I must record that in my own case it is the
evolutionary approach combined with emphasis on needs of users.
Among my reasons for choosing the evolutionary approach is my
experience with the importance of political factors in the entire
process. The facts are that information systems, the way in which they
are implemented and operate, affect people – the people that work in
them, the people they serve, the people that provide the resources
needed. Those political factors need to be understood and, like it or
not, are largely determined by the current situation and the reasons
for wanting changes from it. In fact, my experience as a consultant
universally has been that the need for analysis arises not from the
technical decisions, though they may be seen as providing the
answers, but from the political ones. Therefore, as we later examine
the determination of scope and of requirements, I will place some
emphasis on the political factors.
Approach Adopted in this Course
The approach adopted and presented in this course
emphasizes Evolutionary development from current
operations. It does so for several reasons:
 The most reliable data are from current and past
operations.
 Whatever the ultimate system may turn out to be,
there will need to be transition to it from current
operations, and the evolutionary approach, makes
that transition most effectively.
 Other approaches create their own assumptions and
deficiencies which will produce their own problems.
Turning first to the Conceptual Approach:
The Role of Methods
 The following discussion will present a set of
methods to support the process of systems
analysis, design, and evaluation.
 They also assist in communication among the
members of the systems team and with others,
outside the team, such as management.
 It is important to note that these are tools, so
they should be used as tools and not as not
straight-jackets.
Dimensions of Analysis
 Underlying all of the methods are four dimensions:

Data
• Entities & Relationships
• Records & Fields

Functions
• Processes
• Decisions

Components
• People
• Equipment

Time
• Sequence
• Events
The Role of Structure
 In each dimension (Data, Function, Component, and
Time), there are structures that provide the basis for
defining entities within the dimension and relating the
entities within that dimension to each other. The first
task in analysis is to identify those structures.
 Among the dimensions, there are relationships among
entities from two or more of them. The second task in
analysis is to identify inter-dimensional relationships.
The Types of Methods
 The methods are means for describing either the
structures within each dimension or relationships
among dimensions.
 Some of the methods are graphical, presenting the
description in the form of charts. Some of them are
algorithmic, providing the basis for creating
programs.
The Foundation for Methods
 Underlying the methods, whether graphical or
algorithmic, is a database, the entries in which are:



a characterization of an entity in one of the dimensions
a relationship among entities within a dimension
A relationship among entities across dimensions
 The entries for a relationship across dimensions take
the following form:
Data
Entity
Function Component Time Parameters
Entity
Entity
Entity
 Maintenance of this data base is a central task in
conduct of a systems analysis project.
Let’s first look at the Data Dimension, since it is the
foundation for everything:
APPROACHES TO DEVELOPMENT OF
DATA STRUCTURES (1)
In discussing approaches for methodologies of analysis, I identified two
contrasting approaches to the process: the conceptual approach, focused on
the ideal requirements, and the pragmatic approach, starting from the
current operation. As I have indicated, one must in fact encompass both
approaches within one's own procedures, so the issue is not which of them
one uses but with which one starts. I have found the pragmatic approach to
be the most effective starting point for me, but it does have the disadvantage
that it is conservative and biased toward definitions of requirements that
reflect the current operation rather than an ideal one.
APPROACHES TO DEVELOPMENT OF
DATA STRUCTURES (2)
These two approaches can be exemplified by the analysis of data structures.
The conceptual approach starts with the identification of "entities",
representing external objects relevant to the system (such as persons, places,
things, organizations, activities, etc.), moves to the characterization of them
by data elements, and in successive stages analyzes those data elements into
increasing depths of detail; the final result is the identification of "values"
that can appear in the data elements at the lowest level of detail. In later
stages of analysis and, later, of design, the entities and their data elements
become the potential bases for file structures and then may become related
to each other, using specific data elements (serving as identifiers) as the
means for establishing the relationships.
APPROACHES TO DEVELOPMENT OF
DATA STRUCTURES (3)
In contrast, the pragmatic approach starts with existing records, forms,
files, reports, and related data structures. The data elements that make up
the "formats" of those data structures serve then as means for identifying
the entities and their component data elements to be encompassed by the
system. The initial relationships among entities are evidently those embodied
in the existing files, records, forms, reports, etc. Of course, that initial
definition of relationships does not preclude one from establishing others or
from restructuring the initial ones, but it does tend to bias one's thinking
along the lines of current operations.
Data Structures
 Data Dictionary
 Meaning of Data Element
 Composition of Complex Data Element
 Acceptable Values for Data Element
 Alternative Values for Data Element
 Entity and related Properties
 Key Field
 Other Required Fields
 Optional Fields
 Iteration of Fields (zero or more)
 Objects: Types and Sub-Types of Entities
 Shared Properties
 Distinct Properties
A data dictionary is a centralized depository of data about data as a means
for dealing with databases systems of increasing size and complexity. Such
systems can have dozens of programs, hundreds of thousands of lines of code,
hundreds of data field names in dozens of types of records, many relations
and reports, dozens of professional programmers maintaining the system,
and hundreds of users. A data dictionary is a necessity to maintain control, to
assure uniformity in development, to communicate with users.
Historically, this functional need was represented by forms control. Each
form, record, and report would be identified and given a form control
number. A forms control record would show the fields incorporated in it,
identify who was responsible for generating it and transmitting it. The
resulting file was a the counterpart of the modern data dictionary.
Maintenance of a data dictionary requires the following elements:
Means for defining entries
Means for adding, modifying, and deleting entries
Means for validating entries
Means for inter-relating entries
Data Structures – Examples

Data element: Name
 Alternatives: Corporate, Individual
 Structure: (Name), ((Title), First, (Middle), Last),
 Value: (Alpha-Numeric), (Alphabetic)
 Data element: Customer ID
 Value: (Numeric)
 Data Element: Address
 Structure: (Street, City, State, Mail Code, Country)
 Alternatives: (Home Address), (Business Address)
 Data Element: Customer Record
 Key Field: Customer ID
 Required Fields: Name, Address
 Optional Fields: Alternative Address(es)
Relationships
 A Relationship is an operational connection among two
or more Objects
 For example, a Purchase is a Relationship among the
following Objects:
 Customer ( there may be one or more)
 Item Purchased (there may be one or more)
 Sales Representative
 Order form
 A Form (such as an Order Form) embodies a
Relationship and contains Fields identifying the
Objects (as shown above)
Normalization in Relational Databases
 Problems can arise with multiple occurrences of a given
Object in a Relationship:


There can be redundancy, with values appearing multiple time
can consuming storage space.
There can be inconsistencies because of errors in entry of
multiple values.
 To avoid those problems, a Relational Database defines
canonical forms for each Entity and Object which have
the following properties:


There is no redundancy, so a given field and its value for a
given record (except for IDs) appears only once in the file.
All references to an entity are by means solely of its ID field.
Illustration of Normalization (1)
Let's illustrate the process of normalization by considering the following entity
types as related to an Order Form. First, an order form typically includes of a
"header" containing information about the supplier (name, address, perhaps
discount rate, etc.) and about the overall order (date, "deliver to", "bill to", order
number, etc.). Second, an order usually consists of a series of "line items", each
relating to a particular thing being ordered (quantity, name, identifier, unit price,
applied discount, extended amount). Just from the structure of the order form
itself, we can establish two entities: the order (represented by the header) and the
line item (represented by each of the line items in the order form). But beyond
them, there are at least two other entities implicitly represented: the supplier and
the purchased thing (for a book, for example, that would be a title).
We must now determine, for each of these entities, the minimally necessary data
elements for identification and description:
Header: Header ID#, Date, Supplier ID#, ...
Line Item: Header ID#, Line Item ID#, Thing ID#, Quantity, ...
Supplier: Supplier ID#, Name, Address, Discount, ...
Thing: Thing ID#, Name, Price, ...
Illustration of Normalization (2)
In each case, there may be additional data, not included in the entity record but
calculated from a combination of data from the several entities (such as the
extended amount for each line item and the total of them for the header).
Furthermore, the ellipses ("...") reflect the fact that there may be essential data
elements not evident a priori but that will arise from the operational needs; there
may be data elements needed for error control even though redundant (such as a
count of the number of line items and an entry for the total of the extended
amounts, both included within the header).
It is important to note that the record for each entity type (and therefore for each
entity within it) contains an ID#. This is a unique identifier, used to relate entity
types with other entity types, as is illustrated in the line item entity record (in
which Header ID# and Thing ID# provide the links to those entity records).
In the case of the entity type called "Thing" above, the data elements necessary for
description are likely to be far more extensive than the simple example shown. In
the case of books, in fact, necessary data elements are represented by the MARC
format, with recognition that some (such as publisher fields and sub-fields) may be
replaced by links to other entities (the Publisher entity type, for example).
Warnier-Orr Diagrams
The Warnier-Orr technique uses graphical displays that combine brackets,
circular arrows, vertical arrows, numbers (N), and plus signs (+) to portray
activities or data elements and the relationships among them.
The Warnier-Orr technique as applied to description of data elements
starts with the system outputs, including reports, forms, and files, perhaps
using means similar to the Worksheets 2 & 3 (to be presented later). Each
of them is decomposed into data elements.
Hierarchies are identified (for example, as involved in sub-fields of a
MARC record) and schematically shown by brackets that enclose data
elements supporting or involved in the label to the left of the bracket.
Options for data elements, sequences of them, or repetition of them are
then shown by the appropriate symbol.
 The following slides have been copied from
http://www.kenorrinst.com/wo1.htm
Hierarchy
Hierarchy for Data Structure
Hierarchy for Processing Structure
Hierarchy is equivalent to
“Consists of” or “Is composed of”
Sequence
Sequence example
Repetition
Repetition example (1)
Repetition example (2)
Repetition example (3)
Alternation shown by
Alternation Example
Concurrency example
Recursion (i.e., Repetition)
Let’s now turn to the Functional Dimension:
The Functional Dimension





Data Input and Output Processes
Data Storage and Retrieval Processes
Computational Processes
Decision Processes
Communication Processes




Dataflow Diagrams
Process Flow Diagrams (e.g., Flow Charts)
State Transition Diagrams
Program Languages
Data Flow Diagrams
Data flow diagrams are schematic representations of systems, using symbols to
show the ways in which data flows from one entity or process to another. It does
not show decisions or usage patterns or great detail. However, by use of data flow
diagrams at different hierarchical levels, one can show increasing details.
The following example of a data flow diagram is based on the Stages in Systems
Analysis as discussed earlier. Note that just four symbols are used:
Arrowed Line, to represent data flows within the system
Square Box, to represent data sources,stores, or destinations
Rounded Box with Headers, to represent data processes or transformations
Square Box with Corner Labels, to represent entities outside the focus
Actual procedures, such as those to accomplish a specific task, would be detailed in
a procedure specification. Procedures will present not only data manipulation, but
control, such as deciding which path to take in performing a procedure. Details
that are not shown in a data flow diagram (such as amounts of activity, timing,
frequency, etc.) are shown on supplementary diagrams.
Project
Requestors
Management
Stage 1
Stage 2
Feasibility
Requirements
Stage 3
Systems Development Data Base
Detailed
Design
Stage 8
Stage 7
Stage 6
Stage 5
Stage 4
Monitor &
Maintain
Implement
Install
Functional
Test
Develop
Procedures
Software
Design
Management
Project
Requestors
Vendors
The focus is on Data Flow, not Sequence
 It is important to note that the focus of a Data Flow
Diagram is on the paths of data flow, not on the sequence
with which flow may take place.
 In the Data Flow Diagram of the prior slide, the several
stages are not necessarily executed in the sequence implied
by the stage numbers, since the data does not flow from
stage to stage but instead from each stage to and from the
central database, or to and from the external entities.
 Nothing would prevent the stages from occurring in
parallel. Indeed, in some systems development projects,
that is exactly what happens.
Data Flow Diagram Symbol Conventions
 Various computer software to aid systems analysis
may have slightly different conventions for the
symbols they use in data flow diagrams.
 The following two slides are taken from two
software packages, using different symbols from
the ones of the prior slide.
 The user needs to become comfortable with
whatever may the conventions in the software
being used.
Flow Charting
 Flow charting is a tool used to show the
sequence of steps in a computer program, a
procedure, or a process.
 There are typical conventions for the use of
symbols in a flow chart, as illustrated in the
following slide.
 But, as with other examples of schematics, the
various computer software packages will differ
in the conventions they use. Again, the user
needs to become comfortable with whatever
may the conventions in the software being used.
Co re
C om m e nt
C on ne cto r
O ff-pa g e Co n ne ctor
D isp la y
O utp ut D ocu m en t
O fflin e S to ra ge
G e n eric P roce ss
Term in a l Pro cess
(be gin, e nd )
On line Stora g e
De cision Pro cess
De cisio n P roce ss
Dis ke tte
M a nu al O p e ratio n
In pu t-O utp ut Pro cess
M a gn etic Tap e
M an ua l Inp u t
P re p ara tio n Pro ce ss
M a gn e tic Dru m
Pred e fine d P roce ss
Inte rna l Su b -ro u tine
Pu n che d C ard
Ca rd D eck
Extract Pro cess
C olla te Pro cess
Pu n che d T a p e
M erg e P roce ss
So rt P ro ce ss
Flowcharting of Systems Analysis Stages
 The following flow chart is again based on the
stages identified for the process of Systems
Analysis.
 But this time the focus is on the sequence with
which the stages take place.
 The flow chart is structured into several levels of
detail. First, there is an overview. Second, for
each process in the overview, there is a chart with
greater detail.
Systems Analysis Flow Chart – Overview
Details of Preliminary Stage
Details of Stage 1
Details of Stage 2
Details of Stage 3
Details of Stage 4
Details of Stages 5 & 6
Details of Stages 7 & 8
State Transition Diagrams
 State transition diagrams are probably the most
esoteric of the means for picturing operations in a
system, since they are based on the most theoretical
concepts of what are called “finite state machines.”
 They focus on very specific components of the system –
entities, such as machines but also parts of the symbolic
structure of the system.
 The entity is pictured as receiving events from the
outside world, and each event potentially as causing a
transition of the entity from one state to another.
 State models require identifying each of the possible
state of an entity. Thus, they are ideal for describing
the behavior of a single entity but they are not useful
for describing behavior that involves several entities.
Now, let’s turn to the Components Dimension:
Component Dimension
 Personnel Components
 Equipment Components
 Organization Charts
 Operational Relationships Charts
Administrative Hierarchy – Centralized
Library Management
M anagement Support
Systems
Budget & Accounting
Hardware
Personnel
Server
Development
External
Facilities
Terminals
Training
Software
Cataloging
Circulation
Acquisitions
Library Operations
Central Library
Branch Libraries
Technical Services
Reader Services
Selection
Reference
Acquisition
Circulation
Receiving
ILL
Humanities
Social Sciences
Physical Science
Biological Science
School of Law
Cataloging
School of M edicine
Conservation
School of Engineering
Administrative Hierarchy – De-Centralized
University Administration
Central Automated
Bibliographic System
Humanities Faculty
Physical Sciences Faculty
Engineering Faculty
Library
Library
Library
Technical
Services
Readers
Services
Readers
Services
Technical
Services
Readers
Services
Technical
Services
Social Sciences Faculty
Biological Sciences Faculty
Law Faculty
Library
Library
Library
Readers
Services
Technical
Services
Readers
Services
Technical
Services
Readers
Services
Technical
Services
Medicine Faculty
Library
Readers
Services
Technical
Services
Finally, turning to the inter-relationships among
Dimensions:
Inter-relationships among Dimensions






Data
– Component
Function
– Component
Function
– Data
Data
– Time
Component – Time
Function – Time
Responsibility Matrix
Responsibility Matrix
Application Matrix
Dataflow Diagram
Gantt Chart
Flow Chart
Component-Function Responsibility Matrix
 The “Component-Function” responsibility matrix
provides means for supplementing the administrative
hierarchy among component by description of the
operational relationships among them.
 It provides means for identifying the workloads for
each component as the relate to functions entailed in
the execution of major tasks within the library.
 The following examples illustrate the elements in the
responsibility matrix.
Component-Function Responsibility Matrix
Examples
 The following two examples (one for ILL processing and the other
for Collection Development) show a sequence of functions for the
respective tasks and components responsible for each.
 The first column identifies the sequence of processes for the
function. The third column identifies, by classification code, the
position of the component in the administrative hierarchy. The
fifth column identifies, again by classification code, the position of
the software component in the software system.
 The codes in the third and fifth columns can be used to sequence
the matrix so as to bring together all of the functions, in whatever
task, for which a given component is responsible. In this way, the
responsibility matrix provides means for determining workloads
on each component.
Functional Relationships among Components
Example of ILL-related Functions
ILL Borrowing
1
2
3
4
5
6
7
8
9
10
11
12
Personnel Component
Receive Request
Check OPAC
Check Bibliographic
Request via OCLC
Select Source
Establish Record
Receive Material
ILL Manage
Circulate to User
Return Material
Account for Transaction
Reconcile Accounts
11
11
11
11
11
14
23
14
12
12
14
1
Reference
Reference
Reference
Reference
Reference
ILL Management
Receiving
ILL Management
Circulation
Circulation
ILL Management
Budget & Accounting
Software Component
12
13
13
13
23
23
23
21
21
1
1
OPAC Module
OCLC Module
OCLC Module
OCLC Module
ILL Module
ILL Module
ILL Module
Circulation Module
Circulation Module
Accounting Module
Accounting Module
Functional Relationships among Components
Example of Collection Development Functions
Collection Development Personnel Component
1
2
3
4
4
4
5
6
6
7
8
9
9
10
11
Collection Policy
Collection Priorities
Budget Allocation
Recommendation
Recommendation
Recommentation
Selection
Ordering
Ordering
Receiving
Processing
Paying
Paying
Cataloging
Shelving
0
0
1
11
30
21
21
22
22
23
23
22
22
24
12
Library Management
Library Management
Budget & Accounting
Reference
Branch Libraries
Selection
Selection
Acquisitions
Acquisitions
Receiving
Receiving
Acquisitions
Acquisitions
Cataloging
Circulation
Software Component
1
21
21
21
21
21
1
21
12
21
1
22
12
Accounting Module
Acquisitions Module
Acquisitions Module
Acquisitions Module
Acquisitions Module
Acquisitions Module
Accounting Module
Acquisitions Module
Circulation Module
Acquisitions Module
Accounting Module
Cataloging Module
Circulation Module
Gantt Chart
 A Gantt chart shows the sequence of a set of functions
or activities (called a “work breakdown schedule”)
much as does a flow chart, but in addition it shows the
duration of each activity and the inter-dependencies of
activities. One can therefore see when, in time, things
will occur and can determine which activities may
causes delays.
 In addition, a Gantt chart will frequently show the
assignments of activities to components and the
resources implies by those assignments. One can
therefore see where there are too few or too many
resources and where resources may need to be allocated
in order to deal with potential delays by shortening the
duration of an activity.
Gantt Chart Illustration (1)
 The following three slides present an
illustrative Gantt Chart which is based on the
stages involved in systems development.



The first slide presents the preliminary stage and
then Stages 1 and 2.
The second slide presents Stages 3 and 4.
The third slide presents Stages 5 and, more briefly,
Stages 6, 7, and 8.
 These slides were produced using the software
package “Project Manager Pro”.
Gantt Chart Illustration (2)
 The following three slides present much the same
schedule, but this time using the software package
“Time Line”.
 There are several reasons for presenting this package:



It includes capabilities for showing PERT charts
It includes capabilities for assigning resources
It includes capabilities for dealing with calendars
 Unfortunately, it is DOS-based software rather than
Windows-based. Even more unfortunately, it is no
longer produced so it is not readily available.
 Despite those difficulties, it still works well and serves
an an illustration of its capabilities.
 Note that I have left the schedules for tasks under
Stages 3 thru 8 undefined, so we can use them as
exercises.
PERT Chart Capabilities
 The original (i.e., in 1900) Gantt chart, useful
though it was, lacked several important
features, including dealing with dependencies
among tasks.
 During the 1960s, a variety of extensions of the
Gantt chart were created, among them PERT
(“Program Evaluation & Review Technique”),
as illustrated in the following three slides.
Staff Resources implied by Schedule
 A primary value of a Gantt chart is that it provides
a basis for determining the staffing requirements
per task and per time period.
 The following two slides present a distribution of
staff over tasks during a ten month period in the
implementation of a new system. They are based
on an actual project in a large academic library.
 The tasks include those in database conversion, in
training, and in technical work on the software, as
well as in current operational responsibilities.
MACRO-SCHEDULE: WORKLOAD DISTRIBUTIONS OF SYSTEM STAFF TO ACTIVITIES FOR AUTOMATION PROJECT
Entries are Person-Days per Week
Staff are A# = System Staff and L# = Librarian Staff
STAFF DEC
JAN
FEB
MAR
APR
ACTIVITIES
A# L# D1 D2 D3 D4 J1 J2 J3 J4 F1 F2 F3 F4 M1 M2 M3 M4 A1 A2 A3 A4
DATABASE ACTIVITIES
OCLC Retrocon Assess
3
3
3
3
3
3
System Convert Asssess
7 7
7
7
Transfer to new System
1
2
Transfer OCLC to new system
1
2
Transfer system to lbys
1
2
TRAINING ACTIVITIES
New Software Mgt Course 5
1
New Equipment Mgt Course5
1
New System Lbn Course 2 12
54 28
54 28 54
New System Lbn course
6
TECHNICAL ACTIVITIES
New system Tables
2
5
14
14
New system Language Translation
2
5
6
6 6
Non-bilio file convert
1
3 6
12
Sys Oper Procedures
2
Lby Oper Procedures
12
OTHER ACTIVITIES
Current Ops Responsibility 5 12
28 25
24
18
Holidays & Vacations
5 12 72
85 85 85 85 85
34
TOTALS
5
3
3
3
7
7
24
24
24
21 21 54 21
14 14
6 6
14
6 6
6
17 13 22
7
12 85 85 85 88 85 88 85 88 85 85 85 85 85 85 85
3
3
24
21 54 21 21 54
30
6
6
14 14
6 6 6
6
8 8 8
8 17
17
3
11
17
85 85 85 55 85
MACRO-SCHEDULE: WORKLOAD DISTRIBUTIONS OF SYSTEM STAFF TO ACTIVITIES FOR AUTOMATION PROJECT
Entries are Person-Days per Week
Staff are A# = System Staff and L# = Librarian Staff
STAFF MAY
JUN
JUL
AUG
SEP
ACTIVITIES
A# L# M1 M2 M3 M4 J1 J2 J3 J4 J1 J2 J3 J4 A1 A2 A3 A4 S1 S2 S3 S4
DATABASE ACTIVITIES
OCLC Retrocon Assess
3
System Convert Asssess
7
Transfer to new System
1
2
Transfer OCLC to new system
1
2
Transfer system to lbys
1
2
TRAINING ACTIVITIES
New Sys Mgt Course
5
1
Ne Equipment Mgt Course 5
1
New System Lbn Course 2
12
New System Lbn course
6
TECHNICAL ACTIVITIES
New system Tables
2
5
New system Language Translation
2
5
Non-bilio file convert
1
3
Sys Oper Procedures
2
Lby Oper Procedures
12
OTHER ACTIVITIES
Current Ops Responsibility 5
12
Holidays & Vacations
5
12
TOTALS
5
12
12
12
9 21 54
54 42 54 21 21
30
30
30
6
30
7
6
6
14
14 14 14 14
6 6 6 6 6 6 6 6
6 6
6 6
12
9 12 12 12 12 12 12 12 12
46
30
6
30
30
6
2 53 17 47 55 85 49
78 55 85 55 85
1
12 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85
85 85 85 85 85
34
13 11 7 40
30
34
Turning now to the Pragmatic Approach:
Worksheets for Data Gathering
Three worksheets will be presented as means for recording
data needed for the processes in systems analysis.
 (1) Worksheet 1 provides means for recording data
about the administrative structure
 (2) Worksheet 2 provides means for recording data
about files. They would include collections of material
(each type of collection being a separate file) as well as
administrative and operational data files. The relevant
data include identification of the types of records that
are stored in each file together with numbers of those
records that are stored and are acquired.
 (3) Worksheet 3 provides means for recording data
about records that are stored in files. The relevant data
include identifying the fields that are included in the
records together with the size and frequency of
occurrence of each field.
Worksheet 1: Administrative Description
Administrative Unit
Building Location
Net Sq. Ft.
Purpose:
Special Responsibilities:
Supervisor (Name & Title)
Reports to (Name & Title)
Related Administrative Duties:
Special Administrative Duties:
Community Served:
Units of Work:
Remarks:
Personnel FTE
Cler Stu Total
Function
Prof
Date
Analyst
Costs
Direct Burden
Source
Dly
Workload
Mnly Yrly
Unit Costs
Workload/Costs
Page
Worksheet 2: File Description
File Name
Storage Medium
File Number
File Purpose:
Who Needs Access:
File Location:
Sequenced by:
Label:
How Current
Retention Period
Remarks
Seq
Date
Record
Name
Analyst
Chars/Record
Avg
Peak
Source
Records per File
Avg
Peak
Transaction Volume
Avg
Peak
Page
Worksheet 3: Record Description
Record Name
Record Location
Record No.
Other Names Used:
Related Record Numbers:
How Prepared:
Operations Involved In:
Remarks
No.
Fields
Name
Date
Analyst
Chars/Field
Avg
Peak
Source
Frequency
Per Rec
Per File
Nature of Data
A/N
Source
Page
Module 6. The Library Planning Model
The Matrices for Services & Materials
 LPM is based on eight matrices, four of clients and
services for them and four of materials and technical
processes for them. In each case, the first matrix
contains data for determining workloads involved; the
second contains data for the extent to which workloads
use specific services or processes; the third contains
workload factors as means for estimating required staff
and costs; the fourth contains factors for estimating
the need for facilities.
Populations Served
Materials Acquired
Estimation of Required Staffing
 Based on the data entered into these
matrices, LPM can then estimate the
staffing required to handle the associated
workloads and compare it with data
about the actual or planned staffing.
Served
Selection of Populations
“Results Menu”
(1)
(2)
Estimation of Facilities
 LPM includes means to estimate the facilities
needed to meet the needs of users.
 LPM includes means to estimate the facilities
needed to meet the needs for storage of
materials.
 Since data are reported in many different ways,
LPM provides means to convert from one
means of measurement to another.
Estimation of Facilities
 LPM includes means for estimating the
requirements for facilities to meet the needs of
users and to store collections.
Representative Space Conversion Parameters
Microform Drawers per Cabinet
Square feet per microfilm cabinet
16 mm reels per Drawer
16mm reels per Square Foot
16mm reels per Linear Foot
35 mm reels per Drawer
35mm reels per Square Foot
35mm per Linear Foot
Microfiche, Items/Drawer
Microfiche, Square feet/Drawer
Archives, linear feet/square foot
AV & Electronic, Items per Linear Foot
AV & Electronic, Items per Square Foot
Bound Materials per Linear Foot
Bound Materials per Square Foot
17
11
135
209
20
80
124
10
2,500
1
3
15
30
10
15
Module 7. Requests for Proposal
Request for Proposal
(Sections 1 through 7)







Section 1.
Section 2.
Section 3.
Section 4.
Section 5.
Section 6.
Section 7.
Introduction and Summary
Instructions to Proposers
Evaluation Of Proposals
General Requirements
Installation & Conversion
Documentation, Training, & Help
Maintenance
Request for Proposal
(Sections 8 through 11, Appendices 1 through 3)




Section 8. Benchmark & Acceptance Testing
Section 9. Specifications For Required Modules
Section 10. Desired Optional Modules
Section 11. Specifications For Hardware
 Appendix 1. The Institution
 Appendix 2. Computing & Telecommunications
 Appendix 3. Requirements For External Interfaces
Section 2. Instructions to Proposers
 Summary of Proposed Solution
 Status of Development & Implementation
 The Substantive Proposal Sub-Section
 Software for Essential Modules
 Software for Desired Modules
 Hardware
 The System Support Sub- Section
 The Proposer Qualifications Sub- Section
 The Cost & Contract Sub- Section
Section 3. Evaluation Of Proposals






Hardware & Software Performance
Capability to Deliver Support Services
Time Schedule
Contractual Provisions
Cost
Other Criteria
 Evaluation Process
Section 4. General Requirements





System Structure
Control of Access
Workloads & Response Times
Languages of Operation
Systems Requirements
 System Availability & Reliability
 Operation of Terminals
 Software & Hardware Enhancement
 Rights to Use of Software
Section 5. Installation & Conversion
 Installation
 Conversion & Migration of Data
 Conversion of Procedures & Operations
Section 6. Documentation,
Training, Help
 Documentation
 Training of Institution Staff
 Help Support
 Education of Users & Assistance to Users
Section 7. Maintenance
 Staff Policies of the Proposer
 Hardware Maintenance
 Software Maintenance
Section 9. Specifications for
Required Modules (1)
 Library System Management




System Records
Report Control Records
Access Control Records
Tables of Definition Records
 Acquisitions



Acquisition Records
Vendor Records
Fund Account Records
 Serials






Serials Subscription Records
Serials Holdings Records
Materials Management
Receiving & Processing
Inventory Control
Binding
 Conservation & Preservation
Section 9. Specifications for
Required Modules (2)

Cataloging

Bibliographic Records

Authority Records

Cataloging Records




Opac Services
Circulation

Transaction Record

Patron Record

Reserve Book Record

Accounting Record
Reference Support
ILL


Transaction Records
Accounting Records


Multi-media Management

Title Record

Equipment Record

Rooms & Facilities
Network Access

CD-ROM Access

Campus Databases

Internet

Interfaces to External
Environments
Section 10. Desired Optional Modules
 E-mail
 Publishing
 Article Record
 Journal Record
 Subscription Record
 Selective Dissemination of Information
 Tables of Contents Access
 Source Record
 Patron Record
Section 11. Specifications for
Hardware




Current Equipment
Central & Faculty Library Servers
Database Storage
Terminals
Appendices
 The appendices provide data about the
institution, its current information hardware
and software, and the needs of the environment
external to the institution itself.
Module 8. Measurement of Performance
Needs in Proposal Evaluation
 Procedure for Carrying Out Assessment

It is important that there be a well-defined procedure for assessment
and that it involve as participants that will represent the persons who
will be involved in or affected by the system. That procedure should
be clearly identified.
 Requirement for Objectivity and Justifiability

For both legal and ethical reasons, it is important that the
procedure and assessments be objective and that the basis for
the assessments be documents and justifiable
 Flexibility in Representing Actual Needs by
Specifications

The actual needs may or may not be well represented by the
specifications embodied in the RFP. Therefore, they should not
be used as a straight-jacket but as a set of guidelines.
Procedure for Assessment
 The procedure for assessment could include any or all of the
following steps:





A set of Functional Evaluation Teams, each focused on a specific
aspect of the RFP, will evaluate the functionality, quality, suitability,
and adaptability.
A separate Cost Evaluation Team will assess the costs of the proposed
systems and the corporate qualifications of the proposers.
Each team will make independent rank order assessments and
recommendations to the Executive Review Committee which will
then weigh and compare them to arrive at it final rank order
evaluations and decisions.
In is possible that, based on the assessments by the Evaluation Teams,
a list of as many as three proposals may be established as the basis
for more detailed discussions and demonstrations of the proposed
systems at mutually agreed upon sites. In that case, the decision by
the Executive Review Committee will then follow the conclusion of
those discussions and demonstrations.
Following that selection, negotiations would then be started with the
selected proposer in order to arrive at a mutually agreeable contract.
Criteria for Assessment
 The criteria used in assessment should be identified.
 The primary criteria should include all of the following:




hardware & software performance
capability of the vendor to deliver & to provide support services
contractual provisions
cost
 Other criteria might include




quality of the proposed training program
ability to adapt to future changes in hardware and software
ability of the system to serve additional future requirements
such other factors as may be deemed relevant
Sources of Data for Assessment
 The primary source of data to be used in assessment
should the proposal itself.
 Beyond it, though, other sources might include:



other documentation from the proposer
data from other users of the system
records of prior performance by the proposer
Issues in Assessment

BALANCING COSTS WITH EFFECTIVENESS
Difference Measures – the Problems
Ratio Measures – the Traps

THE MEASUREMENT OF EFFECTIVENESS
Multiple Functional Requirements
Weighting their Relative Importance
Qualitative and Quantitative




THE MEASUREMENT OF COST
Full-Cost or Marginal Cost
Full-Cost or Direct Cost
Cost/Effectiveness Measures of
Information System Performance
System Evaluation
S = (Information)/(Response Time) = N/T
(Cost)
C
Sub-System Evaluation
S = (System Cost) – (Sub-System Cost) = N/T * (C – CS)
(System Cost)
CS
C
MEANS TO INCORPORATE
QUALITATIVE ISSUES (1)
To illustrate one means to represent a qualitative issue, consider comparing levels
of quality in cataloging. One catalog record may be more detailed than another,
more accurate than another, more conforming to standards, or more specific to a
given library's needs than another.
How does one represent such differences in quality of cataloging? One means to
do so is to represent the alternatives by the functions required to produce them,
measuring them by the costs for each.
To illustrate, one expects that the quality of the original cataloging will be better
than that of copy cataloging (though not necessarily so, since there may be issues
of conformity with standards). Let’s see what that looks like:
MEANS TO INCORPORATE
QUALITATIVE ISSUES (2)
The following matrix represents costs by the labor costs per hour for two levels of
staff by (C1 and C2) and the workload factors are the default values used in The
Library Planning Model:
Clerical
Professional
Copy Cataloging
C1*(0.18*2000/1000)
C2*(0.02*2000/1000)
Original Cataloging
C1*(0.05*2000/1000)
C2*(1.15*2000/1000)
Let’s take C1 as $8/hour and C2 at $16 per hour, and consider three different
mixes of the two levels of quality with copy cataloging at 100%, 90%, and 70%:
Clerical
3.60 0.10
Professional 0.04 33.00
Mix 1 Mix 2 Mix 3
10
9
7
0
1
3
N/T = 10
10
Cost 1 Cost 2
36.00 32.50
0.40 33.36
10 C = 36.40
CT/N = 3.64
64.86
6.49
Cost 3
25.50
99.28
124.78
12.48
How to Measure Information?
 Definition of Information as Processing of Data
 Levels of Data Processing
 Measures Appropriate to each Level
Module 9. Issues in Determining Costs
Alternative Means for Cost Assessment
LEVEL
MEANS FOR
EVALUATION
Minimum
Time & Motion Study
RULE OF THUMB
RATIOS
(Basic)/(Minimum) = 1.50
Basic
Direct Labor
(Full Salary)/(Basic) = 1.50
Full Salary
Salary & Benefits
(Burdened)/(Full Salary) = 1.50
Burdened
All Costs
Workload Factors for Estimating Direct FTE
FTE per 1000 Transactions
FUNCTION
Acquisition
Cataloging
Circulation
Serials
Physical Handling
ILL Borrow
ILL Lending
Reference
TOTAL Direct
FTE
PROCESS
Select
Order
Invoice
Original
Copy
Maintain
Charge
Shelving
Receiving
Records
Receiving
Labeling
BibID
Handling
Records
BibID
Handling
Records
WORKLOAD FACTORS
Prof
Cler
Stud
0.25
0.20
0.20
1.60
0.20
0.25
0.03
0.03
0.02
0.10
0.10
0.02
0.06
0.20
0.10
0.20
0.05
0.10
0.20
0.25
0.25
Workload Factors
Relation between FTE per 1000 Transactions and
Minutes per Transaction
 Assume that a typical working year is 42 weeks (which
allows 10 weeks for holidays, vacation, and sick leave).
 Note that are almost exactly 100,000 minutes in a
typical working year: (42*40*60 = 100,800).
 Hence, one FTE can be taken as 100,000 minutes.
 Given that, 1.00 FTE per 1000 Transactions implies
100 minutes per transaction and similarly for other
numbers of FTE (e.g., 0.25 FTE per 1000 transactions
implies 25 minutes per transaction, etc.).
Means for Determining Workload Factors
 Time and motion studies. These tend to focus on
limited functions (such as keyboarding, sorting, and
filing – as will be illustrated).
 Ex post facto accounting. This uses data from current
operations, including workloads and staffing, and then
analyzes those data, fitting them into a standard
accounting structure. Data from a large number of
institutions provides means for calibrating, validating,
and generalizing.
 Analogies. These use data from a variety of contexts,
including many different types of institutions and
operations, and makes comparisons among them to
identify common or similar functions and, by analogy,
arriving as generalized estimates of rates if
performance.
Sorting Time
per item in a batch as a function of (Batch Size)
log(Seconds per Item) = 0.25 + 0.25*log(Batch Size)
log(Seconds per Item)
2.50
2.00
1.50
1.00
0.50
0.00
0
1
2
3
4
5
log(Batch Size)
High 10 Percentile
Average Range
Low 10 Percentile
6
7
Filing Time
per item in a batch as a function of (File Size)/(Batch Size)
log(Seconds per Item) = 0.75 + 0.25*log(FileSize/BatchSize)
log(Seconds per Item in Batch)
3.00
2.50
2.00
1.50
1.00
0.50
0.00
0
1
2
3
4
5
log(FileSize/BatchSize)
High 10 Percentile
Average Range
Low 10 Percentile
6
7
Illustrative Application of Workload Factors
FUNCTION
Acquisition
Cataloging
Circulation
Serials
Physical
Handling
ILL Borrow
ILL Lending
Reference
TOTAL
Direct FTE
PROCESS
Select
Order
Invoice
Original
Copy
Maintain
Charge
Shelving
Receiving
Records
Receiving
Labeling
BibID
Handling
Records
BibID
Handling
Records
Workload
30 K titles
20K orders
20 K orders
4 K titles
26 K titles
30 K titles
846 K circs
2537K shelves
30 K titles
30 K titles
91 K items
91 K items
12 K borrows
12 K borrows
12 K borrows
29 K lends
29 K lends
29 K lends
137 K hours
Full Time Equivalent
Prof
Cler
Stud
7.57
4.04
4.04
6.15
5.29
7.57
25.37 25.37
50.73
3.03
3.03
1.82
5.45
2.42
1.21
2.42
1.46
2.91
5.82
34.22
68.44
51.82
97.25
85.07
(FTE)
Total
7.57
4.04
4.04
8.15
5.29
7.57
50.73
50.73
3.03
3.03
1.82
5.45
2.42
1.21
2.42
1.46
2.91
5.82
234.1
3
Alternatives for Overhead Allocation
Category
Percent
of Total
Non-Profit
Allocation
Total Salaries
1.00T
1.00T
Direct Salaries
0.67T
Indirect Salaries
Salary Benefits
Overhead Expenses
0.33T
0.14T
0.20T
Industry
Allocation
0.67T = 1.00D
0.14T
0.20T
0.67T = 1.00D
Sub-Total
1.34T
1.34T = 2.00D
G&A
Total
0.13T
1.47T
0.13T = 0.20D
1.47T = 2.20D
Module 10. Details of RFP
Section 2. Instructions to Proposers (1)
 GENERAL
 submit proposal by deadline
 identify as "Proposal in Response to RFP"
 clearly identify the name of the proposer
 stipulate proposal is good for 120 days
 PROPOSAL STRUCTURE
 submit proposal in five specified sections
 submit each section in three copies
 submit in three-ring binder
Section 2. Instructions to Proposers (2)
 PROPOSED SOLUTION
 respond directly to Sections 4, 9, & 10
 present single best answer
 avoid presenting multiple strategies
 fully respond to requirements, specifications
 state extent to which each requirement is met
 explain means for meeting each requirement
 provide explanation for any that cannot be met
 identify exceptions and related requirements
 Substantive Proposal in specified sequence
Section 2. Instructions to Proposers (3)
 THE SUBSTANTIVE PROPOSAL:
 GENERAL REQUIREMENTS
• address general requirements
 SOFTWARE FOR ESSENTIAL MODULES
• fully implemented turnkey software system
• address specifications from Section 9
 SOFTWARE FOR DESIRED MODULES
• identify desired modules that are included
• or specific statement that none is included
Section 2. Instructions to Proposers (4)
 THE SUBSTANTIVE PROPOSAL
 HARDWARE
• integrated turnkey including hardware, etc.
• identify hardware required to implement system
• include all equipment necessary for operation
• identify differences for essential & optional
• alternative hardware platforms
• detailed list of the site requirements
• detailed list of electrical, etc. requirements
• identify special conditions or restrictions
• deliver supplies for initial operation
• list supplies necessary for initial operation
• estimate supplies for continued operation
• provide specifications for all supplies
Section 2. Instructions to Proposers (5)
 THE SUBSTANTIVE PROPOSAL
 STATUS OF DEVELOPMENT &
IMPLEMENTATION
• declare the current status of development
• declare status for any alternatives presented
• identify sites for OPTIONAL functions
• identify sites in test and evaluation
• identify dates for completion of testing
• identify dates for completion of development
• identified status of planning
Section 2. Instructions to Proposers (6)

THE SUBSTANTIVE PROPOSAL
 THE SYSTEM SUPPORT SECTION
• INSTALLATION & CONVERSION, DATA &
PROCEDURES
– respond to requirements in Section 5
• DOCUMENTATION, TRAINING & HELP
– respond to requirements in Section 6
• MAINTENANCE & SUPPORT
– respond to requirements in Section 7
Section 2. Instructions to Proposers (7)
 THE SUBSTANTIVE PROPOSAL
 THE PROPOSER QUALIFICATIONS SECTION
– data to assess financial and staffing
• CORPORATE DESCRIPTION
– brief description of the company and parent
– history, description of organization, staffing
– identify persons responsible for
implementation
– provide brief resumes for each
• FINANCIAL CONDITION
– provide a copy of financial statement
– audit certified by an officer of the company
– name, etc. for banking organization
– disclose judgments, litigation, other problems
– warrant that no judgment or litigation exists
– identify any termination of contract
– warrant if there have been no terminations
Section 2. Instructions to Proposers (8)
 THE SUBSTANTIVE PROPOSAL
 THE PROPOSER QUALIFICATIONS SECTION
• EXPERIENCE
– identify customers
– academic library of the size of the
institutional
– provide data about the size of operation
• PROPOSED MANAGEMENT PLAN
– describe management to provide the system
– time schedule of activities and events
– provide checkpoints for institutional to review
progress
– identify activities required of institutional
Section 2. Instructions to Proposers (9)
 THE SUBSTANTIVE PROPOSAL
 THE COST & CONTRACT SECTION
• COST PROPOSAL
– itemized list of initial & continuing costs
– costs as unit prices extended to required units
– identify costs for the essential modules
– identify costs for desired optional modules
– identify costs for with
– identify restrictions on use of the software
• CONTRACT PROPOSAL
– identify restrictions on use of software
compatible with requirements in
institutional usestate owner or licensed to
provide software
– provide licenses to run third party software
– provide access to source code
Section 3. Evaluation Of Proposals (1)
 CAPABILITY TO DELIVER SUPPORT SERVICES
 previous customers as references
 evidence of financial viability and continuity
 evidence of the means for continuing support
 identify means to provide onsite support
 identify means to recover from failures
 identify means to provide hardware maintenance
 identify hours of support for software
Section 3. Evaluation Of Proposals (2)
 HARDWARE & SOFTWARE PERFORMANCE
 identify extent of meeting each requirements
 as necessary identify effects of exceptions
 extent of flexibility provided and means for it
 compatibility with US -MARC
 extent to which multiple languages accommodated
 means to provide interfaces to other networks
 conformance with accepted standards
 limitations on ability to provide reports
 stipulate if there are no limitations
 identify statistics that are most valuable
Section 3. Evaluation Of Proposals (3)




TIME SCHEDULE
CONTRACTUAL PROVISIONS
COST
OTHER CRITERIA
 training, documentation, means to instruct
 means for training other institutional library staff
 ability to adapt to change in technologies
 ability to serve added requirements
 EVALUATION PROCESS
Section 4. General Requirements (1)
 SYSTEM STRUCTURE
 integrated database covering all collections
 viewing whole collection or faculty library
 switch between one view and the other
 modular, with easy modification or replacement
 CONTROL OF ACCESS
 control of access by different categories
 basis for access, centrally and at libraries
 SUPPORT TO LIBRARY & SYSTEM
MANAGEMENT
 information for library and system management
 information for management of operations
 management of the system
 detection and prevention of system failures
 support library and system management centrally
 library & system management at faculty library
Section 4. General Requirements (2)
 WORKLOADS & RESPONSE TIMES
 response times rapid enough
 replacement values with explanation of reasons
 extent response time is affected by bandwidth
 message "Transaction in Process" updated 2 secs
 indicate likely remaining time for processing
 LANGUAGES OF OPERATION
 able fully to operate in multiple languages
 operation in Local Language, Other Language, and
English
 means for switching languages
 additional Roman alphabet languages
\
Section 4. General Requirements (3)
 SYSTEMS REQUIREMENTS
 GENERAL
• software is vendor independent
• software can be moved to various computers
• can be output & transport data to other systems
• means to export and import US -MARC data
• means to export and import data in MICROISIS
• means to export and import data in UNIMARC
• means for import of data for other files
• fully UNIX compatible
• consistent with a client/server operation
Section 4. General Requirements (4)
 SYSTEMS REQUIREMENTS
 SYSTEM AVAILABILITY & RELIABILITY
• regularly scheduled downtime
• hours for scheduled downtime
• percent time fully functional
• function in a partially connected network
• procedures for backup of data files
• procedures for fail-safe operation
• procedures for operations when system is down
• schedule of backup to minimize effects
 OPERATION OF TERMINALS
• text-based & graphical user interface operation
• support both PC and Mac terminals
• support menu driven & command driven
operation
Section 4. General Requirements (5)
 SYSTEMS REQUIREMENTS
 SOFTWARE & HARDWARE ENHANCEMENT
• means for software and hardware enhancement
• training support for new or enhanced features
• requirements to effectively run improvements
 RIGHTS TO USE OF SOFTWARE
• guarantee right to use of all software
Section 5. Installation & Conversion (1)
 INSTALLATION
 detailed plan for installation of the system
 events: hardware, software, conversion
 percentage of records to be converted
 plan for phasing into full-scale operation
 institutional proposed phasing acceptable to the
proposer
 institutional proposed plans for conversion and
migration
 number of records for effective operation
 alternatives for conversion and of data
 current system in parallel with the new system
 schedule for transition from one to the other
Section 5. Installation & Conversion (2)
 CONVERSION & MIGRATION OF DATA
 derive database from existing system & US-MARC
records
 derive authority files from existing system
 scenario of conversion process
 views of the most for accomplishing the
 CONVERSION OF PROCEDURES & OPERATIONS
 manuals for procedures in use of the system
 experience in prior conversions
Section 6. Documentation, Training, Help (1)
 DOCUMENTATION
 documentation sufficiently complete
 deliver full documentation for the hardware
 provided in English and in Local Language
 documentation provided by the training time
 instructions for solving standard problems
 indexes in both Local Language and English
 operator manuals for hardware and software
 provided in both Local Language and English
 updates during the contract to reflect changes
 online help for elements of documentation
 online help in Local Language, English, and Other
Language
Section 6. Documentation, Training, Help (2)
 TRAINING OF institutional STAFF
 provide a program of training for institutional staff
 training services for various levels of staff
 content of training programs
 means used for instruction
 the schedule and length for training sessions
 levels of staff and management each training
 resources and facilities for training sessions
 language of instruction
 means for trainees fluent only in Local Language
 copies of training manuals included
 qualifications that institutional staff to train others
 means they will use for instruction
 means for training in an operating environment
Section 6. Documentation, Training, Help (3)
 HELP SUPPORT
 context sensitive help screens for users
 tutorial support for untrained users
 specific help if the system sees a problem
 hypertext capability
 help screens to untrained user needs
 available in Local Language, English, Other Language
 EDUCATION OF USERS, ASSISTANCE TO USERS
 advice concerning best means for user education
 sample materials as an appendix to the proposal
Section 7. Maintenance (1)
 STAFF POLICIES OF THE PROPOSER
 policies affecting the staff commit of time
 HARDWARE MAINTENANCE
 procedures for obtaining support for hardware
 appropriate inventory of parts to be stocked
 test equipment to be included on site
 procedures for obtaining support at the site
 maximum time delay for field support staff
 costs for alternative delay times
 support at sites other than central processing
 procedures for preventive maintenance
Section 7. Maintenance (2)
 SOFTWARE MAINTENANCE
 maintenance of software
 responsibility for software maintenance
 procedures for upgrading software
 costs associated with upgrading
 procedures for obtaining support for software
Section 8. Benchmark & Acceptance Testing
 Procedure for acceptance testing
Section 9. Specifications for
Required Modules (1)
 LIBRARY AND SYSTEM MANAGEMENT
 functions for management the system
 reporting on system operation
 reporting for management of the library system
 means to specify scope of statistics
 means to specify content of reports
 exchange data with all other modules
 alternatives by which statistics are acquired
 reports both online, printed or to files
 output in formats for application software
 levels of access to functions and data
 means for specifying formats of displays
Section 9. Specifications for
Required Modules (2)
 SYSTEM HARDWARE & SOFTWARE RECORDS
 record for each item of hardware & software
 fields as specified for the record
 REPORT CONTROL RECORDS
 record for each report both standard and ad hoc
 for each new report, for search and access
 fields for content, calcs, format, sequence
 fields for use, frequency, and distribution
 fields identifying the responsible person, etc.
Section 9. Specifications for
Required Modules (3)
 ACCESS CONTROL RECORDS
 record for each aspect of control of access
 basis for access control & for effecting it
 links to records related to individuals
 TABLES OF DEFINITION RECORDS
 record for each definition of format of display
 fields for the role, current spec, history
Section 9. Specifications for
Required Modules (4)
 ACQUISITIONS
 selection, ordering, receiving, and accounting
 reporting support management of acquisitions
 consistent data centrally, at faculty libraries
 output in institutional specified formats
 types of orders used in research libraries
 various conditions of purchase
 faculty production, student dissertations
 identify duplicates in the collection
 identify institutional for exchange in acquisition
Section 9. Specifications for
Required Modules (5)
 ACQUISITIONS
 support currency conversion
 exchange data with all other modules
 available to the OPAC for display to users
 make OPAC records available to acquisitions
 means for user to place a request for selection
 provide data to the serials module
 means for linking to bibliographic utilities
 means for linking to book jobbers and databases
 means to create acquisition record in selection
Section 9. Specifications for
Required Modules (6)
 ACQUISITIONS
 means for checking for potential duplicates
 defaulting in repetitive fields
 consistency criteria for appropriate fields
 accounting functions for receipt or claiming
 change acquisitions record & OPAC at receipt
 means for processing partial shipments
 growth workloads over the five-year period
Section 9. Specifications for
Required Modules (7)
 ACQUISITION RECORDS
 acquisition record for each item selected
 fields as specified
 searchable and accessible as specified
 VENDOR RECORDS
 record for each vendor
 easy means for processing vendor records
 fields as specified
 accessible as specified
 management of correspondence with vendors
 information about policies of vendors
Section 9. Specifications for
Required Modules (8)
 FUND ACCOUNT RECORDS
 fund accounting tracking by institutional criteria
 track amounts budgeted, encumbered, expended
 post fund accounts as items are processed
 adjust values based on authorized changes
 provide full audit trails for all transactions
 means for institutional to specify format of reports
 be a record for each fund account
 means for processing of fund account records
 fields as specified
Section 9. Specifications for
Required Modules (9)
 SERIALS
 means of acquiring and controlling series
 exchange data with all other modules
 support all functions in serials
 interface with all other essential modules
 receive data from acquisitions at ordering
 send data to OPAC to display of holdings
 accommodate active and total titles
Section 9. Specifications for
Required Modules (10)
 SERIALS SUBSCRIPTION RECORDS
 record for serials with fields as needed
 SERIALS HOLDINGS RECORDS
 US-MARC compatible
 ANSI standard for Serials Holdings Statements

fields as specified
Section 9. Specifications for
Required Modules (11)
 MATERIALS MANAGEMENT
 manage the physical items in the collection
 deal with both separate items and serials
 exchange data with all other essential modules
 interface with OPAC for change in status
 interface with circulation missing items
Section 9. Specifications for
Required Modules (12)
 RECEIVING & PROCESSING
 control receiving of materials
 support inspection of received items
 provide means for entry of invoice data
 identify the person for data entry
 deal with non-existing records
 support the physical processing of materials
Section 9. Specifications for
Required Modules (13)
 INVENTORY CONTROL
 means for taking inventory of library materials
 means for obtaining the identification data
 record the date of most recent inventory
 determining mis-shelved and missing items
 recognize the status of items
 update appropriate record to reflect status
Section 9. Specifications for
Required Modules (14)
 BINDING
 support binding
 identify materials ready for binding
 specify details of binding
 CONSERVATION & PRESERVATION
 identify items needing preservation work
 monitor the status of items in preservation
Section 9. Specifications for
Required Modules (15)
 CATALOGING
 GENERAL
• create and maintain bibliographic records
• online processing
• exchange data with all other modules
• be available to the OPAC for display to users
• use records in the OPAC to creat new records
• linking to bibliographic utilities
• accommodate multiple items with the same record
• identify faculty library where item is located
• one bibliographic record for each title
• linkage from other records to the master
Section 9. Specifications for
Required Modules (16)
 CATALOGING
 GENERAL
• display records related to a current one
• provide validity and consistency checks
• detecting duplicates & potential errors
• spelling checks in Local Language, English, Other
Language
• over-riding mandatory field requirements
• view authority files and tables in a "window"
• maintain an "audit trail" of changes in records
 BIBLIOGRAPHIC RECORDS
• fully compatible with US-MARC
Section 9. Specifications for
Required Modules (17)
 CATALOGING
 AUTHORITY RECORDS
• interactive authority control
• authority control for author publisher names
• fully compatible with US-MARC authority records
• provide different classification schedules
• handle non-standard classifications
 CATALOGING TRANSACTION RECORDS
• record for each cataloging transaction
• specified fields
Section 9. Specifications for
Required Modules (18)
 OPAC SERVICES
 OPAC to access and use bibliographic records
 exchange data with all other modules
 available from public and staff terminals
 accessible through dial-up
 be available for access through the Internet
 conform to ANSI/NISO Z39.50-1994 standards
switched from full to faculty library catalog
 user searching by natural language or mnemonics
 screen design and messages
Section 9. Specifications for
Required Modules (19)
 OPAC SERVICES
 single term search of specified fields
 specifying an exact match of a field
 boolean combinations of terms
 use of comparators
 use of adjacency, proximity, sequence of terms
 right truncation of any single word
 to provide means for left truncation
 truncation for more than one word in a query
 display formats be definable
Section 9. Specifications for
Required Modules (20)
 OPAC SERVICES
 showing the number of hits
 one-line entries, multiple entries per screen
 full bibliographic records in full screens
 highlight search terms within each entry
 specify sort sequence of multi-entry displays
 display entry content in user format or US-MARC
 restrict display of US-MARC to specific users
 select an entry for full-screen display
Section 9. Specifications for
Required Modules (21)
 OPAC SERVICES
 "browsing" in the bibliographic file on fields
 "browsing" in authority files
 specify retrieved records to be downloaded
 means for the user to request the download
 specify the format of downloaded records
 set limits on the number of records downloaded
 easy to modify a search query
 means to narrow a search query by date
 means to narrow search query by faculty library
 narrow any search by the type of material
 store user queries and results
Section 9. Specifications for
Required Modules (22)
 CIRCULATION
• provide all functions involved in circulation
• alert operator re any potential problems
• interface with all other essential modules
• communicate with OPAC for display of status
• display of materials charged out to the user
• providing statistics and reports on operation
• statistics on frequency of use of items
• means to identify physical state of materials
• means for flagging materials as "missing"
• provide for charge-out, renewal, and discharge
• accommodate different loan periods
• provide means for calculating due-dates
Section 9. Specifications for
Required Modules (23)
 CIRCULATION
• permit circulation of materials in process
• identifying a borrower lacking a borrower card
• means for ready creation of a borrower record
• charge-out of multiple items to a borrower
• prevent charging prior patron for a current one
• provide for holds and recalls
• inform a hold or recall of return of materials
• cancel holds and recalls for a deleted borrower
• provide means to control renewal of an overdue
• have means to block circulation of materials
• provide means to over-ride restrictions
• provide for determining overdue status of items
Section 9. Specifications for
Required Modules (24)
 CIRCULATION
• provide for overdue notices and accounting
• update accounting records for deleted borrowers
• means for patrons to self-charge-out materials
• means for patrons to renew charge-outs
• functions related to reserve book operations
• means for online change of parameters
• means for back-up operation during down-times
Section 9. Specifications for
Required Modules (25)


TRANSACTION RECORD
• a record for each circulation transaction
• specified fields
• searchable by all fields
• a notes field for data about the transaction
PATRON RECORD
• be a record for each patron and library
• specified fields
• searchable by specified fields
• means for updating from other files
• a notes field for data about the patron
Section 9. Specifications for
Required Modules (26)



RESERVE BOOK RECORD
• record for each item in reserve book operation
• specified fields
• field for use in the reserve book operation
RESERVE BOOK CLASS RECORD
• a record for each class with reserve books
• specified fields
ACCOUNTING RECORD
• a record of accounting data for fines and fees
• specified fields
Section 9. Specifications for
Required Modules (27)
 REFERENCE SUPPORT
 tools to support reference in use of the system
 interface with all other modules
 readily exchange data with each of them
Section 9. Specifications for
Required Modules (28)
 ILL: BORROWING & LENDING OR DOCUMENT
DELIVERY
• support borrowing, lending, & document delivery
• online ILL management of ILL requests
• interface with the circulation and reference
• provide reports as necessary for ILL management
• access by specified fields
• provide for online editing of requests
• interface with of electronic mail
• provide for copyright accounting as necessary
Section 9. Specifications for
Required Modules (29)
 ILL: BORROWING & LENDING OR DOCUMENT
DELIVERY
 TRANSACTION RECORDS
• a record for each ILL transaction
• specified fields
 ACCOUNTING RECORDS
• a record for each partner institution
• data for statistics and financial accounting
• capability for requester records as needed
Section 9. Specifications for
Required Modules (30)
 AUDIO-VISUAL MEDIA & MULTI-MEDIA
MANAGEMENT
• means to manage collections of AV & multi-media
• means to manage equipment and rooms
• capability for booking materials and equipment
• graphic displays for visual review of bookings
• interface with all other essential modules
• not duplicate data available in other modules
Section 9. Specifications for
Required Modules (31)



AV TITLE RECORD
• a record for each AV or multi-media title
• managed within the bibliographic database
• specified fields
• fields for description of physical condition
AV EQUIPMENT RECORD
• specified fields
• a record for each item of equipment
AV ROOMS & FACILITIES
• a record for each room or facility
• specified fields
• field for booking status of room or facility
Section 9. Specifications for
Required Modules (32)
 NETWORK ACCESS
• provide means for access to networks
• tightly integrated with the OPAC module
• ability to move seamlessly among networks
• repeat a request on a succession of databases
 CD-ROM ACCESS
• be available from the OPAC main menu
 CAMPUS DATABASES
• easy to add databases identified as available
 INTERNET
• be directly available from the network module
Section 9. Specifications for
Required Modules (32)
 NETWORK ACCESS
 INTERFACES TO EXTERNAL ENVIRONMENTS
• interface with the Institutional Computing System
• interface with libraries of the State
• access from other libraries within the State
• access to the Internet
• accommodate "World-Wide Web"
THE END