ATTACHMENT H
State of Maryland
DPSCS/ITCD
Maryland Automated Fingerprint Identification System (MAFIS)
Functional and Technical Requirements Document
Final Document
Version 2.0
Prepared by:
Date Prepared: January 23, 2006
Functional Requirements Document (Final)
Version 2.0
Document Revision History
Version No.
Date
Revised By
Summary of Revision
1.0
12-12-05
Bob Bower
Created document template
1.0
12-16-05
William King
Initial write up for FRD document.
1.0
12-20-05
William King
Updates and details from requirements matrix updates.
1.1
01-03-06
William King
Updates based on stakeholder feedback
1.1
01-06-06
William King
Updates for draft #2 requirements categories.
1.1
01-11-06
Bob Bower
Updates based on stakeholder feedback
1.2
01-13-06
Bob Bower
Submitted to State as Version 1.2
2.0
01-23-06
Steve Turner
Submitted to State as Version 2.0
Nortel Government Solutions Incorporated
i
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
Table of Contents
1
GENERAL .......................................................................................................................................... 3
1.1
2
3
Project Description ............................................................................................................. 3
1.1.1
Background ......................................................................................................................... 3
1.1.2
Purpose................................................................................................................................ 5
FUNCTIONAL REQUIREMENTS ................................................................................................. 6
2.1
Data Requirements .............................................................................................................. 6
2.2
Functional and Technical Requirements ............................................................................. 6
2.2.1
General AFIS Requirements ............................................................................................... 6
2.2.2
Tenprint Processing Requirements ................................................................................... 10
2.2.3
Latent Processing Requirements ....................................................................................... 13
2.2.4
Latent Palm Processing Requirements.............................................................................. 16
2.2.5
Transaction Controller Processing Requirements ............................................................. 17
2.2.6
Fingerprint Archive Processing Requirements ................................................................. 19
2.2.7
AFIS Inked Card Conversion Requirements .................................................................... 22
2.2.8
Fast Identification ............................................................................................................. 23
2.2.9
Mugshot System ............................................................................................................... 24
2.2.10
System Management and Reporting ................................................................................ 27
OPERATIONAL REQUIREMENTS ............................................................................................ 34
3.1
Security ............................................................................................................................. 34
3.2
Audit Trail......................................................................................................................... 36
3.3
Networking ....................................................................................................................... 36
3.4
Data Currency ................................................................................................................... 36
3.5
Reliability.......................................................................................................................... 37
3.6
System Availability........................................................................................................... 37
3.7
Fault Tolerance ................................................................................................................. 37
3.8
Disaster Recovery ............................................................................................................. 39
3.9
Performance ...................................................................................................................... 40
3.10
Data Retention .................................................................................................................. 41
3.11
Project Management and Development ............................................................................ 41
4
REQUIREMENTS TRACE ABILITY MATRIX......................................................................... 46
5
Glossary ............................................................................................................................................. 46
Nortel Government Solutions Incorporated
ii
January 23, 2006
Functional Requirements Document (Final)
1
1.1
Version 2.0
GENERAL
Project Description
The scope of the MAFIS replacement will include the replacement of the following components
of the current MAFIS System:

Automated Fingerprint Identification System

Fingerprint Data Router (FDR)

Gateway Service Provider (GSP)

Fingerprint Archive
In addition, the following components will be added to the Maryland AFIS Replacement:

Optional Mugshot System

Fast ID capability (including two pilot locations)

Offsite Fail over systems with replicated data.
Within new technology AFIS systems, in order to provide complete and accurate results, all hard
copy inked tenprint cards will be converted into Maryland National Institute of Standards and
Technology (NIST) electronic tenprint records prior to AFIS processing. This will allow for the
inclusion of all fourteen images into MAFIS, ultimately improving the accuracy of latent
processing. In addition, the cards will be digitized at 1000ppi (as opposed to 500 ppi in the old
MAFIS), thus improving system quality and accuracy.
Card conversion will also be performed to support the new Fingerprint Archive. It is preferred
that all cards for each State Identification Number on record be converted. The State will have
the option to reduce the amount of converted records for the Archive based on cost. The card
conversion process for the Archive system, at a minimum standard will be the front scan
(fingerprint images) of the card at 1000ppi and back scan (demographic information) of each
arrest card at 500ppi.
The MAFIS replacement project will impact other Maryland applications currently in production.
DPSCS wants an independent “Transaction Controller” that will replace the current duties of the
FDR and GSP. This Transaction Controller will have to be designed and developed to be
compatible with internal and external applications. Coupled with the MAFIS and Transaction
Controller, necessary modifications of the surrounding legacy systems to support the modified
workflow will be necessary. Current applications such as IPS/CCH, RAS and ABS will need to
be modified to adhere to the Maryland NIST standards and a more streamlined workflow.
1.1.1
Background
The Maryland DPSCS has the primary responsibility for controlling, supervising, and providing
services for defendants and offenders in our custody. In addition, DPSCS creates statewide
correctional and rehabilitative initiatives, and criminal justice training standards that are the
foundation of Maryland’s crime control efforts. The department also manages statewide criminal
justice information and technology systems. These networks provide criminal justice agencies
and the courts with timely access to complete and accurate information about individuals under
their supervision. An ever-growing demand for civil background checks to protect our State’s
citizens is also supported by DPSCS.
Legislative changes in this area have driven the need for system flexibility.
information regarding DPSCS is available at www.dpscs.state.md.us.
Nortel Government Solutions Incorporated
3
Additional
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
In 1976, the Criminal Justice Information System (CJIS) was created and the CJIS Central
Repository was established effective December 31, 1977, to operate it. CJIS Central Repository
has evolved to be a direct service-provider to both the criminal justice community as well as the
non-criminal justice community. Technological services are provided by the IT units of the
Information Technology and Communications Division (ITCD). Designated by the Federal
Bureau of Investigation (FBI) as Maryland’s official State Identification Bureau, the CJIS Central
Repository receives, maintains, and disseminates Maryland’s criminal history records, which are
fingerprint-supported for positive identification. It receives reports of criminal “events” from the
police, courts, correctional agencies, and other criminal justice entities. These are compiled into
chronological history of an individual’s arrests, convictions, prosecution, etc., to form the “RAP”
(“Report of Arrest and Prosecution”) sheet.
Offender-based records are used by criminal and non-criminal justice agencies (police, sheriffs,
State’s attorneys, courts, correctional agencies, parole and probation, etc.) for investigation,
apprehension, prosecution, corrections, classification, and other criminal justice purposes. CJIS
Central Repository provided over 350,000 criminal history records checks to criminal justice
agencies, as well as, non criminal justice agencies in calendar year 2004, an increase of over 41%
in the past 9 years.
This project supports the following DPSCS goals developed in the Managing for Results (MFR)
process:

Safe Communities: Help to keep Maryland Communities safe by allowing quicker
retrieval and identification of offenders.

Good Management: Ensure that the Department operates efficiently by maintaining
an availability rate of 99.99%.
This project also supports the following overarching State enterprise business goals:

Focus on Customer Service by providing faster and more reliable identification of
offenders, as well as providing timely responses to non criminal justice agencies
mandated by homeland security issues to obtain Criminal History Record
Information (CHRI) for the purpose of risk assessments.

Improve Service Delivery Mechanisms to respond to the needs of a growing,
diverse population. This project will meet this goal by providing a more robust
fingerprint archive retrieval system for supplying information to Maryland’s growing
user population. Improved accuracy and timeliness with new functionality to include
Fast Identification processing.

Balance Freedom of information with privacy and security. The software will be
National Institute of Standards and Technology (NIST) standards compliant and
maintain the integrity of our data.

Improve the quality of information and decision-making. The capability of
capturing palm prints, scars marks and tattoos will improve the capability of a
positive match on an offender.
Nortel Government Solutions Incorporated
4
January 23, 2006
Functional Requirements Document (Final)
1.1.2
Version 2.0
Purpose
The current Automated Fingerprint Identification System will be replaced with a new MAFIS.
The new system will capture, store, index, and perform searches and matches on the fingerprints
of individuals for criminal justice and non-criminal justice purposes. Fingerprint Identification
will be performed on, but not limited to, criminal identification for adults, juveniles, and civil
background checks. The new system will have full disaster recovery capability.
This new system will permit faster identification and, will require less human intervention in the
processing of fingerprints through improved workflow and automated quality control capabilities.
It will also process palm prints and plain impressions or “flat” prints, in addition to the rolled
print capability of the current system.
More specifically, replacing the current MAFIS with the new MAFIS will provide the following
features:

Improved matching accuracy.

Faster identification processing.

Improved automated quality assurance checks that reduce human interaction.

Latent palm print matching.

No single point of failure in support of high availability.

Compliance with the DPSCS Disaster Recovery Plan.

Improved return on investment through reduced vendor dependence.

Provide a statistical reporting system for internal and external decision makers.

System must be capable of performing in a “lights-out” environment when possible
in order to minimize manual/human intervention and associated labor costs.

Flexible configuration that allows for future growth.

