CADIS FRD 03092010.doc

ICE OCIO

CADIS Integrated Project Team Charter

ATTACHMENT 3

Department of Homeland Security

National Protective Programs Directorate (NPPD) Federal Protective Service (FPS)

Functional Requirements Document (FRD) for the

Computer Aided Dispatch Information System (CADIS)

Document Control

Information

Document History

Document Approval for Release

Director, FPS/SEVP IT Systems Branch

Table of Contents 51.0

INTRODUCTION

51.1 Automating the FPS MegaCenter dispatch operation:

51.2 Providing access to information and robust reporting functionality to FPS Law Enforcement Personnel

62.0 Assumptions

63.0 Constraints

74.0 Document References

85.0

FUNCTIONAL REQUIREMENTS

85.1 Standards Compliance

85.2 Alarm Monitoring

95.3 Arrest Information

95.4 Leo User Requirements

105.5 Call Receipt and Dispatch

105.6 Geospatial Information System Interface

125.7 Incident Tracking

135.8 Online Help Capabilities

135.9 Error Management

135.10 Investigative Case Management

145.11 Master Name Information

145.12 Special Events Information

155.13 System Administration Requirements

155.14 System Process and Functionality

165.15 Universal Clock

165.16 System Environment

165.17 User Interface

175.18 Reporting Requirements

185.19 Interfaces

195.20 Data Requirements and Management

205.21 Data Sharing

205.22 Data Retention

205.23 CADIS Deployment Considerations

216.0

OPERATIONAL REQUIREMENTS

216.1 Security

226.2 Audit Trail

226.3 Availability Requirements

226.4 Performance

227.0

PROFILES OF USER CLASSES

237.1 Criminal Investigations Supervisor

237.2 Reporting Personnel / FPS Personnel

247.3 Dispatcher

257.4 Dispatcher Supervisor

267.5 Call Taker

267.6 Alarm Monitor

277.7 Follow-up Personnel

277.8 Special Agent

287.9 Approving Authority

287.10 Records Manager

297.11 Document Release and Control Authority

297.12 Notification Authority

List of Tables

7Table 1 - Document References

23Table 2 - Criminal Investigations Supervisor

24Table 3 - Reporting Personnel / FPS Personnel

25Table 4 - Dispatcher

26Table 5 - Dispatcher Supervisor

26Table 6 - Call Taker

27Table 7 - Alarm Monitor

27Table 8 - Follow-up Personnel

28Table 9 - Special Agent

28Table 10 - Approving Authority

29Table 11 - Records Manager

Glossary

1.0 INTRODUCTION

The National Protection Programs Directorate (NPPD), Federal Protective Service (FPS) is responsible for providing security and law enforcement services for federal facilities. The role of Computer Aided Dispatch Information System (CADIS) is to support the FPS Law Enforcement Mission by:

1.1 Automating the FPS MegaCenter dispatch operation:

The MegaCenters are the vital communications link between FPS Law Enforcement Officers (LEOs), federal facilities, contract guards at the entrance to the facilities, and emergency responders, providing 24 –hour security alarm monitoring and dispatch functions.

Currently, FPS manages dispatches and incidents from four MegaCenters located in Denver, Colorado; Battle Creek, Michigan; Suitland, Maryland; and Philadelphia, Pennsylvania. This dispatch and incident response solution (Daily Operations Log) was originally developed to support mission needs in a non-automated process. The Government Accountability Office (GAO) and FPS have determined that the current infrastructure no longer meets organizational requirements and does not adequately support the FPS Mission in the following ways:

· Manual Processes where automation is available to enhance performance

· Unreliable and non-standardized data management between MegaCenters

· Lack of a Geographic Information System (GIS)

· Lack of performance measurement capabilities

· Limited emergency fail-over and load sharing capabilities

· Dependence on individuals with domain knowledge

1.2 Providing access to information and robust reporting functionality to FPS Law Enforcement Personnel

In order to eliminate the current deficiencies and to address the new law enforcement requirements, the proposed CADIS must replace the current Daily Operations Log (DOL) and Web Records Management (WebRMS) systems and include the following three components:

1) Computer aided dispatch

2) Records management

3) Geographic Information The proposed project is aligned with the DHS and FPS Strategic Plans:

· DHS Strategic Goal of “Strengthen Our Nation's Preparedness and Emergency Response Capabilities”.

· FPS Strategic Goal of “Collaborative Partnerships and Effective Communications and Efficient and Stakeholder-oriented Law Enforcement and Security Services”.

