14. FRD_2009_11 03a.doc

ICE OCIO

CADIS Integrated Project Team Charter

ATTACHMENT 3

Department of Homeland Security

Immigration and Customs Enforcement

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 11.0

INTRODUCTION

21.1 Assumptions

21.2 Constraints

31.3 Document References

42.0 Functional Requirements

52.1

STANDARDS COMPLIANCE

52.2

ALARM MONITORING

62.3

ARREST INFORMATION

72.4

LEO USER REQUIREMENTS

82.5

CALL RECEIPT AND DISPATCH

102.6

INCIDENT TRACKING

112.7

ONLINE HELP CAPABILITIES

112.8

ERROR MANAGEMENT

122.9

INVESTIGATIVE CASE MANAGEMENT

122.10

MASTER NAME INFORMATION

142.11

SPECIAL EVENTS INFORMATION

142.12

SYSTEM ADMINISTRATION REQUIREMENTS

152.13

SYSTEM PROCESS AND FUNCTIONALITY

152.14

UNIVERSAL CLOCK

152.15

SYSTEM ENVIROMENT

162.16

USER INTERFACE

162.17

REPORTING REQUIREMENTS

172.18

INTERFACES

192.19

DATA REQUIREMENTS AND MANAGEMENT

202.20

DATA SHARING

202.21

DATA RETENTION

203.0 Operational requirements

213.1 Security

213.2 Audit Trail

213.3 Availability Requirements

223.4 Performance

224.0

LEO PROFILES OF USER CLASSES

224.1 Criminal Investigations Supervisor

234.2 Reporting Personnel / FPS Personnel

244.3 Dispatcher

254.4 Dispatcher Supervisor

264.5 Call Taker

264.6 Alarm Monitor

274.7 Follow-up Personnel

274.8 Special Agent

284.9 Approving Authority

284.10 Records Manager

294.11 Document Release and Control Authority

294.12 Notification Authority

List of Tables

3Table 1 - Document References

23Table 2 - Criminal Investigations Supervisor

23Table 3 - Reporting Personnel / FPS Personnel

25Table 4 - Dispatcher

25Table 5 - Dispatcher Supervisor

26Table 6 - Call Taker

27Table 7 - Alarm Monitor

27Table 8 - Follow-up Personnel

28Table 9 - Special Agent

28Table 10 - Approving Authority

28Table 11 - Records Manager

Glossary

1.0 INTRODUCTION

The Immigration and Customs Enforcement (ICE), 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:

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

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 (CAD) System

2) Records Management System (RMS)

3) Geographic Information System (GIS)

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.

1.1 Assumptions

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

· CADIS shall replace the current WebRMS and 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 approximately 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 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

· The MegaCenters will dispatch all personnel

1.2 Constraints

The following constraints are associated with the proposed system:

· CADIS’ architecture must be scalable to support future FPS requirements

· Any 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 ESRI databases

· Peer to Peer Architecture is not permitted by DHS Architectural Guidelines

1.3 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

2.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 will describe the proposed CADIS functionality. This section includes the data and functional process requirements for each identified functional area of the system.

2.1 STANDARDS COMPLIANCE

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

2.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)

2.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

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

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

2.1.6 The system must be compliant with Section 508

2.2 ALARM MONITORING

2.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

2.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

2.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.

2.2.4 The system shall be able to meet the current need to convert 7,400,000 alarms from SIS to the dispatch system, and be scalable to address future needs.

2.2.5 The system shall prioritize alarm alerts by type

2.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

2.3 ARREST INFORMATION

2.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)

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

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

2.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.

2.4 LEO USER REQUIREMENTS

2.4.1 The system shall provide the ability to assign none, one or multiple LEOs to geographical locations (sector/beat/area); including post assignments

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

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

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

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

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

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

2.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

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

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

2.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

2.5 CALL RECEIPT AND DISPATCH

2.5.1 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

2.5.2 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).

2.5.3 The GIS system shall have Automatic Vehicle Locator (AVL) modules and provide the ability to link with AVL equipment in cars

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

2.5.5 The system shall provide the ability to display vehicles nearest to a given location

2.5.6 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)

2.5.7 The system shall provide playback capability to recreate fleet movements

2.5.8 The system shall have the ability to integrate with wireless radio infrastructures for messaging using the APCO-25 standards

2.5.9 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

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

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

2.5.12 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

2.5.13 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

2.5.14 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)

2.5.15 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)

2.5.16 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)

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

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

2.5.19 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

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

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

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

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

2.5.24 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)

2.5.25 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

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

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

2.6 INCIDENT TRACKING

2.6.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)

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

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

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

2.6.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

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

2.6.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

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

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

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

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

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

2.7 ONLINE HELP CAPABILITIES

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

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

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

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

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

2.7.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

2.8 ERROR MANAGEMENT

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

2.8.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

2.8.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

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

2.9 INVESTIGATIVE CASE MANAGEMENT

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

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

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

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

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

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

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

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

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

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

2.9.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)

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

2.9.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

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

2.10 MASTER NAME INFORMATION

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

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

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

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

2.11 SPECIAL EVENTS INFORMATION

2.11.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

2.11.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

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

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

2.12 SYSTEM ADMINISTRATION REQUIREMENTS

2.12.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)

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

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

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

2.12.5 The vendor shall provide disaster recovery plan and capabilities

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

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

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

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

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

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

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

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

2.13 SYSTEM PROCESS AND FUNCTIONALITY

2.13.1 The system shall provide the user the ability to query workflow status

2.13.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

2.13.3 The system shall allow users to escalate transaction priority

2.13.4 The system shall allow for workload balancing between different MegaCenters