As an option, purchase a statewide Photo-Mugshot Photo System that will be
integrated with the MAFIS system.
Replacing the existing MAFIS with the purchase of a Commercial off the Shelf (COTS) package
will allow the State to meet the needs of the Homeland Security and FBI National Fingerprint File
(NFF) initiatives in a more timely fashion and keep MAFIS compliant with State and Federal
Regulations for personal identification through fingerprint technology. The project will
incorporate several technologies to include: distributed computing, TCP/IP communications
protocol, latent palm matching, electronic image capture, and software matching and relational
database software. The new MAFIS will be fully interoperable with other AFIS technology
worldwide and based on Maryland NIST. Any applications or peripheral devices that follow
NIST standards will be able to communicate with the MAFIS replacement system. As an option
to this project, a mug-photo identification system will be incorporated at the state level. A pilot
project will be planned for the use of FAST ID functionality.
This capability will allow departments and agencies to use a single finger scanner to capture flat
impressions and launch an automated search on the MAFIS system, returning responses to the
operator in a timely manner.
Nortel Government Solutions Incorporated
5
January 23, 2006
Functional Requirements Document (Final)
2
Version 2.0
FUNCTIONAL REQUIREMENTS
The functional requirements describe the core functionality of the application. This section
includes the data and functional process requirements.
2.1
Data Requirements
With the exception of the Transaction Controller, the AFIS Replacement System will be
comprised of several software components (AFIS, Archive, Fast ID, and Mugshot Photo systems)
that will be COTS products. The logical data model for these products will be dependent on the
Vendor and will not be a custom data model for Maryland. However, Maryland DPSCS will
require that certain fields be available within the database and that certain indexes are available
for searching and relating records between systems. These specifics will be discussed and
documented throughout the design phase of the project.
In addition to a system’s own unique identification or primary key, each software component at a
minimum needs to relate its records back to the SID, PCN, and/or tracking number for each
record it is processing. There are also inquiry functions that will require other key fields to be
available in all databases. The systems shall provide the ability to request a record through
primary and secondary search elements. The primary search elements include, but are not limited
to SID number, PCN, name, date of arrest, SSN, Originating Agency Case number and/or
Tracking number. Secondary search elements include but are not limited to, race, gender, record
type and transaction type.
2.2
2.2.1
Functional and Technical Requirements
General AFIS Requirements
A.1
The system must support the acquisition and storage of both 500ppi and 1000ppi images
for both tenprint and latent prints, including palmprints. Currently 500ppi Livescans
support electronic submissions. Over time, these will be upgraded to 1000ppi.
A.2
The proposed monitors at all AFIS workstations shall display images in at least 256
shades of gray at 1,000 ppi resolution.
A.3
System components and peripherals shall be the most current generation in commercial
use at the point of customer factory acceptance.
A.4
The hardware for the system shall be compatible with the State’s computing
environment, including databases and operating systems. State approval of all proposed
hardware and system software will be required.
A.5
All system processors shall be open systems compliant and shall maximize use of
commercial off-the-shelf hardware as well as operating system and applications software
packages.
A.6
The proposed servers and workstations must support multiple processors as needed for
purposes of expandability.
Nortel Government Solutions Incorporated
6
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
A.7
The System must use an ODBC or JDBC-compliant relational management database
system, preferably a RDBMS from Oracle, IBM DB2 or Microsoft SQL Server. The
database must be compliant with the State's SAN.
A.8
The system will use the State’s SAN for primary record storage.
A.9
The vendor shall provide design documentation for all system components as built, at the
completion of the design phase.
A.10
The vendor shall provide user manuals for all system components as built at the time of
factory acceptance. All documentation must be approved by the State. Any updates
identified during user acceptance will be incorporated prior to final acceptance.
A.11
The vendor shall provide maintenance, operations manuals, and all software release notes
for all system components as built, at the completion of the factory acceptance testing.
All documentation must be approved by the State. Any updates identified during user
acceptance will be incorporated prior to final acceptance.
A.12
The vendor shall provide time synchronization services for all AFIS subsystems plus the
Transaction Controller, Archive Server, and optional Photo-Mugshot Server using either
the AFIS or the Transaction Controller as the time server.
A.13
Each component within the system must be protected with anti-virus and appropriate
security related software. (State will provide the software and license to support this
requirement.).
A.14
The system shall guarantee delivery of a response within 3 seconds to any transaction that
has been accepted or rejected, unless deleted by a System Administrator.
A.15
The tenprint matching system shall be able to process tenprint images that are rotated as
much as 15 degrees in either direction from vertical alignment. This is a total of 30
degrees of potential rotation.
A.16
The system shall provide a notification to the CJIS supervisor (who will be a system
administrator) for records that are not meeting the Service Level Agreement for
processing time.
A.17
The System shall be designed to store all work-in-progress records if network or system
interruption occurs. Upon system restoration, all queued records will be automatically
forwarded without manual intervention. (This requirement is for system availability only
and does not relate to catastrophic events.)
A.19
The proposed system must already be successfully established and in production in
another location of similar size and complexity.
A.20
The delivered system shall have a useful lifespan of at least ten years from the date of
acceptance by State. Software and Hardware must be maintained at supported levels
throughout the life of the contract. (Cost for this requirement must be incorporated into
the annual maintenance fees and should not be a part of this procurement).
A.21
Vendor must provide a complete and separate test system that will mirror the production
system. This system will be used for training and for testing software updates before
Nortel Government Solutions Incorporated
7
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
implementation on the production system. At no time shall the test system impact the
production environment. (i.e. reboots).
A.22
The system shall support FAST ID capabilities and should provide encrypted data
communications to a browser based user interface for desktop and mobile devices.
A.23
Business workflows shall have the ability to be modified by the State via the Transaction
Controller, without the need for AFIS vendor intervention to the AFIS.
A.24
The systems shall provide responses back to end users via the Transaction Controller to
indicate the need for reprints due to poor quality of images, State identification results,
and FBI responses. These responses must be sent within 3 seconds of quality
verification.
A.25
The Transaction Controller and the AFIS Systems shall never allow duplicate PCN’s. A
high priority error message will be generated and sent back to the submitting agency via
the TC within 3 seconds upon identification of any duplicates.
A.26
The proposed printers shall have the ""(Autoselect) Select from dual-tray printer" (8 x 8
fingerprint card stock and letter size paper) option. Capacities must support a minimum
of 500 sheets of fingerprint card cardstock and 250 sheets of 8.5 X 11 paper.
A.27
The proposed printers shall have the ability to print all FBI fingerprint and palm print
templates, accurately reproducing gridlines and text on blank card stock.
A.28
The proposed printers shall have duplex capability that will not jam with FBI provided
blank card stock. Jams that occur more frequently than one per 2,500 cards will not be
allowed.
A.29
The proposed printers must support at a minimum 100mb Ethernet RJ45, DHCP and/or
fixed IP addresses.
A.30
Printers supplied with the AFIS shall include a self-calibration feature to ensure proper
grayscale and 1 to 1 image size printing per FBI IQS specifications.
A.31
The replacement of all latent and tenprint workstations will include networked printing
ability to vendor provided IQS certified printers.
A.32
Database activity shall be logged so that the State AFIS System Administrator can
remotely monitor the details of record movement, processing and dissemination within
the AFIS from any workstation based on user permissions.
A.33
The system shall provide an audit trail and reporting capability of all database
transactions that include operator input and system batch processes with a date and time
stamp.
A.34
The priority of an individual transaction must be modifiable by AFIS System
Administrators.
A.35
System transaction logs must be easily accessible to a system administrator via standard,
ad hoc, and/or third party tools (Excel or Access) for record review and controlled by
permissions.
Nortel Government Solutions Incorporated
8
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
A.36
On line AFIS transaction logs shall be maintained in primary storage (State SAN) for a
minimum period of 24 months. After 24 months, the log files will be moved to off line,
secondary storage.
A.37
The system shall be designed to support moving all transaction logs to external media for
long-term storage.
A.38
The AFIS system must allow a CJIS supervisor (who will be a system administrator) the
ability to view and print the history of a selected record.
A.39
Each tenprint record or latent record shall be available for update or manual processing at
only one workstation at any time. Attempts to access the record currently held by another
workstation should trigger a “record in use” message at the second workstation.
A.40
The system shall use queues or queue equivalents for temporary storage of records and
images during processing. Transactions shall be queued according to priority and released
for processing automatically.
A.41
The system shall process transactions when they are received, and shall handle each
request on a first-in, first-out basis within each priority level.
A.42
AFIS workstations shall have the ability to run office automation software (MS Office,
Photoshop CS, or other similar software) provided by the State.
A.43
The system shall register each newly received tenprint record by Process Control Number
(PCN). The PCN is a unique twelve-digit alphanumeric identifier used for each record
submission.
A.44
An AFIS operator shall be able to retrieve by SID# the corresponding tenprint record
from the AFIS tenprint database using any AFIS workstation. The operator shall be able
to display the entire record or to select and enlarge and/or print to an IQS network printer
any fingerprint image in the record in order to manually compare the images of interest to
hard copy containing unknown images.
A.45
The AFIS shall provide a full range of editing tools. These tools must include at a
minimum: contrast adjustment, image enlargement, rotation, the ability to view flat
impressions as well as the rolled, the ability to substitute flat impressions for rolled
images in the case of sequence errors or poor quality images, the ability to change the
search fingers and resubmit the record to the matchers, and the ability to edit the
computer-generated minutiae.
A.46
The AFIS system shall support a search priority system with the ability for authorized
users to modify standard priorities based on user permissions.
A.47
The AFIS system shall allow an operator the ability to view the Work in Progress queue
to determine the status of a record based on permissions.
A.48
The system must enable a user to modify the default search space to include or omit
searching of records of a particular image type (tenprint records, palm print records, and
unsolved latent records) for any individual inquiry.
Nortel Government Solutions Incorporated
9
January 23, 2006
Functional Requirements Document (Final)
2.2.2
Version 2.0
A.49
The AFIS must support SMTP/MIME or MQSeries transmission protocols plus NIST
and future XML messaging to/from other systems.
A.50
The vendor shall provide follow on maintenance and support of all AFIS components for
both software and hardware via a separately negotiated maintenance agreement.
A.51
The printers provided to print fingerprint cards will be FBI IQS certified and will print
the first card within two minutes of receiving the card data and will be able to print at
least one fingerprint card per minute immediately following the printing of the first card.
A.52
Each workstation must be able to access on-line help and workstation documentation,
including user manual, technical manual and maintenance manual. Any authorized
system user must be allowed to access the on-line documentation.
A.53
The system shall be delivered with a minimum of 1 Gigabit internal network backbone to
support all system servers provided within this contract.
Tenprint Processing Requirements
T.1
The system shall provide tenprint accuracy and reliability of greater than 99% with at
least 90% of the true candidates in the number 1 position on the candidate list.
T.2
Each tenprint verification workstation shall be provided with a FBI IQS certified flatbed
scanner to support a search and purge tenprint identification process. This process must
not allow permanent record storage of tenprints in the database.
T.3
The vendor shall provide 22 Tenprint workstations. These workstations will support
tenprint processing, quality control, training, and the disaster recovery system.
T.4
The tenprint workstations shall be capable of displaying a list of candidates ranked by
matcher score. Candidates are ranked in order of highest matcher score sequentially to
the lowest matcher score above the threshold. The length of the candidate list will be
determined by a system default setting that can be modified by the system administrator.
Operators may override the default setting on an individual search basis.
T.5
The System shall auto encode fingerprints with the option for minutiae editing by tenprint
quality control operators.
T.6
If the verification results differ from the validation results, the system shall automatically
forward the transaction to a supervisor for final decision.
T.7
If the tenprint search results in candidates above the threshold, they will be queued in
matcher score order (highest to lowest) for verification.
T.8
The system shall perform image quality analysis and sequence check upon receipt of all
tenprint records.
T.10
Tenprint records that go into an error status shall be automatically placed into an error
queue for review by a tenprint processing supervisor or quality control operator.
Nortel Government Solutions Incorporated
10
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
T.11
The system shall allow searching of ten flat images in support of applicant processing.
These records will only be searched and purged immediately upon completion of
identification or non-identification. The ten flat images captured for applicant processing
will not be permanently stored in the AFIS.
T.12
The system must not allow duplicate State Identification Numbers (SID) to be stored in
the database.
T.13
The system shall automatically launch a search of the unsolved latent database for all
tenprint records that are new inserts into the AFIS tenprint database.
T.14
Upon the automated quality check, a flag shall be set for any fingers not meeting quality
thresholds defined by the State or for out of sequence errors. These records shall be
automatically routed to the quality control queue.
T.15
The system shall be capable of storing new tenprint records to its permanent database
within 60 seconds upon receipt of a SID number from the Transaction Controller.
T.16
The system shall store a composite record (14 images) in the search database composed
of the best quality images from all tenprint submissions. Image substitution based on
higher quality will be done by the system without operator intervention unless the record
is of substandard quality.
T.17
The system should provide for multi-finger tenprint searches for greater accuracy. The
State of Maryland requires that at a minimum, the best four of six fingers be searched.
T.19
The system shall perform all searches independent of any demographic filtering.
T.20
The system shall provide the ability to perform both an OPEN (searching against the
whole database) and a CLOSED search (search that attempts to match the search record
against one or more records from the tenprint database specified by a SID# list).
T.21
The system shall be capable of performing a batch TP/TPID search of the permanent
database, for the purpose of identifying duplicate records.
T.22
The system shall provide an automated consolidation process of all human verification
operator identified duplicate records. Consolidation process is initiated by AFIS and
controlled by IPS/CCH.
T.23
The system shall provide the ability to perform expungements of records through an
electronic process initiated from IPS/CCH.
T.24
The system shall automatically use alternate finger matching in the event of missing or
poor quality images.
T.25
When all tenprint candidate list scores are below the tenprint “no-hit” threshold score, a
“no-hit” response shall be provided to the transaction controller.
T.26
The system shall not allow record updates or inserts for transaction type "IDENT",
executed at an AFIS workstation. (IDENT - Identification verification only, search and
purge.)
Nortel Government Solutions Incorporated
11
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
T.27
The AFIS system shall provide information to the Transaction Controller regarding
image quality improvements and permanent scars for National Fingerprint File (NFF)
compliance.
T.29
The AFIS and the Fingerprint Archive systems must both support Wavelet Scalar
Quantization (WSQ) and Joint Photographic Experts Group (JPEG) 2000 image
compression for finger and palm images at settings compliant with the FBI EFTS and
FBI best practices for high resolution images.
T.30
The system shall log records sent to image quality analysis by capture device and capture
device operator in order that the State might use this information to detect malfunctioning
hardware and operator training needs.
T.34
The system shall have the capability to allow the quality control operator to substitute
flats for rolls and/or revise the finger numbers for rolls acquired out of position (swap
boxes).
T.35
The workstation shall provide for a side-by-side display of the search print and the
corresponding match candidate print. The side-by-side split screen shall be capable of
displaying both images at full resolution at 1,000 ppi.
T.36
The system shall allow operators to review tenprint candidate results on a verification
screen by either requesting the next candidate or requesting the results of a specific
candidate. (Must allow both options.)
T.37
The workstation shall have the capability to print a hard copy of the candidate list to
include at a minimum the candidate SID number and matcher score at operator request.
T.38
The tenprint quality control queue shall be accessible from all AFIS workstations based
on operator permissions.
T.39
The workstation shall provide tools for the quality control operator to resolve sequence
errors, improve image quality or to flag the record as “rejected”.
T.40
The workstation shall display all 14 images and allow the operator to compare any of the
search record images against any or all images in the candidate record.
T.41
The system shall enable an operator to forward a transaction to a supervisory technician
or exception handler with a work related note if they are having difficulty verifying the
identification.
T.42
Restricted by user permissions, each workstation will have the ability to review either the
tenprint verification or quality control queues.
T.43
Upon receipt of a SID #, all new tenprint record submissions shall be inserted into the
tenprint database and shall become available for subsequent searches within 15 seconds.
T.44
The system shall allow cancellation of a search transaction from the search queue, prior
to initiated search, or to delete search results awaiting verification by a supervisor or
operator with appropriate permissions. Deletions and cancellations shall cause an
appropriate message to be transmitted to the Transaction Controller so that records in the
TC do not “hang” waiting for AFIS response.
Nortel Government Solutions Incorporated
12
January 23, 2006
Functional Requirements Document (Final)
2.2.3
Version 2.0
T.45
The system shall provide a method for submitting 10 print searches for identification only
(IDENT transaction) from any AFIS workstation with an IQS scanner. These records
will not be retained in AFIS or any other system.
T.46
Tenprint records that undergo QA update processing shall be stored as the corrected
version in the AFIS system.
T.47
The system shall be capable of automatic encoding of minutiae to process all types of
fingerprints and palmprints. A fingerprint operator will have the ability to manually add,
remove, or adjust the minutiae and re-launch a search.
T.48
The system must be able to support pre-defined search priorities, set by the system
administrator, which can be modified by the user at search initiation.
T.49
The system must process multiple tenprint record types that include but are not limited to:
Criminal, Applicant, Juvenile, Sex Offender Registration, and Identification only.
T.50
The tenprint system shall be sized to support 4 million tenprint records.
Latent Processing Requirements
L.1
For not less than 95% of all latent searches where the unknown latent print has at least 10
identifiable minutiae points with no filters added, if a corresponding fingerprint or palm
print image is registered in the system, that matching record must be identified in the
respondent candidate list in one of the top 5 positions, based on the match score.
L.2
For not less than 95% of all latent searches where the unknown latent print and a
corresponding file print have at least 15 minutiae in common with no filters added, the
matching file print record must be identified in the respondent candidate list in one of the
top 3 positions, based on match score.
L.3
For not less than 95% of all latent searches where the unknown latent print and a
corresponding file print have at least 20 minutiae in common with no filters added, the
matching file print record must be identified in the respondent candidate list in the top
position, based on match score.
L.4
The vendor shall provide 26 latent processing workstations to be installed in multiple
remote sites.
L.5
Each Latent Workstation must include FBI IQS Certified flatbed scanner input devices
and the software necessary to scan and submit latent prints at 1000ppi for processing.
L.6
The system shall be capable of providing a list of respondents ranked by a scoring system
in descending order of probability of the correct match for latent searches to the
workstation operator with the option to print hard copy.
L.7
Unsolved latent prints entered by a remote site shall become available for tenprint to
unsolved latent searches within 60 seconds.
L.8
The system shall provide the capability to make an inquiry (search) of the unsolved latent
database, whenever a latent record is added to the unsolved latent database. (Unsolved
latent to unsolved latent database search).
Nortel Government Solutions Incorporated
13
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
L.9
The system must have the capability to search latent fingerprints against both rolled and
flat impressions in the AFIS tenprint database.
L.10
The system must have capability to identify “simultaneous impression” and link multiple
latent as having come from the same person (hand) and rank candidates higher in the
candidate list based on matcher score correspondence from all “simultaneous impression”
images.
L.11
The system should have the capability to perform batch purges on the unsolved latent
database, by date and crime type.
L.12
All latent prints will automatically be searched against the tenprint database and the
unsolved latent database. Latent palms should be automatically searched against the
palmprints database and the unsolved latent palmprints database.
L.13
The system shall provide the capability to automatically search the unsolved latent
database whenever a tenprint record is added to the AFIS database.
L.14
The system shall provide the capability to produce a candidate list to the originating
latent examiner.
L.15
The system shall provide the ability to sort the candidate list by most likely candidate to
least likely candidate based on matcher scores.
L.16
The system must support ULW software on all MAFIS latent workstations with the
ability to electronically transfer “coded” images and minutiae from MAFIS workstation
software into ULW software along with associated Type 2 data.
L.17
The system shall allow the use of third party image editing software (e.g. Photoshop
CS/2) on all latent workstations with electronic import – export of images between latent
workstation and image editing software.
L.18
The system shall allow latent examiners access to the Fingerprint Archive so that they
may easily view, download, and print complete fingerprint and palm print records on
Maryland or FBI card formats. This functionality shall be available at every AFIS latent
workstation.
L.19
The MAFIS system shall have the capability to accept ULW latent search requests and
search all ULW submissions and return candidate lists to the submitting location via both
the State network and the FBI CJIS WAN.
L.20
The latent workstation shall support the import of lifts via multiple media sources. At a
minimum, the system must support CD and USB connectivity. At a minimum, file
formats of TIFF, bmp, JPEG, and NIST must be supported.
L.21
The system shall provide for automated reporting for each latent examiner, to include
new cases, completed cases, and pending verifications.
L.22
System shall have the capability for the State AFIS System Administrator or designated
supervisor based on permissions, to transfer cases from one latent operator’s queue to
another when operators transfer or terminate employment.
Nortel Government Solutions Incorporated
14
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
L.30
The System must have the ability to re-launch a search with varying parameters without
rescanning images, (by recalling the record and modifying descriptive and/or fingerprint
minutiae data).
L.31
The system shall be capable of adding new latent images and changing associated data
within the latent case records.
L.32
The system shall allow cancellation by the operator who launched the search or by the
system administrator, of a search transaction from the search queue, or to delete search
results awaiting verification.
L.33
The system must provide the ability to request an unsolved latent image display by case
number.
L.34
The system shall allow operators to review latent search results on a verification screen
by either requesting “next result” or requesting the results of a specific candidate.
L.35
The full 14 image fingerprint record shall be immediately available to a latent examiner
for all candidate list latents queued for verification with the ability for the latent examiner
to print all 14 images from each candidate at 1:1 size in standard fingerprint card format
using an IQS networked printer.
L.36
The system shall have the capability to allow the operator, upon request, to declare a
primary and/or secondary pattern type for search.
L.37
System shall provide a priority setting system that works to insert higher priority latent
searches in the queues ahead of lower priority latent searches based on permissions.
L.38
The system shall provide for a side-by-side display of the latent print and the
corresponding match candidate print. This side-by-side split screen shall allow display of
1,000 ppi images at full resolution.
L.39
The system must have the ability to continue latent entry if central processing equipment
is temporarily unavailable.
L.40
Based on a latent system's user login, the system must provide the user with the ability to
review any search results related to that user's searches. This function must be available
from any latent workstation.
L.41
The system shall support a default number of candidates to be returned for each inquiry,
and shall enable individual users to increase or decrease the requested candidate list
length for any specific inquiry.
L.42
The system shall provide the latent user the ability to view on screen multiple potential
matching images (from different SID#) along with the latent search print in a single
screen (similar to a photo "lineup"). These are frequently referred to in the industry as
"six packs" and at default, contain the search image and five top candidate images.
L.43
For courtroom presentation of latent fingerprint and/or palmprints cases, the system shall
provide automatic "charting" of minutiae between latent candidates and known images.
This charting, at a minimum, must be saved as JPG or TIFF files; and these files must be
printable on a networked printer.
Nortel Government Solutions Incorporated
15
January 23, 2006
Functional Requirements Document (Final)
2.2.4
Version 2.0
L.44
The system shall provide a way for the original latent examiner to “send” a case to a
second latent examiner either internal or external to the original examiner's agency for
purposes of allowing the second latent examiner to review and verify latent match
results. This process will not transfer ownership of the record.
L.45
The latent user shall have the capability to cancel his/her own search transaction from the
search queue, or to delete search results awaiting search verification. The System
Administrator should be able to cancel any user's transactions.
L.46
The system shall be designed to allow a trained latent user to capture a good quality latent
print, plot 12 or more minutiae points, enter two or more filters and initiate a MAFIS
latent search in less than 10 minutes.
L.47
All Latent Workstations shall allow operators to continue to acquire images, assign
minutiae, and queue latent work for processing during any network or central site
interruption. Once the network or central site is restored, all queued records will be
automatically forwarded for latent search processing.
L.48
The system shall allow a latent operator the ability to launch a tenprint to unsolved latent
search from the latent workstation by entering a State Identification Number. In this
case, the latent examiner can override the system TP/USL threshold value for this
specific search and/or specify a fixed number of candidates to be returned for
verification.
L.49
The Latent Workstation shall enable a technician to segment out individual impressions
from a cluster and encode one or more impressions from the cluster without having to
encode all of them.
L.50
The unsolved latent database shall be sized for 350,000 records.
Latent Palm Processing Requirements
LP.1
The system shall electronically support receipt and processing of Type 15 records
including palm and writer's palm images. Personal identification will be based on
tenprints. Once a SID# is assigned, known palms can be inserted into the palmprints
database.
LP.2
The system shall automatically search the unsolved palm latent file when a new palm
print record is registered in the system.
LP.3
The system must be able to accept and process an entire palm print (lower palm) image as
a single latent image.
LP.4
All latent workstations shall support the analysis of partial and full palm latents.
LP.5
The system shall provide the ability for the latent examiner to declare a searched latent to
belong to a smaller section of the palm and to limit matching to that section when known
to avoid unnecessary use of matcher resources.
LP.6
The palm print system shall be day-one forward, sized to support 3.5 million palm print
records.
Nortel Government Solutions Incorporated
16
January 23, 2006
Functional Requirements Document (Final)
2.2.5
Version 2.0
Transaction Controller Processing Requirements
TC.1
The system will perform editing upon receipt of a NIST message to ensure all records
comply with Maryland NIST standards before further processing. Records that do not
comply with the NIST standard will be rejected, purged, with an electronic response back
to the end user.
TC.2
The Transaction Controller must support both SMTP/MIME and MQSeries transmission
protocols plus NIST, and future XML messaging to/from other systems.
TC.3
The Transaction Controller shall perform check digit validation of the process control
number (PCN) upon the receipt of new tenprint record, as per State provided algorithm.
See appendix for check digit standards.
TC.4
The Transaction Controller will create and monitor ID record workflows based on
Tenprint Transaction Type and apply internal decision logic based on processing results
supplied by all other external systems.
TC.5
The Transaction Controller will receive and process asynchronous NIST tenprint
messages from criminal arrest Livescans (Types 1,2,4/14,8,10.15 or subsets).
TC.6
The Transaction Controller must receive and process asynchronous NIST tenprint records
from applicant Livescans (Types 1,2,4/14, 8).
TC.7
The Transaction Controller must receive and process asynchronous NIST tenprint records
including criminal and applicant records from Cardscans (NIST Types 1,2,4/14,7,15).
TC.8
The Transaction Controller must send criminal and applicant NIST records to MAFIS
and receive identification messages back from MAFIS including SID#, requests for new
SID#, and error messages.
TC.9
The Transaction Controller must convert Type 4/14, 15 JPEG 2000 compressed tenprint
images to Type 4, 15 (500 ppi) WSQ tenprint images before transmission to RAFIS and
IAFIS if necessary.
TC.11 The Transaction Controller must be able to send NIST formatted ID messages back to the
submitting agency to report on identification results from MAFIS and from the FBI
IAFIS.
TC.12 The Transaction Controller ULW router functions must include the ability to forward
ULW search requests to MAFIS from authorized agencies and to block unauthorized
ULW requests from agencies not authorized to submit such requests.
TC.13 The Transaction Controller shall maintain a log of tenprint record file sizes by submitting
device so that Maryland Administrators can investigate potential overcompresson by an
image capture device.
TC.14 Transaction Controller shall perform an analysis of its work in progress database of an
adjustable time interval to identify any records that appear to be "stuck" or "orphaned"
and initiate a report concerning these records to the tenprint supervisor and the system
administrator.
Nortel Government Solutions Incorporated
17
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
TC.15 The State will own and maintain the Transaction Controller code and program upon
acceptance. The State will provide at least two developers who must be integrated into
the TC development team in key positions.
TC.16 The Transaction Controller must support transmission of JPEG and JPEG 2000 Type 10
images to IAFIS.
TC.17 The Transaction Controller must interface with the RAS system in the case of applicant
tenprints for the exchange of Type 2 data.
TC.18 The Transaction Controller must exchange Type 2 data with IPS/CCH in the case of
criminal arrest tenprints to forward Type 2 arrest data, request SID# assignment, request
name search, and status and error messages.
TC.19 The Transaction Controller must interface to the Mugphoto System server to send NIST
Types 1,2,10 messages and status and error messages.
TC.20 The Transaction Controller must interface to Northern Virginia Regional AFIS system
(RAFIS) to transmit copies of arrest tenprint records originating from Montgomery and
Prince George’s Counties.
TC.21 The Transaction Controller must interface to the Fingerprint Archive System to transmit
competed arrest and applicant tenprint records for permanent storage (Types
1,2,4/14,7,8,15).
TC.22 The Transaction Controller must interface to the FBI's IAFIS to transmit criminal and
applicant tenprint records and receive FBI identification responses.
TC.23 The Transaction Controller must maintain a statistical database so that standard and ad
hoc reports can be generated concerning records processed per unit time, by agency, by
submitting device (capture device identifier).
TC.24 All system reports shall be available indefinitely in order to support historical analysis
and audit of the processing of individual records.
TC.25 The system shall include reports that summarize input, normal and abnormal processing
activities and output. The content, organization, filters and variables of these reports
shall be configurable by the operator and/or the System Administrator.
TC.26 The Transaction Controller shall provide record error monitoring and reporting to the
Systems Administrator on an immediate basis so that corrective action may be taken to
handle "defective" records.
TC.27 The Transaction Controller must provide an administrator user interface so the tenprint
supervisors and/or the systems administrator can investigate and take action to fix or
delete problem records and messages.
TC.28 The System Administrator shall be able to limit the tasks available to a particular user
and/or group of users. Bidder shall describe how access privileges are managed in the
system.
Nortel Government Solutions Incorporated
18
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
TC.29 The Transaction Controller shall provide work queue status to a System Administrator
user interface for system monitoring purposes. A large "status screen" shall be mounted
in the Tenprint Processing area to display TC status.
TC.30 The tenprint supervisor and other authorized users shall be able to inquire as to the status
of any record(s) that is (are) "in progress" within the Transaction Controller workflows
by PCN, submitting agency, or submitting device, from a user interface on the operator's
PC.
TC.31 The Transaction Controller shall be a three-tier application built on the latest technologies
using an application server (IBM Websphere preferred), a Relational Database
Management System (RDBMS), encrypted web services, rule engine, and a thin client
interface.
TC.32 The system shall forward all appropriate (Based on NFF Requirements) criminal arrest
records to the FBI within 60 seconds of completion of the State identification process.
TC.33 The Transaction Controller must apply workflow decision logic to determine the next
step in a workflow based on messages returned from MAFIS, RAS, and IPS/CCH.
TC.34 The Transaction Controller must act as an intelligent router to forward ULW search
requests to IAFIS and to forward IAFIS search results (candidate lists) back to the
submitting ULW.
TC.35 The Transaction Controller must act as an intelligent router to receive ULW requests for
search of MAFIS and to route the MAFIS produced candidate list back to the original
requesting ULW.
TC.36 The Transaction Controller shall translate all coded information into clearly
understandable language prior to forwarding any responses to the end users.
TC.37 The Transaction Controller shall create an FIS Type of Transaction to forward finger
image quality updates and permanent scars or amputations to the IAFIS.
TC.38 The Transaction Controller shall perform check digit validation of the tracking number
upon the receipt of new tenprint records, as per State provided algorithm. See RFP
appendix for check digit standards.
TC.39 The system shall have the ability to select an adjustable number of "lights out" processed
records and send them to a second stage validation queue for manual review. This
process must be adjustable at the System Administrator level with Administrator ability
to turn manual verification on or off and to set the frequency of records to be audited
(every 10th record, every 15th record, etc.)
TC.40 The system must be capable of supporting “lights out” processing of all tenprint searches
utilizing the System Administrator adjustable threshold levels.
TC.41 The Transaction Controller shall be a robust system designed to process each transaction
within 3 seconds upon receipt.
2.2.6
Fingerprint Archive Processing Requirements
Nortel Government Solutions Incorporated
19
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
FA.1
The Fingerprint Archive system shall use the State’s SAN and mirrored disaster recovery
SAN for data storage.
FA.2
The system database shall be designed to support user-friendly search and retrieval of
individual records and system reports.
FA.3
Fingerprint and palmprints images shall be stored in their native original compression,
either JPEG 2000 or WSQ.
FA.4
The system shall be "Read-Only" and not allow any modifications to an archived record.
This includes images and demographic information
FA.5
The system shall support storage and retrieval of both Tenprint and Palmprints records
with associated demographic information.
FA.6
The system shall support an electronic expungement process to flag records in the
Archive, not allowing user access. This process will be controlled by the IPS/CCH and
forwarded via the Transaction Controller.
FA.7
The system shall log all transactions relating to user access, record retrieval, card
printing, and automated functions such as expungements and consolidations. The
transaction log must be viewable by the State Systems Administrator.
FA.8
For all expungements requests, the system shall print a fingerprint card. Each card must
be labeled in the top margin of the card "Expungement Request - DATE".
FA.9
As part of the expungement process, the system shall flag specific record(s) associated to
each PCN, SID, and/or tracking number to be expunged, from the database after printing.
FA.10 The system shall allow for an automated consolidation process upon identifying duplicate
SID numbers. This process will be initiated by the AFIS upon identification and will be
communicated by the Transaction Controller.
FA.11 The system shall report back to the Transaction Controller when each record is
successfully inserted into the database.
FA.12 If a record is not successfully inserted into the database, the system shall generate an
error message to be returned to the Transaction Controller. The Transaction Controller
must display this message in easy to understand language at the operator level.
FA.13 The system shall be designed so that it shall only accept insertions and deletions from the
transaction controller.
FA.14 The Fingerprint Archive system should use a mainstream RDBMS: State prefers Oracle,
DB2 or MSSQL Server.
FA.15 The system shall interface with the Transaction Controller for receipt of completed
tenrpint / palmprint records and for system administration messages such as errors and
expungements.
Nortel Government Solutions Incorporated
20
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
FA.16 The Fingerprint Archive system should allow the creation and printing of State and FBI
Criminal and Applicant fingerprint cards to FBI IQS networked printers. All printing will
be done on blank cardstock.
FA.17 Tenprint records printed from the Fingerprint Archive system will be printed with a “MD
CJIS” certification watermark. This certification will serve the purpose of verifying the
record is a true copy of the original.
FA.18 The system must have the ability to reproduce a fingerprint card for court that is a true
copy of the original. (Records that originate as electronic records from Livescan shall
print on Maryland’s criminal arrest or applicant forms as appropriate to the transaction
type. Additionally FBI arrest and applicant format shall be supported for printed cards.)
FA.19 The system shall provide the capability for on-line reporting based on user permissions.
FA.20 The system shall provide ability to create custom reports, as determined by the State.
(See Table 2.1 of section 2.2.10 System Management and Reporting)
FA.21 The system shall allow the system administrator, through user profiles to enforce record
access to the archive database.
FA.22 The system shall allow for a Systems Administrator to view and correct transmission or
system related errors if they occur.
FA.23 The vendor must support an enterprise licensing for the archive system clients, allowing
the State to issue access to the Archive system based on the number of user licenses.
FA.24 The Archive search shall permit the location of an individual's tenprints/palmprints by
search on SID# followed by a pick list for specific tenprint records for the individual.
Searches by other data elements shall result in a pick list or else a specific tenrpint record
(PCN search).
FA.25 The system shall provide the ability to view the full 14 image fingerprint record and
associated palmprints (if available).
FA.26 The system shall provide the operator with the capability to select any image for single
image display, enlargement or enhancement using available image processing tools
through the Archive System. Any changes to the displayed image will not affect the
image stored in the permanent database.
FA.27 The archive system must provide the ability for a user to run the archive client software
and access the archived records from any tenprint or latent workstation via a web browser
based on permissions.
FA.28 The archive system must allow an operator to retrieve a record based on either the
original SID or the consolidated SID numbers and display all records associated to the
SID in a pick list for operator review.
FA.29 The system shall provide the ability to "sort" on all the search columns based on unique
parameters, as agreed upon during system design.
Nortel Government Solutions Incorporated
21
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
FA.30 The Archive system shall reproduce an electronic record in the format of a MD Criminal
and Applicant card as well as an FBI criminal or applicant card format appropriate to the
original Type of Transaction.
FA.31 The Archive system must have the capability to store, display, and print NIST record
Types 1, 2, 4, 7, 8, 14 and 15 data. Additionally the system must provide the ability to
retrieve, display, and print a Type 10 mugphoto thumbnail image from the Mugphoto
server with the fingerprint record.
FA.32 The Archive system must support SMTP/MIME or MQSeries transmission protocols plus
NIST and future XML messaging to/from other systems.
FA.33 The vendor shall provide follow on maintenance and support of all Fingerprint Archive
components for both software and hardware via a separately negotiated maintenance
agreement.
FA.34 Each workstation must be able to access on-line help and workstation documentation,
including user manual, technical manual and maintenance manual. Any authorized
system user must be allowed to access the on-line documentation.
2.2.7
AFIS Inked Card Conversion Requirements
DC.1
For the purposes of the AFIS, the best quality record on file shall be converted.
DC.2
Duplicate SID numbers should be identified during tenrpint record conversion or during
initial load on the new MAFIS.
DC.3
Image processing during initial tenprint load of the new MAFIS should include minutiae
coding, pattern typing (auto classification) and print quality coding with fingerprint
sequence checks for each finger in each record.
DC.4
Conversion of all inked hard cards shall be done at 1000ppi and JPEG 2000 compression
for the purpose of storage in AFIS (2.5 million records) and the State’s Fingerprint
Archive system (estimated 5.5 million cards).
DC.5
For the Fingerprint Archive system each individual hardcard must be electronically
converted and stored (unaltered) in the database.
DC.6
Converted hardcard records shall be compliant with FBI and NIST standards for
compression and storage.
DC.7
The vendor will supply trained and experienced operators to perform both hard card and
electronic card conversion.
DC.8
Archive conversion must include the scanning of each event record for storage of all
events under the same person ID (SID) in the Archive System. The State will provide
descriptor data via electronic media for each card converted listed by SID and Event
Number.
Nortel Government Solutions Incorporated
22
January 23, 2006
Functional Requirements Document (Final)
DC.9
Version 2.0
The bidder must state the number of cards or electronic records per week to be converted
and the length of time cards will be out of file. The bidder must clearly define any tasks
that will be the responsibility of the State.
DC.10 All card conversion will be performed at the Maryland State designated location.
DC.11 All descriptor data in current system shall be brought from the existing electronic archive
database via electronic media provided by the State.
DC.12 Converted electronic records should be compliant with FBI and NIST standards for
compression and storage. (The records are currently in NIST format with original WSQ
compression).
DC.13 All electronically submitted tenprint fingerprint records in the current Fingerprint
Archive system database shall be transferred into the new AFIS and Fingerprint Archive
System at 500 ppi.
2.2.8 Fast Identification
FI.1
Capture devices for Probation Dept. will be USB single finger flat image scanners with
client software set to capture two flat images. Pilot quantity is 4 units. Optional twofinger simultaneous capture device will be considered.
FI.2
Vendor will supply mobile WiFI (802.11g) PDA type capture devices for Dept. of
Corrections. Pilot Quantity is 8 units. State will supply wireless network.
FI.3
The system shall capture two fingers' flat images sequentially or optionally
simultaneously.
FI.4
FAST ID system shall retrieve a thumbnail photo, if available, from Mugshot server and
transmit to user along with FAST ID matching SID# result.
FI.5
FAST ID client shall display search results including at a minimum SID#, small photo,
Name, address, SSN depending on data availability.
FI.6
The FAST ID system must accept records containing one, two, or more finger images
captured at 500 or 1,000 ppi, compressed using WSQ or JPEG 2000. FAST ID images
may be rolled or flat.
FI.7
The FAST ID record structure may be NIST format, M1 format, or SC37 format. FAST
ID records may contain fingerprint images or extracted minutiae (without images) per M1
and SC 37 standards.
FI.8
All FAST ID capture messages will be via TCP/IP.
FI.9
FAST ID system must support processing of FAST ID submissions from third party
vendors as long as message formats conform to NIST, M1, or SC 37 standards.
FI.10
The FAST ID system shall log and store transaction information including submitting
agency, capture device identifier, image quality date, time, match results suitable to
determine processing time and possible device quality problems.
Nortel Government Solutions Incorporated
23
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
FI.11
FAST ID shall NOT use the Transaction Controller. Vendor must supply appropriate
system interface that supports 128-bit encryption and message controller between AFIS
matching system and FAST ID capture devices. (Maryland will supply the network).
FI.12
FAST ID system shall enable reporting by user, device, agency, date, time and result
(match to SID# or no match) for managerial and statistical purposes.
FI.18
The vendor shall provide follow on maintenance and support of all back end Fast ID
components for both software and hardware via a separately negotiated maintenance
agreement.
2.2.9 Mugshot System
MS.1
The system should have the ability to export images in NIST Type 10 format.
MS.2
The system shall provide a browser-based query interface.
MS.3
The vendor shall provide an enterprise license of the client software for installation on
State provided hardware.
MS.4
Mugphoto software shall be made available on all latent and tenprint workstations at a
minimum.
MS.5
The system shall use the State’s SAN for data storage.
MS.6
The system shall provide automatic system monitoring tools to include real time
detection of system hardware or software failures.
MS.7
The system should have flexible identification indexing to be able to link records across
multiple systems using common identification attributes (e.g. SID number, PCN, Arrest
date, time and location) as needed.
MS.8
The Transaction Controller shall automatically send all associated photos to the
Mugphoto server upon SID assignment.
MS.9
The system shall provide automated parametric search of the photo records database and
retrieval of images for all records satisfying the search parameters (e.g., height, weight,
gender, race, hair color, group affiliation, etc.).
MS.10 The system shall provide automated search of the photo records database and retrieval of
all images similar to a specified search record (i.e., individuals with the same physical
characteristics as a specified subject).
MS.11 The system shall perform an automated search of the photo records database and retrieval
of all records for individuals with a specified tattoo.
MS.12 The system shall not allow any permanent editing of photo record information by any
user, without first logging the reason for the modification along with the photo record.
(Modifications to the photo image will be prohibited.)
Nortel Government Solutions Incorporated
24
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
MS.13 The system shall support an automated consolidation process. This process will be
controlled by the IPS/CCH system and transmitted through the Transaction Controller.
MS.14 The system shall support an automated expungement process to flag selected records
from the central photo repository database, making the record inaccessible by a user.
MS.15 The system shall provide automatic logging of each transaction event from receipt,
processing, and response stages.
MS.16 The list of records returned to the operator during a record retrieval process must be
displayed in chronological order. (Most recent first)
MS.17 The system must automatically store and use for facial recognition the most recent photo
images of an individual.
MS.18 The system shall store all photos received for each individual, indexed by SID, PCN
and/or tracking number. The PCN or tracking number will identify a specific event.
MS.19 A thumbnail photo image (full face) shall be accessible to support FAST ID and the
Fingerprint Archive systems.
MS.20 The vendor shall provide line item costs for facial recognition capabilities as an optional
cost.
MS.21 The system should accept the record into the server in NIST Type 10 format with
associated demographic data in Type 2 format.
MS.22 The system shall include, but not be limited to the following image profiles: front, left
profile, right profile, scars, marks and tattoos.
MS.23 The facial recognition package shall provide the ability to enable a facial recognition
search of the photo records database, and retrieval of all identified matching or possibly
matching images, including storage of matched photos for later retrieval without the need
to repeat the prior search.
MS.24 The color photo image must be digitized and stored with a resolution that is at least the
resolution specified in the standards outlined in the NIST Best Practice Recommendation
For The Capture Of Mugshots (Version 2.0).
MS.25 Photo images stored in the State's database must be stored as compressed files using the
JPEG 2000 compression algorithm.
MS.26 The system shall be designed to allow the addition of a facial recognition software
package as a separate module for a future enhancement without requiring any major
system changes.
MS.27 The vendor shall provide network ready color printers for optional purchase.
MS.28 The system shall provide the ability to generate hardcopy prints of the record data and
color photographs, including the capability to print on a network-connected color printer.
Nortel Government Solutions Incorporated
25
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
MS.29 Printing of photo or fingerprint images at a specific Remote Workstation must be
controlled as an agency option. Some agencies may not wish to automatically print photo
images and/or fingerprint images as part of the search response.
MS.30 The vendor shall supply both preconfigured reports and the ability for the System
Administrator to easily generate ad hoc reports.
MS.31 The system shall provide reporting features which access the database management
systems for the on-line photo database and provide standard and ad-hoc reports relating
to photo database administration (e.g., management reports, statistical reports, etc.).
MS.32 The system shall provide interactive tools to allow the State system administrator to
monitor all processes and queues, and to detect and correct system operational problems.
MS.33 The system must provide interactive tools to the State System Administrator to access
transaction logs for performance and activity analysis.
MS.34 The system shall provide for remote access to support troubleshooting and maintenance
capability. This will allow a remotely located system engineer to operate system
diagnostics, correct operational problems and download software modifications.
MS.42 The operator shall have the capability of making an on-screen indication that the photo
image must be retaken at a later date.
MS.43 The system shall provide retrieval and display of any user-selected image or all images
for a specified individual, along with all associated record information.
MS.44 The photo system shall organize and display all data for an individual in record format or
line-up format, with user controls providing unrestricted capabilities for selecting and
modifying views of the data.
MS.45 The system shall allow an operator to copy selected records to a removable media
consistent with industry best practice (i.e. optical, DVD, DAT, etc.).
MS.46 System generated errors shall be provided on screen to the end user in understandable,
user level terms.
MS.47 Each workstation must be able to access on-line help and workstation documentation,
including user manual, technical manual and maintenance manual. Any authorized
system user must be allowed to access the on-line documentation.
MS.48 The record retrieval software shall allow an operator to retrieve a record based on criteria
of SID, PCN, and name at a minimum.
MS.49 The Mugphoto System must support SMTP/MIME or MQSeries transmission protocols
plus NIST, future XML messaging to/from other systems.
MS.50 The vendor shall provide follow on maintenance and support of all Mugphoto system
components for both software and hardware via a separately negotiated maintenance
agreement.
Nortel Government Solutions Incorporated
26
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
2.2.10 System Management and Reporting
SM.1
The vendor must provide a Systems Operations and Support document that outlines the
processes and procedures taken to ensure the AFIS, FAST ID, Archive, and Mugphoto
systems are maintained and supported to the required performance standards. This
document must be approved by the Maryland DPSCS.
SM.2
Reports shall include information on: operator performance, accuracy, counts of records
received, rejected at each edit point, records processed - longest time shortest time,
average time, etc. (A listing of minimal reports for each subsystem is outlined in Table
2.1)
SM.3
The reporting functionality shall allow the System Administrator the capability to limit
operator access to reports through individual user’s roles settings.
SM.4
The vendor shall supply both preconfigured reports and the ability for the System
Administrator to easily generate ad hoc reports using vendor provided or third party
software (e.g. Crystal Reports).
SM.5
The system shall include reports that summarize input, normal and abnormal processing
activities and output. The content, organization, filters and variables of these reports
shall be configurable by the operator and/or the System Administrator.
SM.6
All system reports shall be available indefinitely in order to support historical analysis
and audit of the processing of individual records.
SM.7
No reporting data will be destroyed throughout the life of the contract without written
permission from the Maryland DPSCS.
SM.8
The report system shall support the retrieval and display of any system statistical data
without impacting system performance.
SM.9
The system reports shall support the ability to export data into standard MS Office Excel
spreadsheet or Access database.
SM.10 The system shall include on-line monitoring and system administration, which can be
operated remotely through a Virtual Private Network (VPN).
SM.11 The system must maintain transaction logs to assist in recovery of data files.
SM.12 The system should have the capability to allow the system administrator to modify the
number of candidates returned to a workstation through threshold modification.
SM.13 The system should have the capability to allow the system administrator to adjust the
threshold levels for 'lights out' performance.
SM.14 The System Administrator shall be able to limit the tasks available to a particular user
and/or group of users. Bidder shall describe how access privileges are managed in the
system.
SM.15 The vendor shall provide ample on-site support staff for the AFIS, FAST ID, Archive,
and Mugphoto systems to support the required availability. This support will be available
Nortel Government Solutions Incorporated
27
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
on-site during the normal work week of Monday through Friday, 8:00 AM to 5:00 PM
throughout the warranty period. Support will be available on-site after the warranty
period at the option of the State.
SM.16 The vendor will provide on-call support 24 X 7 X 365 for any system performance or
operational issues within fifteen minutes of the first attempt to contact the on-call
support.
SM.17 Each on-call technician must have high-speed remote access (vendor provided at vendor
site) into the system to perform system maintenance. State will work with vendor to
provide VPN secure access.
SM.18 The systems shall provide an easy display of all error queues and system exceptions for
State Administrator viewing and printing.
SM.19 The systems queue transaction activity display shall be automatically refreshed at an
adjustable rate. Recommend refreshing within 3-5 minute intervals.
SM.20 The AFIS and Transaction Controller systems queue transaction activity displays shall be
available for display at any time on any workstation in the system based on user
permissions.
SM.21 The vendor shall place all accepted software for all system components of AFIS,
Fingerprint Archive, Fast Identification, and Mugphoto Systems in Escrow. This Escrow
account will be available to the State if the selected vendor discontinues business and will
become the property of the State of Maryland. (Includes all system upgrades and
enhancements.)
SM.22 On-Site support must be available within one hour of notification if resolution cannot be
done remotely.
Nortel Government Solutions Incorporated
28
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
Table 2.1 Reporting Requirements
System Component - AFIS
Report Description
Production Reports
Periodic Statistical Reports - Report of processing
data from a selected start date and end date. Report
must include at a minimum, number of records
processed by type, site location, average processing
time, and number of hits made. Reports must be
available for each subsystem of Tenprint, Latent, and
Fast ID processing.
Detailed Monthly/Weekly Statistical Reports Provide information on Month or Week selected and
provide information on average processing time for
each transaction type received. Reports must be
available for each subsystem of Tenprint, Latent, and
Fast ID processing.
Daily Statistical Reports - Provide daily information
on number of records processed, by location, with
average processing time. Reports must be available for
each subsystem of Tenprint, Latent, and Fast ID
processing.
Hourly Statistical Reports - Provides a number of
records processed by hour by record type. Reports
must be available for each subsystem of Tenprint,
Latent, and Fast ID processing.
Quality Rejection Report - Provide rejection
information on all records sent to QC due to poor
quality or sequence errors by date/time range.
Information will be available by site location.
User Performance Report - This report will be
available to individual operators, supervisors or
managers to display based on permissions. Report will
provide number of records processed and decision
made. This report will be available by date range or
individual record.
Transaction Inquiry Report - This report must be
available for operator, supervisor and administrator use
to provide all information regarding a specific
transaction upon request. (for completed and
incomplete transactions.) Event information such as
coding, quality, verification, hit/no-hit, and associated
user interaction will be indicated.
System Administration Reports
Nortel Government Solutions Incorporated
System Capacity Report - Report must indicate the
number of records in the database, number of new
records added by adjustable time period, and the
29
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
anticipated time the system will meet the contract
capacity.
System Error Report - Provide a report of all system
generated errors and the number of each error logged
by date range and/or error type.
System Availability Report - This report will be
available either daily, weekly, monthly, or annually.
This report will indicate the system operational status
for both Fully Operational and Reduced Capacity
operations.
System Security
User Activity Report – provides a listing of all
date/times when each individual logged on and off the
system. Report can be ran by individual or site location
based on date/time range.
User Access Listing – this report will provide a list of
all current users with the date of creation and the date
of last login.
Security Incident Report – this report will identify all
invalid login attempts by location/workstation or User
ID for a given time period.
System Component – Transaction
Report Description
Production Reports
System Activity Report - Report will include the
number of records processed by type with an average
processing time. The option to break down information
by agency must be available. The report will have the
option to include listing all activities completed. (i.e.
successful submission to RAS, IPS/CCH, Archive,
Mugphoto, RAFIS, IAFIS)
Response Time Failure Report - Report will provide
a listing of all records that did not meet the Service
Level Agreement timeline for processing. Each record
identified will outline the processing steps with
date/time indicator for troubleshooting purposes.
Quality Override Report - This report can
generated upon request and sorted by User for
Livescan or Cardscan records indicating quality
sequence overrides performed. The report can
generated by site location, and/or Operator.
be
all
or
be
IAFIS Transaction Report - Report will outline the
number of records submitted to IAFIS by date period
for both tenprint and latent submissions. The number
of rejected records will be available on the report. The
average response time will be indicated.
Expungement/Consolidation Report - This report
will identify and list all expungements and/or
Nortel Government Solutions Incorporated
30
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
consolidations for a given time period requested by the
system. This report must indicate the success of failure
of each associated system, i.e. AFIS, Archive,
Mugphoto. Additionally a summary report will provide
the number of records expunged or consolidated over a
period of time.
System Administration Reports
System Availability Report - Report will provide the
operational availability status of the Transaction
Controller for a specified time period.
Error Reporting - Error reports will be available for
all system activities. These activities will include at a
minimum, NIST Edit errors, all subsystem provided
errors relating to AFIS, Mugphoto, and Archive system
updates.
Lights Out Decision Report - The report will be used
to determine threshold adjustments. The report must
indicate the number of records that generated a hit
decision by the Verification Operator with the
candidate in the number one position including matcher
score. Additionally, this report will provide the number
of ‘lights out’ hit decisions made. All hits outside of
the number one position on the candidate list will also
be shown for assistance in the decision making process.
System Security
User Activity Report – provides a listing of all
date/times when each individual logged on and off the
system. Report can be ran by individual or site location
based on date/time range.
User Access Listing – this report will provide a list of
all current users with the date of creation and the date
of last login.
Security Incident Report – this report will identify all
invalid login attempts by location/workstation or User
ID for a given time period.
System Component – Archive
Report Description
Production Reports
System Activity Report - Report of all new record
inserts/updates for a given period of time.
System Activity Report - This report process will have
the ability to identify all activity for a given record.
User information that accessed and/or printed the
record.
Expungement/Consolidation Report - This report
will identify and list all expungements and/or
consolidations for a given time period. Additionally a
summary report will provide the number of records
expunged or consolidated over a period of time.
Nortel Government Solutions Incorporated
31
January 23, 2006
Functional Requirements Document (Final)
System Administration Reports
Version 2.0
System Availability Report - Report will provide the
operational availability status of the Archive for a
specified time period.
System Capacity Report - Report will provide a list of
all records, tenprint – palmprint specific in the Archive
system. The growth by month since the system was
installed. Estimated date when the system contracted
capacity is met.
Error Reporting - This report will identify all errors
generated resulting from insert or update failures,
expungement or consolidation failures.
System Security
User Activity Report – provides a listing of all
date/times when each individual logged on and off the
system. Report can be ran by individual or site location
based on date/time range.
User Access Listing – this report will provide a list of
all current users with the date of creation and the date
of last login.
Security Incident Report – this report will identify all
invalid login attempts by location/workstation or User
ID for a given time period.
System Component – FAST ID
Report Description
Production Reports
System Activity Report - Report of all search requests
by location or device number for a given period of time
with the number of hits identified. Report will provide
the ability to define by hour, day, week, or month.
System Administration Reports
System Availability Report - Report will provide the
operational availability status of the Fast Identification
system for a specified time period.
Error Reporting - This report will identify all errors
generated resulting from search requests.
System Security
User Activity Report – provides a listing of all
date/times when each individual logged on and off the
system. Report can be ran by individual or site location
based on date/time range.
User Access Listing – this report will provide a list of
all current users with the date of creation and the date
of last login.
Security Incident Report – this report will identify all
invalid login attempts by location/workstation or User
ID for a given time period.
System Component – Mugphoto
Report Description
Production Reports
System Activity Report - Report of all search requests
by location or device number for a given period of time
Nortel Government Solutions Incorporated
32
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
with the number of hits identified. Report will provide
the ability to define by hour, day, week, or month.
System Administration Reports
System Availability Report - Report will provide the
operational availability status of the Mugphoto system
for a specified time period.
System Capacity Report - Report will provide a list of
all photo records in the system, the growth by month
since the system was installed. Estimated date when
the system contracted capacity is met.
Error Reporting - This report will identify all errors
generated resulting from search requests.
System Security
User Activity Report – provides a listing of all
date/times when each individual logged on and off the
system. Report can be ran by individual or site location
based on date/time range.
User Access Listing – this report will provide a list of
all current users with the date of creation and the date
of last login.
Security Incident Report – this report will identify all
invalid login attempts by location/workstation or User
ID for a given time period.
Nortel Government Solutions Incorporated
33
January 23, 2006
Functional Requirements Document (Final)
3
Version 2.0
OPERATIONAL REQUIREMENTS
Operational requirements describe the non-business characteristics of an application and deal
with the operations of the information technology components.
3.1
Security
All AFIS software components shall provide a mechanism for protecting system data and the
operational environment from compromise or unauthorized access. It includes the ability of the
COTS software to prevent malicious as well as non-malicious security breaches. The COTS
software shall provide a security mechanism that does not require a user or administrator within
the product to have local or domain admin privileges within the operating system. All systems
must follow the Maryland Department of Budget and Management Office of Information
Technology Information Technology Security Policy and Standards document Version 1.3 dated
December 2005.
The following requirements support the protection of the system required by DPCSC:
S.1
Login access shall be controlled with a unique user login name plus password. (State
prefers the utilization of LDAP to a State directory.)
S.2
Password shall be modifiable by each user and password modification shall be allowed
from the user's workstation.
S.3
The vendor shall use the security templates developed by the State, if available.
Otherwise the vendor shall supply their own security templates and provide the templates
to the State System administrators.
S.4
The system shall require a re-definition of passwords on a periodic basis (e.g. Every 45
days) interval to be modifiable by the State.
S.5
The State System Administrator should be able to add and delete users and/or require
update of password(s).
S.6
The system shall produce intrusion alerts for unsuccessful login attempts beyond State
specified threshold.
S.7
State System Administrator shall have the ability to set a system directed automatic
logout for operator inactivity.
S.8
The system shall allow only connection to the DPSCS intranet (via the internet), through
VPN or SSL. There shall not be any remote dial-up access. Note: State will provide all
necessary firewall hardware and VPN components.
S.9
The State’s AFIS System Administrator shall manage System and subsystem security
centrally. As an option, the Administrator shall be able to assign remote site
administrators for the purpose managing local user access.
S.10
The State System Administrator shall have the power to immediately terminate an enduser’s session(s).
Nortel Government Solutions Incorporated
34
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
S.11
The system shall not allow a user to have more than one session active on the same
system at the same time.
S.12
Any attempt to log into a workstation with an invalid user name/password shall be logged
at the central site.
S.13
Intrusion attempts shall be identified in real time and an alarm notice based on State
defined threat levels shall be immediately sent to the AFIS System Administrator.
S.14
The AFIS security scheme shall record operator activities and access to system and
subsystem components. In particular, details for each record addition, edit and deletion
shall be available for review.
S.15
The proposed AFIS technology shall provide the necessary log files for tracking all latent
and tenprint transactions, whether received or transmitted electronically or manually.
S.16
The vendor shall ensure that all security log files be maintained in primary storage (State
SAN) for a minimum of 24 months. After 24 months, logs will be moved offline to
secondary storage.
S.17
The vendor shall ensure that all log files are protected from modification.
S.18
Assign security access by user, role and/or group. Examples of roles include Supervisor,
Senior Operator, and Entry Level Operator.
S.19
Have an order of security precedence, such as user id, role and group.
S.20
Have the ability to grant roles to users and have the user inherit the security access
granted to all roles assigned to the user.
S.21
Allow association of one or more groups to a user.
S.22
Test and Training databases must be separate from operational databases.
S.23
The system shall allow the system administrator to invoke security changes immediately
(i.e. system restart is not required to effect security changes).
S.24
The AFIS shall use the State's enterprise anti-virus software if applicable to the operating
system chosen. Otherwise the vendor shall supply an anti-virus and malware
management plan appropriate for the AFIS environment.
S.25
The Transaction Controller shall use the State's enterprise anti-virus software if
applicable to the operating system chosen. Otherwise the vendor shall supply an antivirus and malware management plan appropriate for the Transaction Controller
environment.
S.26
The Fingerprint Archive shall use the State's enterprise anti-virus software if applicable
to the operating system chosen. Otherwise the vendor shall supply an anti-virus and
malware management plan appropriate for the Fingerprint Archive environment.
Nortel Government Solutions Incorporated
35
January 23, 2006
Functional Requirements Document (Final)
3.2
Version 2.0
S.27
The Mugphoto Server shall use the State's enterprise anti-virus software if applicable to
the operating system chosen. Otherwise the vendor shall supply an anti-virus and
malware management plan appropriate for the Mugphoto Server environment.
S.28
The Fast ID shall use the State's enterprise anti-virus software if applicable to the
operating system chosen. Otherwise the vendor shall supply an anti-virus and malware
management plan appropriate for the Fast ID environment.
S.29
Biometric logon is a desirable option to the State. Vendors shall describe the use of this
feature if available with their proposed solution.
S.30
The vendor shall ensure that all audit trail logs are accessible to CJIS-CR administrators
and their designees for use in performance evaluations and problem solving.
Audit Trail
The AFIS security scheme shall record operator activities and access to system and subsystem
components. In particular, details for each record addition, edit and deletion shall be available for
review.
The proposed AFIS technology shall provide the necessary log files for tracking all latent and
tenprint transactions, whether received or transmitted electronically or manually. Further, all
changes and releases for each record shall be recorded in these log files. Logging shall be
accomplished in a manner that facilitates reviews, searches and reporting of actions that have
taken place within the AFIS environment. Additionally information regarding system audit trail
requirements can be found in the Maryland Department of Budget and Management Office of
Information Technology Information Technology Security Policy and Standards document
Version 1.3 dated December 2005.
The Vendor shall ensure that all audit trail logs are:
3.3
3.4

Retained according to parameters that will be specified by the ITCD:

Backed up and deleted from the system in accordance with scheduled security backups

Protected from modification

Accessible to CJIS-CR administrators and their designees for use in performance
evaluations and problem solving
Networking
N.1
The system shall be able to accommodate remote latent or tenprint workstations with
minimum communication rates of .5 T1-capacities (750 kbs). These workstations shall
have acceptable response times for the user, in accordance with the Business
Requirements.
N.2
The system shall support direct communications with either Ethernet (locally) or a
substantially equivalent media.
N.3
The vendor shall ensure that secure communication is used in the operation of all
subsystems. Further, TCP/IP shall be used by all network solutions.
Data Currency
Nortel Government Solutions Incorporated
36
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
AFIS is a real time mission critical system that requires data to be stored and be available as soon
as possible. The following are some examples within the AFIS system that require data to be
current.
Process Queues – All process queues that show the work in process for fingerprint identification.
The system queue transaction activity display shall be automatically refreshed at an adjustable
rate. Recommend refreshing within 3-5 minute intervals. The system queue transaction activity
display shall be available for display at any time on any workstation in the system by authorized
users.
Tenprint – prints and mug photos should be stored and available for searching immediately after
being identified by the AFIS system and a SID# has been assigned.
Unsolved Latents – Unsolved latent prints entered by a remote site shall become immediately
available for tenprint to unsolved latent searches.
3.5
Reliability
The system servers shall allow for secure remote administration. These systems shall provide for
automatic alerting to system administrators and State personnel when there are problems or
failures with the system software and hardware. This provides monitoring and support,
minimizing the need for on-site personnel. This will result in avoidance of outages and shorter
down time when there is an outage.
3.6
System Availability
The system shall be a high availability system that operates on a twenty-four hours per day, seven
days per week, 365 days per year basis (24 x 7 x 365). The system should meet 99.99%
availability. Software maintenance must be performed without requiring system downtime. The
system will be considered down whenever normal AFIS operations cannot be conducted without
experiencing major system alarms or conditions that inhibit or prevent the user from performing
vital processing functions.
3.7
Fault Tolerance
SA.1
All critical system components must be protected through the use of redundant
components. Switchover shall be automatic and shall not require ANY manual
intervention. (This does not include catastrophic events.)
SA.2
The system should meet 99.99% availability on a monthly basis. Maintenance activities
shall not interrupt production performance. The system will be considered down
whenever normal AFIS operations cannot be conducted to support the system throughput
requirements.
SA.3
The power supply for the servers should be modular and should include redundancy such
that the power supply system is capable of meeting full and continued supply of server
power.
SA.4
The system shall provide for automatic alerting to system administrators and State
personnel when there are problems or failures with the system software and hardware.
Nortel Government Solutions Incorporated
37
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
SA.5
The system shall support back-up processes that do not require system downtime or
reduced performance.
SA.6
System availability is measured on a monthly basis, starting at 12:00am Eastern Standard
Time (EST) on the first day of each month and ending at 11:59pm EST on the last day of
the month. Note that allowable downtime does not accumulate from month to month, but
is reset at the beginning of each month.
SA.7
The vendor shall provide a script that will allow for the automatic start-up of the system
and application components when a server powers up.
SA.8
At minimum, system generated statistical reports of daily, weekly, monthly and yearly
performance shall be readily available to the State AFIS Administrator.
SA.9
System availability reports shall cover date, time and duration for all recorded events,
outlining System Unavailability or Reduced Capacity operations within the period
selected for the reporting. (Recorded events must include any system interruption that
impacts production.)
SA.10 The system must be designed to operate in a 'Reduced Capacity' mode if system
malfunctions occur. At a minimum, 50% of the total volume of transactions, including
100% of the priority 1, 2, and 3 transactions shall be processed within their normal
response time.
SA.11 At a minimum, the System shall only function in a Reduced Capacity mode for a
cumulative maximum of 48 hours per year, for a duration not to exceed 12 hours within
one month.
SA.12 The vendor must provide a one year warranty on all hardware and software provided.
The warranty period begins upon full acceptance of each system.
SA.13 The vendor and appropriate sub-system vendors shall provide follow-on maintenance
support for AFIS, Fingerprint Archive, Fast Identification, and Mugphoto systems. The
vendor shall provide a draft Maintenance Plan with their proposal outlining the below
listed categories:
o
Help Desk Services
o
Method of Notification
o
Escalation Procedures
o
Problem Escalation
o
Non-Performance Penalties
o
Test Equipment
o
Installation, Verification and Validation (IV&V)
o
Software Defects
o
Upgrade Support
o
Enhancements
o
VPN Connectivity
Nortel Government Solutions Incorporated
38
January 23, 2006
Functional Requirements Document (Final)
3.8
Version 2.0
Disaster Recovery
DR.1
The State will provide an off site location for disaster recovery, the vendor shall provide
the hardware and software to operate the following systems: AFIS, Transaction
Controller, Fast Identification, Fingerprint Archive, and Mugphoto.
DR.2
The Vendor shall propose hardware for the disaster recovery site that will allow the State
to operate at a minimum of 50% capacity with short-term plan to provide 90%
availability within 7 days.
DR.3
In the event of a disaster, the Vendor shall be capable of failover to the disaster recovery
site within one hour.
DR.4
The Vendor shall use the State provided SAN device at the disaster recovery site and
replicate the required data for the disaster recovery system. (The DR SAN is of the same
model as the primary).
DR.5
The Vendor shall provide a method of data replication that provides real time replication
with no more than 2 minutes latency between the primary and secondary storage devices.
DR.6
Equipment provided under this RFP, shall be connected to State provided UPS units.
Sufficient UPS capacity will exist at both primary and recovery sites.
DR.7
All servers shall be configured with automated scripts for controlled shutdown, and
automatic startup without manual intervention in the event of primary power failure and
UPS battery depletion.
DR.8
The successful Vendor shall provide a single, detailed IT Disaster Recovery/IT Business
Continuity Plan (Plan) addressing the needs of DPSCS. This plan should cover a variety
of likely situations and may include various options for response.
DR.9
The Vendor shall provide in its recommendations the step-by-step sequence of actions
and associated disaster recovery team position-responsibilities needed to re-locate
facilities and functions to their alternate sites.
DR.10 The Vendor shall include the associated DRT (disaster recovery team) positionresponsibilities to restore IT facilities and functions to their pre-event status.
DR.11 The Vendor shall provide, and keep current, electronic and paper copies of the following
to be stored at State provided off-site storage: For all system components, the documents
should include custom code and corresponding design and support documentation, server
configurations, design, support and maintenance documents.
DR.12 Vendor shall include recommendations of proposed level of internal Auditing and
Testing plans for the backup systems; clear statement of Test objectives; description of
Test methods and step-by-step Test methodology; evaluation and optimum use of Test
results; and a proposed Audit and Test frequency and schedule.
Nortel Government Solutions Incorporated
39
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
DR.13 The Transaction Controller (TC) shall be mirrored at the disaster recovery site with the
mirrored TC able to immediately continue processing in the event of failure of the
primary TC.
DR.14 The system shall have a process in which the primary or secondary systems will be resynched and operations will resume at the conclusion of a disaster.
DR.15 The vendor shall provide both training and documentation on the disaster recovery plan.
3.9
Performance
T.31
The system shall be capable of handling throughput to support tenprint processing of 270
records per hour against a database of 4 million records.
T.33
The system shall be capable of processing 270 good quality tenprint records within one
hour on a continuous basis.
L.23
All unsolved latent prints shall be stored in AFIS uncompressed at 1,000 ppi or if
compressed, the compression must not allow any loss of image quality.
L.24
The system shall be sized to process 100 latent to tenprint searches in an 8-hour period
and 300 LT/TP searches in 24 hours against a database of 4 million tenprint records
containing all 14 images and including latent searches against both rolled and flat images.
L.25
The system shall be sized to process 100 latent to unsolved latent searches in an 8-hour
period and 300 LT/UL searches in 24 hours.
L.26
The system shall be sized to process 40 latent palm print to known palm print searches in
an 8-hour period and 120 LP/PP searches in 24 hours.
L.27
The system shall be sized to process 1100 tenprint to unsolved latent fingerprint searches
per day (24 hour period) against a database size of 350,000. See Statement of Work
Section 3.10 for a complete performance outline.
L.28
The system shall be sized to process 15 latent palm print to unsolved latent palm print
searches in an 8-hour period and 45 LP/ULP searches in 24 hours. L.29 The
system
shall be sized to process 120 known palm prints to unsolved latent palm print searches
per day (24 hour period). See Statement of Work Section 3.10 for a complete
performance outline.
FI.13
Fast Identification must process records and transmit search results within 3 minutes of
receipt of the search request and 1 minute of receipt of a 1:1 match request.
FI.14
Fast Identification searches shall be performed against the AFIS tenprint database of 4
million person records.
FI.15
The volume of 1:1 Fast Identification searches will be 1,500 per day with peak hour of
500 searches.
FI.16
The volume of 1:N Fast Identification searches will be 7,000 per day with peak hour of
500.
Nortel Government Solutions Incorporated
40
January 23, 2006
Functional Requirements Document (Final)
FI.17
Version 2.0
The Fast Identification peak hours for 1:1 and 1:N searches could occur concurrently for
a total peak hour volume of 1,000 FAST ID search requests.
MS.35 The Mugphoto system shall be designed to support a database size of 5,000,000 records
consisting of 2.4 million and growing individual SID# plus multiple arrest images from
multiple arrests of the same individual.
MS.36 The Mugphoto system shall support record receipts and inserts at up to 1500 daily with a
peak performance of 250 per hour.
MS.37 The Mugphoto system shall support a normal workload of twenty (20) investigative (lineup) transactions per hour in addition to all other processing activities.
MS.38 The Mugphoto system shall be capable of processing a request, for the most current
photo image set from on-line storage (receipt of request at Mugphoto server to time
server starts to transmit to workstation) in a response time of 3 seconds or less.
MS.39 The Mugphoto system shall be capable of processing a request, for an index of all on-line
and archived photo records for an individual (receipt of request at Mugphoto server to
time server starts to transmit to workstation) in a response time of 3 seconds or less.
MS.40 The Mugphoto system shall be capable of processing a request, for a user-selected photo
record from on-line storage (receipt of request at Mugphoto server to time server starts to
transmit to workstation) in a response time of 3 seconds or less.
MS.41 The Mugphoto system shall be capable of processing a request, for the initial six (6)
images for a line-up in response to a parametric search inquiry of the on-line database
(receipt of request at Mugphoto server to time server starts to transmit to workstation),
with a response time of 10 seconds or less.
3.10
Data Retention
Maryland’s overall retention requirement for AFIS and Arrest information is ninety-nine (99)
years. Purges and expungements are ordered by the courts, and will require special user
authorization to perform the removal of records with a minimum of two levels of approval.
Standard user privileges shall not include the delete capability.
3.11
Project Management and Development
PM.1
The vendor shall provide resumes of all management team members assigned to this
contract. At a minimum, this will include: Project Sponsor, Project Manager,
Engineering Manager, Trainer, and System Design Engineer.
PM.2
The vendor shall outline the team approach to execute each phase of the project. The
following constitute the phases for this project: Planning, Design, Development,
Implementation (Testing, Training, Data Conversion, Installation, Transition), Systems
Operations and Support.
PM.3
The vendor shall ensure all sub-contractors are managed within the State approved
management process.
Nortel Government Solutions Incorporated
41
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
PM.4
The vendor shall be responsible for all requirements outlined in this document flowing
down to all sub-contractors involved in this project.
PM.5
The vendor shall use the Maryland DPSCS Project Management Office as the sole
interface to the State staff.
PM.6
The vendor shall ensure that all project activities shall be agreed upon by consultation
with the Maryland DPSCS Project Management Office.
PM.7
The vendor shall demonstrate industry standard project management methodologies. The
standard desired by the State of Maryland follows the Project Management Book of
Knowledge (PMBOK) methodology.
PM.8
The Vendor shall manage all work under this contract with a proven System
Development Life Cycle (SDLC) and approved by the State of Maryland.
PM.9
The vendor shall ensure all management plans and methodologies are driven down to all
sub-contractors. This will be documented and approved by the State of Maryland in the
Sub-contract Management Plan.
PM.10 The vendor shall provide a detailed project schedule as part of the Project Management
Plan. This schedule will not be deviated from without written approval from the State of
Maryland.
PM.11 The State of Maryland DPSCS shall provide on-site office space for up to five personnel
throughout the SDLC process.
PM.12 Project planning sessions shall begin within ten days of contract award.
PM.13 The vendor shall plan for the project planning sessions to be held at the Maryland DPSCS
facility. This will be coordinated with the Maryland DPSCS Project Manager.
PM.14 All documentation shall be delivered to the Maryland DPSCS in electronic format and
with a minimum of 5 bound hard copies.
PM.15 Office documents and/or reports shall be done using Microsoft Office 2000 or later (MS
Word, MS Excel, MS PowerPoint).
PM.16 Drawings and flowcharts shall be done using Microsoft Visio 2000 or later.
PM.17 Project schedules/plans shall be done using Microsoft Project 2000 or later.
PM.18 The vendor shall include all deliverables in the project schedule, with a Draft and Final
delivery date.
PM.19 The Project Management Plan shall at a minimum include: Project Description, Project
Development Strategy, Work Breakdown Structure, Project Schedule, Project Resources,
Acquisition Plan, Problem Resolution, Communication Plan, Standards, Security.
PM.21 The Project Schedule shall outline each key phase and associated deliverables.
Nortel Government Solutions Incorporated
42
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
PM.22 The Project Schedule shall outline all State assignments required to make the project
successful.
PM.23 The Communications Plan must outline weekly progress/status reporting.
PM.24 The Communications Plan must outline weekly progress/status meetings and meeting
minutes.
PM.25 The Communications Plan must outline all design review meetings and meeting minutes.
PM.26 The vendor shall not proceed with any activities in the Project Management Plan until the
Maryland DPSCS has approved the Project Management Plan.
PM.27 The vendor shall updated the Project Management Plan at each phase transition period
throughout the SDLC.
PM.28 The SEMP shall provide a top-level technical plan for the integration of all Maryland
state contracted systems.
PM.29 The SEMP at a minimum shall include: Detailed Scope definition, Contracted software,
hardware, Communications protocol information and System security and how it relates
to the engineering activities.
PM.30 The SEMP shall describe the management process necessary to ensure that all
components are fully compliant with all agreed upon requirements and standards.
PM.31 The Quality Assurance Plan shall outline the Quality Assurance methodology.
PM.32 The Quality Assurance Plan shall outline the Best Practices associated with implementing
a system of this magnitude.
PM.33 The Quality Assurance Plan shall outline the Procedures and tools that will be used to
ensure delivery of quality products to Maryland.
PM.34 The Quality Assurance Plan shall outline defined roles for the Maryland DPSCS relating
to the quality review of deliverables.
PM.35 The Sub-contract Management Plan shall flow down project requirements.
PM.36 The Sub-contract Management Plan shall flow down tools and procedures that will be
used to manage the sub-contractor(s).
PM.37 The Sub-contract Management Plan shall flow down approach to problem resolution.
PM.38 The Sub-contract Management Plan shall flow down corrective action approach for
missed deliverables.
PM.39 The Risk Management Plan shall describe the vendors approach to managing risk.
PM.40 The Risk Management Plan shall outline tools and procedures used to identify, assess,
mitigate and report risks throughout the project.
Nortel Government Solutions Incorporated
43
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
PM.41 The Risk Management Plan shall provide a risk priority assessment.
PM.42 The Requirements Traceability Matrix must support the development phases by
identifying the design document sections and software components that are associated
with each requirement.
PM.43 The Requirements Traceability Matrix must support the acceptance testing process by
identifying test cases associated with each requirement.
PM.44 The vendor shall prepare a Customer Factory Acceptance test plan to demonstrate each
component's compliance to the established requirements in the Requirements Traceability
Matrix.
PM.45 The vendor shall prepare a Unit Level Test Plan for each individual component
contracted. The test plan must outline each requirement in the Requirements Traceability
Matrix and the testing approach to verify compliance.
PM.46 The Vendor shall prepare an Integrated Systems Test Plan to outline each associated
requirement in the Requirements Traceability Matrix and the testing approach to verify
compliance.
PM.47 The Vendor must provide all internal testing documentation verifying quality control
within the organization prior to customer viewing.
PM.48 The Training Plan shall outline the objectives, needs strategy and curriculum to be
addressed during training for end users.
PM.49 The Training Plan will present the activities needed to support the development of
training materials, coordination of training schedules, reservation of personnel and
facilities, planning for training needs, and other training tasks that are necessary for the
implementation of the Replacement AFIS
PM.50 All training will be performed using both hands-on and document-based training
materials.
PM.51 Training documentation, at a minimum will include hardcopy user manuals, software
operational texts, and tutorial examples.
PM.52 To the extent possible, all such training materials should be made available to the State in
electronic format.
PM.53 The vendor shall grant the State permission to reproduce any and all training materials for
purposes of training State personnel on the proposed system.
PM.54 The Vendor shall coordinate the training schedules with the State 45 days prior to starting
any training.
PM.55 Training in MAFIS operations shall include all operating positions. Such positions shall
include Tenprint Operators, Quality Assurance Specialists, Latent Examiners,
Supervisors, System Administrators and support personnel.
Nortel Government Solutions Incorporated
44
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
PM.56 The vendor will be required to provide a transfer of knowledge regarding all technical
and administrative functions for the Transaction Controller, including, but not limited to
architecture, installation & configuration, security concepts, user definition and
maintenance.
PM.57 The vendor shall provide the following minimum numbers, outlined in Table 3.11.1 of
personnel/position training requirements upon system implementation.
PM.58 The vendor shall supply instructing personnel with training and experience on the
equipment supplied under these requirements, and all the necessary instructional
materials. All manuals, handouts, and other printed materials shall become the property
of the attendees.
PM.59 Where production data must be accessed, the vendor shall obtain prior approval from the
ITCD Project Authority.
PM.60 The vendor shall maintain a functional requirements document for the MAFIS
Replacement system, which includes the Transaction Controller, Fingerprint Archive,
Fast Identification and optional Mugphoto system.
PM.61 Vendor must support the required Minority Business Enterprise goals established for this
project.
PM.62 The Bidder must state in their proposal that they acknowledge that all Maryland photo
and fingerprint imaging data shall be the exclusive property of the State and that this data
will not be used for any purpose without the written permission of the State.
PM.63 Maryland criminal history and applicant information including friction ridge images may
not be transported outside the United States nor exposed to anyone other than State
approved vendor, contractor, or subcontractor personnel.
PM.64 There should be no substitution of vendor personnel named in the proposal without
permission from the State.
PM.65 The successful bidder's PM must have extensive background in the AFIS industry.
Table 3.11.1 Minimum Training Requirements
Section
AFIS
User Type
#of Personnel
Hours
Tenprint user
35
16
Tenprint
Supervisor
10
12
Tenprint
6
8
Latent User
30
16
Latent
Supervisor
10
8
Sys Admin
Latent
Nortel Government Solutions Incorporated
45
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
Latent
4
8
Archive User
40
4
Archive
Supervisor
15
8
Archive
6
8
Mugphoto
User
40
8
Mugphoto
Supervisor
15
8
Mugphoto
Sys Admin
6
8
Fast
20
4
Fast
Ident
Supervisor
5
8
Fast Ident Sys
Admin
6
8
TC
Supervisor
6
8
TC
System
Admin
4
8
Sys Admin
Archive
Sys Admin
Mugphoto
Fast
Identification
Transaction
Controller
4
Ident User
REQUIREMENTS TRACE ABILITY MATRIX
Not included
5
GLOSSARY
The following is a list of all acronyms used in this document.
ABS – Arrest Booking System
AFIS – Automated Fingerprint Identification System
ANSI – American National Standards Institute
CAR – Criminal Arrest Record
CCH –Computerized Criminal History System
CIRS – Centralized Image Repository System
Nortel Government Solutions Incorporated
46
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
CJIS CR – Criminal Justice Information System Central Repository
COTS – Commercial Off The Shelf
DPI – Dots Per Inch (printed resolution)
DOC – Division of Corrections
DPP – Division of Parole and Probation
DPS – Department of Juvenile Services
DPSCS – Maryland Department of Public Safety & Correctional Services
EFTS – Electronic Fingerprint Transmission Standard
FBI – Federal Bureau of Investigation
FDR – Fingerprint Data Router
GSP – Gateway Service Provider
IAFIS – Integrated Automated Fingerprint Identification System (FBI)
IQS – Image Quality Specifications
ITCD – Information Technology & Communications Division
III – Interstate Identification Index
IPS – Identification Processing System
JDBC – Java Database Connectivity
LAN – Local Area Network
Lights Out - System processing that determines identification of an individual without manual or
human intervention.
MAFIS – Maryland Automated Fingerprint Identification System
MSP – Maryland State Police
NFF – National Fingerprint File
NIST – National Institute of Standards and Technology
NLS – Network Livescan System
NOVARIS – Northern Virginia Regional Identification System
ODBC – Open Database Connectivity
ORI – Originating Agency Identifier
PCN – Process Control Number
PPI – Pixels Per Inch (digital resolution)
RAFIS – Regional Automated Fingerprint Identification System
RAP – Report of Arrest and Prosecution
RAS – Repository Administrative System
RDBMS – Relational Database Management System
SAN – Storage Area Network
Nortel Government Solutions Incorporated
47
January 23, 2006
Functional Requirements Document (Final)
Version 2.0
SRE – Submission Result – Electronic
SDLC – System Development Lifecycle
SID – State Identification Number
TP/TPID – Tenprint to Tenprint Identification
TDB – Temporary Database
TOT - Type Of Transaction
ULW – Universal Latent Workstation
VPN – Virtual Private Network
WAN – Wide Area Network
WSQ – Wavelet Scalar Quantization (image compression standard)
Nortel Government Solutions Incorporated
48
January 23, 2006