This Functional Requirements Document (FRD) is a formal statement of the proposed CADIS system’s capabilities in support of FPS.

2.0 Assumptions

The following assumptions are pertinent to the development and implementation of the CADIS application:

· CADIS shall replace the current Web-based Records Management System (WebRMS) and Daily Operations Log (DOL) systems.

· CADIS shall either be a single COTS product or a integration of different COTS modules.

· CADIS shall have the capability to interface with other DHS and government IT systems.

· CADIS shall provide a web service interface for remote systems/users using existing equipment.

· CADIS shall be purchased and fully implemented in a period spanning a period not to exceed 12 months ( including; installation, maintenance, testing, and training according to ICE System Lifecycle Methodology (SLM) and ICE investment planning/approval).

· CADIS shall follow the ICE SLM workpattern for COTS products.

· Application maintenance shall occur over the lifecycle of the CADIS system.

· CADIS shall address usability and accessibility requirements and incorporate industry best practices.

· CADIS shall be flexible, scalable, and adaptable to meet growing business needs and users.

· Personnel in the MegaCenters will dispatch all personnel.

3.0 Constraints

The following constraints are associated with the proposed system:

· The CADIS architecture must be scalable to support future FPS requirements.

· The COTS solution must adhere to DHS Enterprise Architecture standards.

· DHS/ICE network performance may limit the use of connectivity options that are available due to security concerns.

· The GIS module must interface with Economic and Social Research Institute (ESRI) Geospatial Information System (GIS) databases.

· DHS Geospatial Information System Compliance: All implementations shall comply with the policies and requirements set forth in the DHS Geospatial Information Infrastructure (GII), including (but not limited to) the following:

· The DHS geospatial data model shall be used building to the GII.

· All data within the GII, whether adopted or developed, shall be submitted to the DHS Enterprise Data Management Office (EDMO) for review and insertion into the DHS Data Reference Model.

· Peer to Peer Architecture is not permitted by DHS Architectural Guidelines, as specified in DHS Management Directive 4300A, version 7.

4.0 Document References

The following list of references was used in the development of this FRD.

Department of Justice/Bureau of Justice Assistance

Standard Functional Specifications for Law Enforcement Computer Aided Dispatch (CAD) System

Records Management Systems (RMS) www.leitsc.org

DHS Security Handbook http://www.dhs.gov/xlibrary/assets/privacy/privacy_guide_spii_handbook.pdf

Table 1 - Document References

5.0 FUNCTIONAL REQUIREMENTS

The functional requirements are functions or features that must be included in CADIS in order to meet the business needs and be acceptable to the system users. The functional requirements describe the proposed CADIS functionality. This section includes the data and functional process requirements for each identified functional area of the system.

5.1 Standards Compliance

5.1.1 The system shall be fully National Incident Based Reporting System (NIBRS) compliant

5.1.2 The system shall provide for the consolidation of data from multiple sources, checks for duplicate records, and create required NIBRS output, in the format and on the media specified by the Federal Bureau of Investigation (FBI)

5.1.3 The system shall provide data input modules to capture all required NIBRS elements from CADIS transactions or directly from the user entry in an application

5.1.4 Data in CADIS shall be validated upon entry against a list of authorized NIBRS data elements or values

5.1.5 The system shall adhere to Emergency Data Exchange Language (EDXL) communication standards

5.1.6 The system must be compliant with Section 508

5.2 Alarm Monitoring

5.2.1 The system shall provide the ability to track and identify alarms monitored through an interface with FPS Security Information System (SIS), an Underwriters Laboratories (UL) approved centralized alarm monitoring system. There will be an interface to SIS from each of the CADIS systems in the four MegaCenters. The number of alarm aggregation points is one per CADIS system. SIS provides the capability to automatically detect and export all alarm points to CADIS. SIS interface record formats will be defined in the functional requirements phase. No alarm filtering exists in SIS, all alarm filtering will be done in CADIS. WAN connectivity and bandwidth between the MegaCenters will be sufficient to support the alarm monitoring capabilities of the COTS product.

5.2.2 The system shall provide the ability to accept building numbers and information from SIS computerized alarm monitoring equipment and convert the data into text

5.2.3 Based on the building number received from SIS, the system shall provide the ability to populate CADIS’s alarm monitoring screen with building information (building contact, agencies, addresses, etc.) from data provided through a RAMP interface with CADIS.

5.2.4 The system shall be able to meet the current need to convert 7,400,000 alarm signals from SIS to the dispatch system, and be scalable to address future needs. The number of incidents generated from these alarm signals varies substantially based on the type of alarm, and the number of incidents cannot be predicted.