2.13.5 The system shall be configurable to support end-user defined workflow

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

2.13.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)

2.14 UNIVERSAL CLOCK

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

2.14.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)

2.15 SYSTEM ENVIROMENT

2.15.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)

2.15.2 The data shall be replicated between the two MegaCenters

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

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

2.16 USER INTERFACE

2.16.1 The system shall be configurable to select data and data layout of the information presented on a screen

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

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

2.16.4 The system shall provide a consistent Graphical User Interface (GUI) look and feel across the entire product line

2.16.5 The system shall be accessible through web enabled devices

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

2.16.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

2.16.8 Telecommunications Device for the Deaf (TDD) and Text Telephone (TTY) for calls for service

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

2.16.10 The system shall be capable of accessing internet enabled closed circuit televisions

2.17 REPORTING REQUIREMENTS

2.17.1 The system shall provide the ability to create reports using a specific time zone

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

2.17.3 The system shall provide the ability to create and send situation reports for a specific incident

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

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

2.17.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

2.17.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

2.17.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

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

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

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

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

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

2.17.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

2.18 INTERFACES

2.18.1 CADIS shall have the capability to build interfaces to the following system:

2.18.1.1 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.

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

2.18.2.1 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

2.18.2.2 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

2.18.2.3 SIS (Security Information System) – FPS’ central station for automatic alarm monitoring – automated security management and alarm monitoring system

2.18.2.4 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.

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

2.18.2.6 DHS/ICE Geospatial Database - provides local base map and map layer data access for use by the CADIS system in the ESRI format

2.18.2.7 State Crime Information Center - In addition to NCIC, CADIS shall provide the same interface functionality of NCIC for each state’s Crime Information Center within every state jurisdiction that CADIS is deployed.

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

2.18.3.1 FPS Post Tracking System (PTS) - an automated guard post time tracking system

2.18.3.2 The system shall be upgradable to E-911 capability

2.19 DATA REQUIREMENTS AND MANAGEMENT

2.19.1 The system shall provide the capabilities to manage and maintain data concurrency and redundancy in two environments that uses a replicated architecture

2.19.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

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

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

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

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

2.19.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

2.19.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

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

2.19.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

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

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

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

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

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

2.19.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

2.20 DATA SHARING

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

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

2.20.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

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

2.21 DATA RETENTION

2.21.1 Dispatch reports, incident records, and case reports shall be maintained indefinitely

2.21.2 The system shall provide the ability to archive and restore data

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

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

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

2.21.6 The system shall provide the ability to schedule automatic archival processing of records

3.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.

3.1 Security

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

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

3.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

3.2 Audit Trail

3.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

3.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.

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

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

3.3 Availability Requirements

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.

3.4 Performance

The CADIS application shall satisfy the following performance requirements:

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

3.4.2 The system shall process 90% of defined report transactions in less than 60 seconds

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

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

3.4.5 The system shall be able to support 600 concurrent users

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

4.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. Further details shall be provided during requirements gathering:

4.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

4.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

4.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 weather information

7. 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

4.4 Dispatcher Supervisor

The Dispatcher Supervisor reviews and directs activities of dispatchers. Assigns dispatchers to incident, and allocates resources. This FPS employee will have access to CADIS, be able to review incident information, update incident information, but, not to close investigations.

2. CADIS provide a list of the incident active for each dispatcher for a prior of time.

1. Provide a screen that displays all dispatch activity.

2. Provide audit trail information.

Table 5 - Dispatcher Supervisor

4.5 Call Taker

(This may or may not be the same person as the dispatcher)

The Call Taker receives notification of incident and initiates law enforcement response. The Call Taker is responsible for gathering information, prioritizing incoming events, initiating incident tracking and distributing data to authorities.

2. Provide call history for building

2. Display building information

3. Verify address input

4. Assign sequence number

2. Closes incident

2. Assigns case number

3. Automatically transfer all information collected by call taker to dispatcher

Table 6 - Call Taker

4.6 Alarm Monitor

(This may or may not be the same person as the dispatcher)

The Alarm Monitor receives notification of alarm activation and initiates law enforcement response. This Alarm Monitor is responsible for gathering information, prioritizing incoming events, initiating incident tracking, and distributing information to authorities.

2. Display alarm text on screen

3. Save information

2. Display building information

3. Verify address

4. Assign sequence number

2. Closes incident

2. Assigns case number

3. Automatically transfer all information collected by call taker to dispatcher

Table 7 - Alarm Monitor

4.7 Follow-up Personnel

Follow-up Personnel performs additional fact finding based on Case Report. The Follow-up Personnel conducts fact finding, documents information collection, and submits reports.

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

Table 8 - Follow-up Personnel

4.8 Special Agent

The Special Agent responsible for fact finding and analysis of case information in support of law enforcement. The Special Agent is provides in depth investigative services in support of adjudication, on or off General Services Administration (GSA) property; conducts fact finding; analyzes facts; prepares summaries of information collected and conclusions of analysis; prepares transmittal form(s); obtains and executes warrants; arrests subjects; and testifies in court.

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

Table 9 - Special Agent

4.9 Approving Authority

The Approving Authority performs checks for accuracy and completeness of submitted reports and determines the need for follow-up or supplemental reports, and approves reports.

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

Table 10 - Approving Authority

4.10 Records Manager

The Records Manager performs checks for accuracy and completeness of submitted reports, and maintains hardcopy reports (archive). The Records Manager’s duties include reviewing approved written reports, filing reports in archives, retrieving written reports, and forwarding copies to requestors.

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

Table 11 - Records Manager

4.11 Document Release and Control Authority

The Document Release and Control Authority reviews Case Reports prior to release, and removes…