BOOKING SYSTEM SPECIFICATIONS
General Qualifications
The system supplier shall provide a list of references of systems of similar scope to the proposed system and must be
able to demonstrate a minimum of 10 years of development experience.



Right to choose system in department’s best interest.
Only fully networked versions of the will be considered.
Only multi-user versions will be considered.
Structure/Development/Platform
Front-end: The proposed system must be designed with a Microsoft 32-bit development environment such as
Microsoft Visual Basic or Microsoft Visual C++ and run on a Windows 95 or later or Windows NT 3.51 or later
platform. The proposed solution must be non-proprietary and shall be constrained to industry standard off-the-shelf
components. The system must be completely open and accessible.
Back-end database: Fully ODBC capable, relational database system such as Microsoft’s SQL Server 6.5 and later.
The applications must adhere to a true client/server model. Data integrity must be maintained through the use of
formal referential integrity constraints including cascading updates and deletes.
Compatibility


Year 2000 (Y2K) compatible
National Incident Based Reporting System (NIBRS) compliant
Description
“Booking” allows a user to store a person’s demographic, physical, and other information and images into a
temporary storage system. Once positively identified, this temporary record is posted to a known persons database.
Persons already in the known persons database will have their records updated with the most recent information and
images. Because the known persons database is fully normalized, the existing information is not replaced but
complemented. The following categories of information must be normalized; Addresses, Aliases, Dates of Birth,
Employers, Guardians, Personal Identifiers, License Numbers, Social Security Number, Photographs, and Telephone
Numbers.
The booking system must provide the ability to capture and store digital photographs during the booking process.
These images should be stored as Binary Large Objects (BLOBs) in the database itself, not as separate files. The
number of images allowed should be limited only by the available disk space and should not be a limit imposed by
the software provided. The user must be able to associate the following information to each image: 1) the aspect;
e.g. frontal, profile, etc., 2) a memo, 3) a NIBRS personal descriptor, 4) the eye wear status; e.g. Glasses, No
Glasses, 5) the age of the person at the time the photo was taken.
The system must accommodate adults and juveniles and support their segregation throughout the booking process
and their subsequent record storage. The system must also allow authorized users to treat select juveniles as adults.
Required Fields
Booking ID
Date of Booking
Time of Booking
State BCI ID
CCR Number
Last Name
First Name
Middle Name1
Alias
Date of Birth
Social Security Number
Driver’s Licence Number
Driver’s Licence State
Address Prefix
Address Street
Address Suffix
City
State
Zip Code
Country
Home Telephone Number
Alternate Telephone Number
Gender
Height
Weight
Build
Complexion
Eye Color
Hair Color
Hair Style
Facial Hair
Personal Identifiers 2 3
Occupation
Employer
Employer Address Lines (2)
Employer City
Employer State
Employer Zip Code
Employer Telephone
Employer Fax Number
Supervisor
City of Birth
State of Birth
Country of Birth
Marital Status
Citizenship
Residence Status
Ethnicity
Race
Guardian 1 Last Name
Guardian 1 First Name
Guardian 1 Middle Initial
Guardian 1 Role
Guardian 2 Last Name
Guardian 2 First Name
Guardian 2 Middle Initial
Guardian 2 Role
Guardian Address Lines (2)
Guardian City
1
NOT just middle initial.
Normalized. Must support unlimited number of associated records.
3
Consists of NIBRS code, category, and location.
2
Guardian State
Guardian Zip Code
Guardian Telephone
Guardian Alternate Number
School Attending
Photographs 1
(Associated fields: Aspect, Memo, Personal Descriptor, Eye Wear, Age at time of photo)
Relational Design – all tables must be fully normalized and must use non-proprietary data types.
Normalized known persons database tables:
Known Persons
Addresses
Aliases
Dates of Birth
Employers
Guardians
Personal Identifiers
License Numbers
Social Security Number
Telephone Numbers
Images
System Tables
These tables will provide the user with choices from a drop-down list (e.g. a combo box) and should be populated
with NIBRS defined data elements, the administrator, however, must be able to add to, modify, or delete elements of
the lists at any time.
Address Suffixes
Citizenships
Complexions
Ethnicity
Eye Colors
Eye Wear
Facial Hair Types
Genders
Guardian Roles
Hair Colors
Hair Styles
Height Feet
Height Inches
Marital Statuses
Personal Descriptors (NIBRS)
Photo Aspects
Races
Residency
Resident Status
States and their abbreviations
Zip Codes and their associated cities and states
User Interface
A “Lookup Screen”, which displays all records that have not been posted, displaying at a minimum, the Primary
Key, Last Name, First Name, Middle Name, Date of Birth, Arrest Date, and Cell Number fields must be provided.
This list should be sorted alphabetically by last name then first name. The person’s BCI number must be assignable
from this screen to facilitate batch processing of positively identified individuals. Choosing an individual from the
list must bring the user directly to that person’s record.
The system must allow a user to navigate the current set of records either sequentially, using next and previous
record navigation buttons, via the previously described “Lookup Screen”, or via a “Find Record” dialogue which
allows boolean comparisons on a field by field basis. A bookmark feature that allows the user to return to a record
that was previously flagged is also desired.
In an effort to make data entry as efficient and easy as possible, the user interface should adhere to the Common
User Interface (CUA) standards and should provide the user with contemporary features such as; a tabbed dialogue,
pop-up calendars, fully populated NIBRS compliant drop-down lists of choices for data entry, city/state lookup upon
zip code entry, and immediate data validation feedback. In addition, the user should be able to navigate and enter
data via the with or without the mouse. Data integrity should be assured by limiting data entry to list choices, where
appropriate, and by the use of referential integrity techniques.
Image Acquisition Module
The image acquisition module captures, manipulates, and stores images associated with the current person’s booking
record. The image acquisition system must have the ability to interface with any TWAIN compatible source, such as
scanners, digital cameras, video capture boards, etc. and then to capture the image via the device’s TWAIN
dialogue. The system must allow the user to choose from a list of available TWAIN sources at any time. Image
import via the windows clipboard or an external file must also be supported. Disk file types supported must be Joint
Photographic Experts Group (JPEG), Windows Bitmap (BMP), and Tagged Image File Format (TIFF), at a
minimum. Once the image has been imported into the image work area, image processing functions such as
Histogram Equalization (Intensity stretching), Enlarge/Reduce, etc. are highly desirable. Any editing of the image
should be reversible via an undo feature. An automated “Portrait Crop” feature must be included in this module. A
“bounding box” of fixed size and aspect ratio must be available to the user. The user will have to simply position the
box over the portion of the image that is to be stored and the program must crop and size the image automatically.
The image specifications are defined below. The number of images that can be stored with the booking record
should only be a function of available storage space, not a constraint of the program. All images must be normalized
and provide for the following additional fields; Aspect, e.g. frontal, profile, etc., a descriptive memo, a NIBRS
compliant Personal Descriptor, EyeWear type, and Age at time of photo.
The booking system must support image output to the windows clipboard or export to disk file using, at a minimum,
the following file types: Joint Photographic Experts Group (JPEG), Windows Bitmap (BMP), and Tagged Image
File Format (TIFF). An Arrest and a Fingerprint card must also be provided. Posting of the Booking records to the
fully normalized Known Persons system must be on-demand for completed records only.
Image Specifications (Cropped Photos)
Width: 323 pixels
Height: 406 pixels
Color depth: 16 million colors
Average size stored: 11K
Storage format: Joint Photographic Experts Group (JPEG)
Legacy Information
Each vendor must provide information regarding his or her method of legacy data import capability.
Configurability
Configuration system must be password protected.
Administrator must be able to configure:
System database (system and user tables) location.
Default printers for Arrest cards, Fingerprint cards.
Training
Two (2) Days of training shall be provided to up to 3 persons.
Support
The vendor shall provide, at no additional cost, telephone support for a period of one year from acceptance.
Subscription Service
The vendor shall provide, at no additional cost, all software updates to the proposed system for a period of one year
from acceptance.
OTHER ISSUES/CAVEATS
Pricing
Installation included? Per site cost? Additional sites?
Custom programming rates for future projects.
Database
Provided?, what is it?, platform?, cost?, cost to integrate with existing our database?, Open architecture?
Connectivity
True Client/Server model?, Pass-thru queries?, Modular/Integrated?
Method: RDO, DAO, Jet, ODBC API, VB/SQL?
Network
Supported, types, configuration included?, Concurrency?, Record Locking?
Implementation
Project plan? Proposed work schedule indicating work milestones, potential meetings,
project personnel required, field testing, etc.
When would we be fully operational?
What type of error handling does your application have?
Documentation
Topology maps/system architecture diagrams, data dictionaries, etc.?
Compatibility
Is your system compatible with our existing system?
Will we be able to exchange data with our existing system?
Support
What type of support is available? Service contracts? Help desk?
Training availability?