5.2.5 The system shall prioritize alarm alerts by type. There are ten alert levels, as defined by SIS.

5.2.6 The system shall allow the differentiation of alarms requiring a a local or FPS police response, fire response and Emergency Medical Services (EMS) response

5.3 Arrest Information

5.3.1 The system shall have the capability to add arrest information to new and existing records from other sources and look up criminal history (open warrants, citations, misdemeanors, etc). The additional sources to be interfaced will be defined during requirements definition, if interface C (NCIC) is awarded.

5.3.2 The system shall segregate adult information and cases, from those involving juveniles, as required by law

5.3.3 The system shall allow capturing and tracking of aliases and other information that requires multiple instances (for example, names, jobs or addresses)

5.3.4 The system shall provide standard word processing functions and capabilities for selected narrative and text fields. These capabilities shall include spell checking, word wrap, cut and paste, and find and replace.

5.4 Leo User Requirements 5.4.1 The system shall provide the ability to assign none, one or multiple LEOs to geographical locations (sector/beat/area); including post assignments. There are approximately 900 LEOs covering approximately 9,000 government facilities. Response assignments will be defined during system configuration.

5.4.2 The system shall provide the ability to search and review all activities of a specific LEO

5.4.3 The system shall provide the ability to assign none, one or multiple LEOs to an incident

5.4.4 The system shall provide the ability to alert dispatcher after a specified duration has elapsed since last communication with the LEO

5.4.5 The system shall provide the ability to search LEO information by partial string and/ or multiple fields

5.4.6 The system shall provide the ability to report LEO activity/history

5.4.7 The system shall provide the ability to assign on-duty LEOs

5.4.8 The system shall provide the ability to store LEO check-in information; including time of last check-in, duration to next check-in and status

5.4.9 The system shall provide the ability to track dispatch, arrival and completion date/times for each LEO assigned to incident

5.4.10 The system shall provide the ability to track travel mileage to and from the incident location for each LEO (using GIS)

5.4.11 The system shall provide the ability to store and update additional identifiable information about a LEO; including (but not limited to): assigned vehicle and radio call sign, in addition to customizable data fields for LEO information

5.5 Call Receipt and Dispatch 5.5.1 CADIS shall be able to dispatch from four FPS MegaCenters to any mobile user within the United States and its territories.

5.5.2 The system shall provide the capability to automatically populate the CADIS screen with building information from RAMP based on the building number, address or common name

5.5.3 The system shall provide a list of questions to ask the caller, based on the type of incident. The list may be modified at the request of the user (e.g., if a caller requests help for a shooting, the dispatcher may ask if medical assistance is required or if the perpetrator fled). Emergency Medical Dispatch is not required.

5.4 Geospatial Information System Interface

5.6.1 The GIS system shall have Automatic Vehicle Locator (AVL) modules and provide the ability to link with AVL equipment in cars. The AVL system has not been defined, nor does it exist in FPS vehicles. However, whichever AVL solution is selected will meet requirements of the selected COTS product. The system shall use geospatial information to display relevant neighborhood information, improve routing, and track vehicles. FPS does not currently have GPS Vehicle Location devices but anticipates this integration as a future capability.

5.6.2 The system shall automatically determine the geographic location of a vehicle and transmit the information to a dispatcher

5.6.3 The system shall provide the ability to display vehicles nearest to a given location 5.6.4 The system shall provide the ability to display premises information from GIS that falls within range of a given location (e.g. allows operator to locate hazardous materials, floor plans, evacuation plans, etc. within proximity of a given location)

5.6.5 The system shall provide playback capability to recreate fleet movements for dispatchers, administrative and supervisory review. Playback retention shall be provided within the limits of the COTS product.

5.6.6 The system shall have the ability to integrate with wireless radio infrastructures for messaging using the APCO-25 standards. This requirement is necessary for planned future capability. The interface between the existing P25 wireless radio system and CADIS will be defined during system requirements.

5.6.7 The system shall show real time tracking, the exact location visited by a vehicle, how long it was there, speeds en route and the time the vehicle left each location. The tracking shall be performed as part of the GPS/AVL system that will be deployed at a future date.

5.6.8 The system shall have the capability to add/input map layers

5.6.9 The system shall provide zoom in and out capabilities and map layers

5.6.10 The system shall provide look up capabilities for all coded screen entries, emergency contact and hazard information, map information and building schematics and/ or NIBRS codes

5.6.11 The system shall allow users to enter multiple instances of all fields - names, addresses, and phone numbers. For example, if a suspect uses more than one name, the system should allow input for each of the names the suspect uses

5.6.12 The system shall provide a method for displaying valid activity codes based on partial string entry by user (input process for initial call entry or dispatch)

5.6.13 The system shall allow key fields on screen to FLASH in different color or style to indicate an alert (e.g., individual has a history of violence or weapons possession)

5.6.14 The system shall provide situation reports and notifications for customer-defined (types) incidents to other offices based on type and priority of call (bomb threats, hostage situations, fire)

5.6.15 The system shall provide the ability to send dispatch and pre-arrival instructions to LEOs

5.6.16 The system shall provide to the user pertinent information to notify other Federal Law Enforcement Agencies located in buildings involved in an incident

5.6.17 Based on user defined rules, the system shall provide the ability to recommend units for dispatch based on the type of call and location of the incident

5.6.18 The system shall provide the ability to display the current status of all active units

5.6.19 The system shall identify standard procedures for each call type, as defined by the user

5.6.20 The system shall provide the ability to report multiple incidents that occur at the same location, at the same time in one incident report

5.6.21 The system shall provide the ability to communicate between the dispatcher and the LEO, and other logged on users.

5.6.22 The system shall provide the ability to access local responder information through a building information database provided by the Risk Assessment and Management Program (RAMP)

5.6.23 The system shall provide the capability to identify when notification of, or coordination with other agencies is necessary, and retain a record of when such coordination or notification has been made

5.6.24 The system shall provide a cross reference link to suspicious vehicles, persons, or incidents using license plates numbers or VIN

5.6.25 The system shall provide access to information on all citations issued by FPS and other agencies

5.5 Incident Tracking

5.7.1 The system shall provide the ability to enter information, including LEO initiated “police reports" directly into the RMS from remote sites (field reporting) using desk top computers, laptop computers and Mobile Computing Devices (MCDs). Electronic copies of paper forms will not be required. Data entry fields will provide direct input into the RMS component of CADIS. Reports generated from that RMS component will comply with FPS requirements, which will be defined in the requirements definition phase.

5.7.2 The system shall provide the ability to flag incidents that require investigative follow up

5.7.3 The system shall provide a method of identifying individual reports written for an incident

5.7.4 The system shall check for duplicate names and display choices for user selection or allow new entry

5.7.5 The system shall provide the ability to cross check against the dispatcher's incident number record to determine if an associated case control record exist

5.7.6 The system shall allow for routing reports to one or more approving authorities and log report approval, disapproval, or changes

5.7.7 The system shall be able to "lock" an incident or case report (i.e. no further changes can be made to the report) once it has been approved

5.7.8 The system shall provide the capability for information from a GIS to populate the forms to the maximum extent possible

5.7.9 The system shall provide electronic signature capabilities to sign off on reports

5.7.10 The system shall not allow modifications to the original incident file

5.7.11 The system shall be able to create a supplement/follow-up incident report

5.7.12 The system shall provide the capability to indicate the status of a report or case (with categories)

5.6 Online Help Capabilities

5.8.1 The system shall provide online user documentation including tutorials for each component

5.8.2 The system shall provide the ability to print the help system information

5.8.3 The system shall provide a help system that can be updated by the system administrator

5.8.4 The system shall provide a help system that supports keyword searches

5.8.5 The system shall provide the ability for the help system to access a list of frequently asked questions

5.8.6 The system shall provide context-sensitive on line help capabilities at the field, module, and application level; help includes error messages, corrective actions, field description, hypertext links, and field or screen function

5.7 Error Management

5.9.1 The system shall have the ability to log errors to an error log

5.9.2 The system shall provide the user with an error message on the screen when an error occurs, describing the error and whenever possible providing corrective actions

5.9.3 The system shall provide the ability to notify users when requests have been aborted due to an application failure when running queries and/or on-line reports

5.9.4 The system shall provide the capability to retain erroneous transactions in the application until they are corrected or deleted

5.8 Investigative Case Management

5.10.1 The system shall configure the case number to user specification or standard and automatically assign it

5.10.2 The system shall give users the ability to reopen or close cases based on user access levels

5.10.3 The system shall be able to list all investigations in progress (open) using a standard query and report

5.10.4 The system shall list all cases that currently require follow-up as of a specified date

5.10.5 The system shall ensure that the case number generated in CADIS is the key field for accessing a case for case management information

5.10.6 The system shall maintain a history of all LEOs and investigators ever assigned to a case (by name, date, and number)

5.10.7 The system shall allow supervisors the ability to add additional review dates without deleting the previous review dates for a case

5.10.8 The system shall maintain a history/log of all review dates by case

5.10.9 The system shall allow users the ability to inquire, change, and delete specific actions on a case prior to final approval

5.10.10 The system shall allow users the ability to relate multiple cases to a single master case

5.10.11 The system shall provide the ability to indicate if another law enforcement agency has the primary responsibility for NIBRS reporting purposes (e.g. local police department reports rather than FPS)

5.10.12 The system shall provide a listing of cases that have been assigned for investigation with status and due dates

5.10.13 Based on user defined business rules, the system shall allow reports to be "sanitized" prior to release and log requestors' name, phone, and date report was released

5.10.14 The system shall provide multiple possible statuses for a case (example: closed, open-complete, open-incomplete)

5.9 Master Name Information

5.11.1 The system shall have the capability to pull all related offenses committed by a suspect/offender, by name

5.11.2 The system shall link incident/case report number to Master Name Information

5.11.3 The system shall allow for indicator flags (medical/criminal/warrant status) linked to the Master Name files

5.11.4 The system shall have the ability to search and present similar names, based on parameters such as contains, misspelling, etc.

5.10 Special Events Information

5.12.1 Dispatcher shall be able to enter Special Events in real time for reference by other dispatchers and personnel prior to the event’s date and time

5.12.2 The system shall provide users the special event notification including: date, time, and duration. Sample types of special events: street closings, demonstrations, Very Important Persons (VIP) visits, threats & warnings, Federal Emergency Management Agency (FEMA) Mission Assignments, Deployment of the Critical Incident Response Team

5.12.3 The system shall provide the user notification of National Special Security Events (NSSEs) or Incidents of National Significance

5.12.4 The system shall provide the ability to access a calendar to allow for event scheduling, reviewing planned activities, etc.

5.11 System Administration Requirements

5.13.1 The system shall provide the ability to distribute upgrades to remote sites from a central location via Big Fix or other ICE Application or approved method (Peer to Peer Architecture is not permitted by DHS architectural standards)

5.13.2 The software shall have a unique version identification number for each release

5.13.3 The system shall provide product upgrade and rollback support by separating and isolating version changes

5.13.4 The vendor shall provide documentation with each release specifying changes made to application and data structures

5.13.5 The vendor shall provide disaster recovery plan and capabilities

5.13.6 The system shall provide ability to schedule routine system activity (backups, updates, standard reports, and archiving)

5.13.7 The system shall provide the ability to create new user logon IDs with group security access

5.13.8 The system shall provide the ability to add/update dispatcher information

5.13.9 The system shall provide the ability to search and review all activities of a specific Dispatcher

5.13.10 The system shall provide the ability to assign a dispatcher to an incident

5.13.11 The system shall provide the ability to assign multiple access levels or permissions to customize allowable activities for dispatcher, supervisors and system administrators

5.13.12 The system shall allow authorized system administrators the ability to add or delete users in "real-time"

15.13.13 The system shall have the ability to store updates on the local machine if connectivity is lost and resume updates once reconnected.

5.12 System Process and Functionality

5.14.1 The system shall provide the user the ability to query CADIS incident status 5.14.2 The system shall provide review of workflow or transaction status at all levels (individual transactions to organizational processes), and detail how often, how long and at what interval similar transactions occur

5.14.3 The system shall allow users to escalate transaction priority, which will be defined during the requirements definition phase.

5.14.4 The system shall allow for workload balancing between different MegaCenters

5.14.5 The system shall be configurable to support end-user defined workflows that are available within the COTS product.

5.14.6 The system shall provide the capability to assign priorities to transactions depending on the performance requirements that are desired

5.14.7 The system shall allow for multiple tasks to take place without disputing dispatch and reporting capabilities (i.e. if a lengthy query is being run, this should not slow down other system operations)

5.15 Universal Clock 5.15.1 The system shall provide the ability to work with and display a standard, system wide clock, for establishing baseline times (e.g., Coordinated Universal Time (UTC)

5.15.2 The system shall be capable of identifying and maintaining accurate local time for dispatching and incident reporting across different time zones (from a centralized dispatch office)

5.13 System Environment

5.16.1 The system shall be hosted at two facilities: Primary and Back-up (Currently, the Suitland, Maryland MegaCenter is planned to be the Primary Site and the Battle Creek, Michigan MegaCenter is planned to be the back-up site)

5.16.2 The data shall be replicated between the two MegaCenters. The network will provide sufficient capability to transfer this data in real time.

5.16.3 The system shall provide seamless transition from primary dispatch center and backup center in the event of a catastrophic or technical failure

5.16.4 The system shall provide for automatic synchronization of databases in all locations

5.17 User Interface 5.17.1 The system shall be configurable to select data and data layout of the information presented on a screen

5.17.2 The system shall be able to auto-populate data elements wherever possible

5.17.3 The system shall provide the ability to handle standard and user defined hot key shortcuts (via keyboard) for commonly used actions

5.17.4 The system shall provide a consistent Graphical User Interface (GUI) look and feel across the entire product line. The GUI look and feel will be determined by the capabilities of the COTS product. All screens should be existant in the product being proposed.

5.17.5 The system shall be accessible through web enabled devices

5.17.6 The system shall provide the capability to use "pick lists" for optional entries for fields where the user has predefined choices

5.17.7 The system shall provide the common capability to enter a report or other information directly into an application through a CADIS Terminal, desk top computer, laptop or touch screen tablet

5.17.8 Telecommunications Device for the Deaf (TDD) and Text Telephone (TTY) for calls for service. Each facility utilizes its own phone system. Interface requirements will be defined during requirements definition phase. Some existing phone systems are Meridian and Avaya.

5.17.9 The system shall prioritize alarm alert type indicated by color and/or audio signal

5.17.10 The system shall be capable of accessing internet enabled closed circuit televisions. This is considered a future capability, not to be bid on at this time.

5.18 Reporting Requirements 5.18.1 The system shall provide the ability to create reports linked to the specific time zone in which the incident occurred and display UTC.

5.18.2 CADIS shall be able to produce and save ad-hoc reports

5.18.3 The system shall provide the ability to create and send situation reports for a specific incident. The report will be based on the requirements definition phase.

5.18.4 The system shall provide the ability to create and send incident summary reports for a specific date/time range

5.18.5 The system shall provide the ability to send incident information to LEOs

5.18.6 The system shall provide the ability to report all incidents, at a minimum, for a specific location, agency, activity code, incident type, date/time range

5.18.7 The system shall provide the ability to create and e-mail incident information to a predefined list of user type based on business rules that identify the type of information that can be reported

5.18.8 The system shall provide the ability to perform statistical analyses and identify trends and patterns in all reported incidents across all NIBRS codes based on factors including geographic location, facility security level, and others

5.18.9 The system shall limit a user’s ability to print reports based on defined use access level

5.18.10 The system shall provide the capability to create, manage, and maintain ad-hoc queries

5.18.11 The system shall provide the capability to create custom forms, queries, and report definitions

5.18.12 The system shall provide the ability to export data in different formats, such as Excel, Extensible Markup Language (XML), TXT, etc

5.18.13 The system shall provide the capabilities to electronically forward RMS data to external data sources based on agency rules embedded within the system.

5.18.14 The system shall provide the ability for queried data to be viewable on screen, able to be sent to a printer or saved to a file

5.19 Interfaces

5.19.1 CADIS shall be NIBRS compliant:

NIBRS - CADIS provides data input modules to capture all required NIBRS information from CADIS transactions or directly from the user entry in an application. The CADIS components determine the agency responsible for reporting the crime. If FPS is responsible for reporting the data, the CADIS provides for the consolidation of data from multiple sources, checks for duplicate records, and creates required NIBRS output, in the format and on the media specified by the FBI.

5.19.2 CADIS shall have the capability to build interfaces to the following systems:

· NCIC (National Crime Information Center)- Provides a computerized database for ready access by a criminal justice agency making an inquiry and for prompt disclosure of information in the system from other criminal justice agencies about crimes and criminals

· NLETS (National Law Enforcement Telecommunication System) – warehouses data such as motor vehicle registrations, driver’s data, Interpol warrants, and ICE Services databases in addition to state and local databases for wants, warrants, and criminal history

· SIS (Security Information System) – FPS’ central station for automatic alarm monitoring – automated security management and alarm monitoring system. CADIS will consolidate, geographically and functionally, alarm inputs, the dispatch decision-making and recordkeeping sites, and dispatch communications hub.

· RAMP (Risk Assessment and Management Program) – FPS’ centralized source of information used by FPS for risk assessment and management including all information on federal facilities, contact information, and much more.

· ICEPIC (Immigration and Customs Enforcement Pattern Analysis and Information Collection System) - allows DHS LEOs access to multiple law enforcement databases.

· DHS/ICE Geospatial Database - provides local base map and map layer data access for use by the CADIS system in the ESRI format. Dispatchers will require access to all maps, and LEOs will require access to regional and local maps. The ESRI toolsets in use will be defined during requirements definition phase. The Geodatabase will be split into subsections.

5.19.3 CADIS shall have the capability to build future interfaces to systems or organizations (internal systems):

· FPS Post Tracking System (PTS) - an automated guard post time tracking system. This is a future requirement.

· The system shall be upgradable to E-911 capability. This is a future requirement.

5.20 Data Requirements and Management 5.20.1 The system shall provide the capabilities to manage and maintain data concurrency and redundancy in two environments that uses a replicated architecture

5.20.2 The system shall provide the capabilities to manage and maintain data concurrency in a architecture where a server manages information pertinent for each of four locations separately but is accessible by the entire user community

5.20.3 The system shall provide fail-over capabilities allowing another MegaCenter to assume the processing for a failed location

5.20.4 The system shall provide a Data Base Management System (DBMS) enforced referential integrity for all stored information

5.20.5 The system shall provide the ability to integrate the data dictionary with other functions such as help, query, and field selection

5.20.6 The system shall provide capabilities to manage, maintain, and print the data dictionary

5.20.7 The system shall provide the capability to add data elements when necessary (for data management, control, internal and external reporting requirements) based on user access level

5.20.8 The system shall provide the ability to define “user-defined” fields. User-defined fields can be configured for a specific data element as part of an incident record

5.20.9 The system shall provide the ability to store/add/update NIBRS codes to define incident types

5.20.10 The system shall provide the ability to store media including pictures, voice recordings, and scanned files The system shall provide the ability to store arrest information; including personal suspect data

5.20.11 The system shall provide the capability to resolve conflicts where two or more people attempt to access the same record

5.20.12 The system shall provide the capability to periodically purge selected data

5.20.13 The system shall provide the ability to expunge files (in the rare case of court orders, etc.)

5.20.14 The system shall provide the common capability to add or delete field contents, or to modify existing fields based on user access levels

5.20.15 The system shall provide the ability to search all data elements by partial string

5.20.16 The system shall provide the ability to import data from a variety of database systems and, including but not limited to, ORACLE, MS SQL Server, Informix, and American Standard Code for Information Interchange (ASCII) delimited files

5.21 Data Sharing 5.21.1 The system shall provide workflow integration with other workflow products (i.e., MS Office, MS Outlook, SharePoint, etc.)

5.21.2 The system shall provide support for custom processes that interface with external applications using the EDXL standards

5.21.3 The system shall be able to communicate with current applications in addition to new applications being developed, and provide shared access to data, data operations, and methods under appropriate security, integrity, and access control mechanisms

5.21.4 The system shall access read only building information data from RAMP or other DHS systems

5.22 Data Retention 5.22.1 Dispatch reports, incident records, and case reports shall be maintained indefinitely

5.22.2 The system shall provide the ability to archive and restore data. Any active records shall be indefinitely available, anything that has a disposition or is closed, minimum 12 months.

5.22.3 The system shall provide the ability to archive and restore subsets of data

5.22.4 The system shall provide access to archived data for reporting purposes

5.22.5 The system shall provide search, read and view capabilities on archived data

5.22.6 The system shall provide the ability to schedule automatic archival processing of records 5.23 CADIS Deployment Considerations 5.23.1 The Contractor shall be aware of the following consideration as it relates to the deployment of CADIS:

5.23.2 The CADIS servers and system shall be completely installed, tested, implemented, and operational for at least three months in the four FPS MegaCenters, prior to deploying to MCD users.

5.23.3 All dispatch and system administrator users shall be trained prior to operational implementation of the system.

5.23.4 Geographic locations of clients:

· Dispatch clients are located in the MegaCenters in Denver, Colorado; Battle Creek, Michigan; Suitland, Maryland; and Philadelphia, Pennsylvania. All workstations are considered GFE.

· Regional/Reporting Clients, including mobile and desktop users, are located nationwide but organized into eleven regions plus the Headquarters office in Washington, DC.

5.23.5 All clients, stationery and mobile, shall have the ability to install the required software, upgrades and patches using the existing DHS network and Big Fix utilities. Follow up with individual users for completion of installation will be accomplished by Help Desk personnel.

· Mobile Computing Devices (MCDs):

· The appropriate software shall be installed and configured on existing mobile computing devices used by the law enforcement users. MCD specifications will be provided as an attachment to this SOW. Deployment to MCDs is to occur no sooner than three months after successful implementation of the system in the MegaCenters. All LEO users shall be trained prior to distribution and implementation of the system to desktop and mobile computers.

5.23.6 The system shall have the capability to integrate alarm location, floor plans and building data, using the ESRI standard; however this capability will be explored during a later phase of implementation.

6.0

OPERATIONAL REQUIREMENTS

Operational requirements describe the non-business characteristics of an operation. This section is included in the FRD to support the functional requirements.

6.1 Security

6.1.1 The system shall meet the requirements in the MD4300-A handbook

6.1.2 CADIS shall not be designed to handle information marked at the “CLASSIFIED” level.

6.1.3 The system shall adhere to the Information Access Division (IAD) standards for advance technologies dealing with access to multimedia and other complex information

6.2 Audit Trail

6.2.1 The system shall have an audit trail record that specifies: the type of event and its result, when the event occurred, the User ID associated with the event and the program or command used to initiate the event

6.2.2 The system shall have an "audit trail" function that can be queried by User ID, Terminal ID, date, time or other set of parameters to run reports of selected information.

6.2.3 The system shall provide the ability to identify the most current modification of a report (require access level)

6.2.4 The system shall provide an audit trail (times/dates/identities of who accessed or updated a report or case file)

6.3 Availability Requirements

6.3.1 At minimum, availability requirements for CADIS shall be 99.999% (five nines) uptime. ‘Five nines’ refers to 99.999% availability, which translates to a total downtime of approximately five minutes and fifteen seconds per year. This availability requirement applies both to dispatch capabilities and record management components. There is no requirement for offline capability for dispatch functions. Dispatch functions must be available online in the primary location or the backup location.

6.4 Performance

6.4.1 The CADIS application shall satisfy the following performance requirements:

6.4.2 The system shall be able to support the specified workload and 90% of all transaction processing transmissions shall take < 3 seconds

6.4.3 The system shall process 90% of defined report transactions in less than 60 seconds based on current canned reports provided in the COTS product.

6.4.4 The system shall provide performance statistics for the system that shows process and various query response times for the above specified workload

6.4.5 The system shall provide sub-second response time for screen traverse and field validation

6.4.6 The system shall be able to support 600 concurrent users

6.4.7 The system shall be able to process over 125,000 dispatch calls a year and over 7,400,000 alarm alerts per year.

7.0 PROFILES OF USER CLASSES

The following sections identify the roles in each user class and the system functionality(s) associated with each role. These are preliminary / notional scenarios, subject to change with revised Standard Operating Procedures (SOPs) with the new system. All RMS access should be web based. Access to the RMS will be defined through user roles during requirements definition. Further details shall be provided during requirements gathering:

7.1 Criminal Investigations Supervisor

The Criminal Investigations Supervisor reviews and directs activities of personnel assigned to incident investigations, and allocates resources. This FPS user class will have access to CADIS, be able to review incident information, update incident information, and close investigations.

2. Provide a method to display cases by attributes (opened, opened incomplete, closed etc)

2. Allow information to be updated

Table 2 - Criminal Investigations Supervisor

7.2 Reporting Personnel / FPS Personnel

The Reporting Personnel / FPS Personnel collect facts and prepare the report for the preliminary (original) incident report. This individual is one of the responding LEO's and participates in observation activities, analytic activities, interpersonal communications, and written communications.

2. Provide a method to display cases by attributes (opened, opened incomplete, closed etc)

Table 3 - Reporting Personnel / FPS Personnel

7.3 Dispatcher

The Dispatcher receives requests for service and sends Responding LEO(s) or contract guard to scene of incidents. The Dispatcher determines which LEO to dispatch based on location, availability, or at supervisor’s discretion; collects and distributes background and amplifying information from various sources; and monitors incident status and activity based on threat level. The Dispatcher relays information between distant locations, acts as a liaison with local authorities, and maintains LEO availability status.

2. Display the status of the LEO’s

3. Display building information

4. Display information collected by the call takers/alarm monitors

2. Provide status and location of LEOs

3. Provide the dispatcher GIS information

4. Provide information from other agencies via interfaces.

2. Change the status of the incident to closed

2. The time of the expected arrival is reserved

3. Update incident record with the person dispatched

4. Allows the dispatcher to set a time to contact the LEO dispatched

5. Provide Traffic information

6. Provide directions

2. Copies information from incident record to case record

2. Updates the case record with the public safety agency dispatched

3. Provides information as to who is responsible for NIBRS reporting.

Table 4 - Dispatcher

7.4 Dispatcher Supervisor

The Dispatcher Supervisor reviews and directs activities of dispatchers. Assigns dispatchers to incident, and allocates resources.