Arizona State University Police Department Request for Proposals #: CAD/RMS/Mobile. Mobile Functional Requirements

Transcription

1 General Mobile Data Computing Features Mobile Application User Interface Function Keys/Commands Emergency Key Functionality Mobile Logon/Logoff Application Integration Mobile Mapping Status Views Mobile Dispatch Operations Queries Item # Mobile Data Computing Functional Requirements S M A U Comments 1 General Mobile Data Computing Features 2 Ability for the system to automatically refresh without user intervention, as new information becomes available. 3 Ability to log all mobile transactions with the following information: 4 Agency 5 Date and time of transmission 6 Mobile Terminal ID 7 User ID 8 Vehicle ID - Bike/Segway/Motor/SRO 9 Lockset Number/Keyset 10 GPS Location 11 Ability to provide a visual alert if Mobile application loses connection to CAD. Arizona State University Police Department Request for Proposals #: CAD/RMS/Mobile Mobile Functional Requirements System Functionality Modification Needed. At no extra Cost Modification needed at an additional cost Unable to meet the requirement Please explain any line items (from the left that are not an "out of the box" standard but are part of your overall proposal; specifically, why the particular line item is not an "out of the box" standard. Additionally, please identify what potential effect this may have upon meeting a January 13, 2020 implementation date. (Required for any items marked "M", "A", or "U") Your proposed solution will be evaluated based on the value of each of these items combined and will not negatively impact the proposal. Arizona State University Police Department Mobile Functional Requirements 1 of 17

2 12 Ability to continuously attempt to reconnect to CAD system in the event connectivity is lost. 13 Ability to support an automatic download of software/files (e.g., code tables, updates) at logon. 14 Ability to schedule an automatic download of software/files (e.g., code tables, updates). 15 Ability to provide functionality on the following mobile devices: 16 Laptops 17 Tablets 18 Smartphones 19 Mobile Application User Interface 20 Ability to provide screen display formats that are consistent across the application. 21 Ability for user to toggle between windows. 22 Ability to view multiple windows at the same time (e.g., side by side or cascade). 23 Ability for user to minimize or expand any window. 24 Ability to support touch-screen functionality. 25 Ability to support voice activated (voice command) functionality. 26 Ability to support text-to-voice functionality. 27 Ability to accept input from: 28 3D barcode reader (e.g., driver's license, registration) 29 Card swipe device 30 Command entries on a command line 31 Fingerprint reader 32 Function keys (one touch keys) 33 Point-and-click devices (i.e., mouse, trackball, touch pad) Arizona State University Police Department Mobile Functional Requirements 2 of 17

3 34 Ability for users to configure the display of their Mobiles, including: 35 Font color 36 Font size 37 Window size 38 Window location 39 Day/Night mode 40 Ability to configure a default for the following application settings: 41 Audible message 42 Audible tones 43 Color 44 Ability to store a user profile for mobile display configuration for auto-configuration upon log on. 45 Ability to allow users to return to application default settings Ability for users to select a configuration scheme that accommodates color-blindness. Ability to support multiple on-screen button configurations (e.g., left side, right side, top or bottom). 48 Ability to cut and paste from one application or window to another. 49 Ability to display the following information on the screen during normal operations: 50 Availability of wireless connectivity 51 Call status 52 Communication verification and other Mobile operational status indicators 53 Current unit 54 Current unit status (regardless of who assigned the updated status) Arizona State University Police Department Mobile Functional Requirements 3 of 17

4 55 Current system date and time 56 Incident number 57 Case number (if provided) 58 Message alert 59 Radio talk group (if assigned) 60 Screen name/description 61 Unit ID 62 User ID 63 Vehicle location 64 Ability to view multiple calls simultaneously (e.g., in different windows). 65 Function Keys/Commands 66 Ability to support single keystroke commands. Ability to define sub-menus for buttons and function keys so that 67 button and function key commands are based on previous commands. 68 Ability to define keystroke shortcuts for: 69 Common tasks 70 Status updates 71 Form retrieval (e.g., NCIC call disposition) 72 Ability to configure a Mobile button (tool bar or function key) to launch any third-party program (e.g., MS Word). 73 Emergency Key Functionality 74 Ability to initiate an emergency message transmission from a touch screen button or hot key. 75 Ability to automatically transmit the following information in an emergency situation: 76 Last known location 77 Current location (with AVL) 78 Reference to incident 79 User ID Arizona State University Police Department Mobile Functional Requirements 4 of 17

5 80 User name 81 Ability to have a visible and audible indication that emergency key has been activated (in all units). 82 Ability to delay emergency key activation by an agency defined period of time (e.g., two second pause before activation to allow personnel to deactivate key if necessary). 83 Ability for Agency to configure where the emergency button appears on the screen (e.g., fixed or floating). 84 Ability for dispatch to select which consoles receive visible/audible alerts of emergency key activation. 85 Ability to configure emergency key to capture agency-defined combination of above information. Ability to send to all Mobile and CAD users (except the sender) an 86 emergency notification with unit ID and location (if known) when the emergency key is activated. 87 Ability to prevent emergency notification from appearing on the sender's screen. 88 Ability for the Mobile screen to revert to its prior view after the user dismisses an emergency message. 89 Ability to automatically send location coordinates and unit ID upon triggering an emergency key. 90 Ability for system administrator to turn off emergency key functionality by: 91 Device 92 User 93 Mobile Logon/Logoff 94 Ability to require both user identification and password to logon. 95 Ability to require any combination of the following information to logon to the Mobile application: Arizona State University Police Department Mobile Functional Requirements 5 of 17

6 96 Password 97 Unit ID 98 Radio ID(s) 99 Status (e.g., in service, out-of-service) Ability for agency to set the time a Mobile use can be logged in and 100 remain inactive before automatically logging out the user. (Example: left of the day and forgot to log out). 101 Ability to print a log of all transactions for a Mobile computer. Ability to save data entered into user logon fields that remains the 102 same from session to session (e.g., all information other than password). 103 Ability to automatically notify CAD of logon/logoff. 104 Ability to log multiple individuals on to a single unit. 105 Application Integration 106 Ability to view all incident information available in CAD on the Mobile. 107 Ability to provide the same messaging features as the CAD application. 108 Ability to provide the same BOL features as the CAD application. 109 Ability for mobile status updates to be reflected in CAD. Ability to run multiple applications (e.g., mobile, automated field 110 reporting) on the Mobile at the same time, with CAD operations having precedence over reporting operations. 111 Ability to receive dispatch alerts and/or indicators without losing current work. 112 Ability to receive messages and/or indicators without losing current work. 113 Ability for alerts created in CAD or RMS to be made available to users in the Mobile environment. Arizona State University Police Department Mobile Functional Requirements 6 of 17

7 114 Messaging 115 General Messaging Features 116 Ability to support a messaging system that can transmit messages to and from mobile and desktop workstations. 117 Ability to display the following identifiers within a message: 118 Sender name/id 119 Sender date 120 Sender time 121 Receiver name/id 122 Receiver date 123 Receiver time 124 Ability to send messages to a user who is not logged into the mobile device and cache that message for retrieval when the user logs on. 125 Ability for message server to continuously attempt to deliver a message until received and confirmed. 126 Ability for user to retrieve cached messages upon logon. 127 Ability to assign a priority to a message (e.g., routine, urgent, emergency). 128 Ability to store messages for later viewing. 129 Ability for messages to be sorted by most recent or first received. 130 Sending Messages 131 Ability to create and save message groups. 132 Ability to send broadcast messages. Ability for users to select any number of people as part of a 133 message group with no limitation on the number of people in a group. Ability to enter unlimited narrative with wrap-around feature (if 134 characters are limited, indicate the maximum in the "comments" section). Arizona State University Police Department Mobile Functional Requirements 7 of 17

8 135 Ability to automatically populate the "To" field on the message mask when selecting recipients. 136 Ability to select recipient by: 137 Name 138 Unit ID 139 Badge Number Ability to select a recipient by a single command to create a 140 message (e.g., double click on a logged on user and message screen pops up). 141 Ability to attach files to messages. 142 Ability to embed photos in messages. 143 Ability to set agency-defined file size limit. 144 Ability to send a message to all units handling a specific incident. Ability to transmit a reply message to the originator of a currently 145 displayed message without having to reenter the originator's address. 146 Ability to transmit a "reply all" message to multiple recipients that were part of the originator's message group. 147 Ability to forward a message. 148 Ability to create messages that are retained in the system and sent at pre-specified times. 149 Ability to provide a notification for delivery of messages to the device. 150 Receiving Messages 151 Ability to notify receiver via an audible and/or visual flag that a new message has arrived in mailbox. 152 Ability to prevent incoming messages from interfering with current work. 153 Ability to notify receiver of total number of unread messages. Arizona State University Police Department Mobile Functional Requirements 8 of 17

9 154 Ability for messages to be queued in an "inbox" for later viewing at the convenience of users. 155 Ability to query message logs by agency-defined criteria (e.g., date/time range, sender, recipient, device). 156 Ability to note time opened/read by receiver. 157 Ability to clear a message from the queue. 158 Ability to retain a message in the queue. 159 Ability for supervisors to monitor messages. 160 Ability for supervisors to search messages by a text string (e.g., to identify inappropriate language use). 161 Ability to archive messages. 162 Ability to save message logs for an agency-determined period of time. 163 Ability to purge message logs for an agency-determined period of time. 164 Mobile Mapping 165 Ability for map to function without wireless connectivity. 166 Ability to support AVL functionality. 167 Ability to cache map layers to minimize the amount of data transmitted wirelessly. 168 Ability to update unit and incident locations on map without resetting the entire map. 169 Ability for map to function in the background and not supersede other applications. 170 Ability to display compass direction between two user selected points. 171 Ability to select map layers for display. 172 Ability to center map display on: 173 Current vehicle location (with AVL) 174 Midpoint between vehicle location and dispatch location 175 Dispatch location Arizona State University Police Department Mobile Functional Requirements 9 of 17

10 176 Vehicle activating emergency activation key 177 Specified geographic area (e.g., entering an address via text entry) 178 Incident location Ability to prevent the zoom level from automatically modifying 179 during an active incident (e.g., not automatically zooming out when new units are added) Ability for user to access apartment complex maps upon clicking on 180 the location for a complex (assuming user-created map layer containing site maps). 181 Ability to display other field units on mobile map (assuming AVL and sufficient bandwidth). 182 Ability to make temporary "marks" on map (e.g., to note locations of a law enforcement perimeter). 183 Ability to display active incidents and unit statuses on the map. 184 Ability to display historic incidents on the map. 185 Ability to click on a unit or incident in the incident queue or unit status bar and have it displayed on the map. 186 Ability for mapping client to load automatically upon system boot. 187 Ability to filter display by: 188 Agency = Campus 189 Unit type 190 Unit status 191 Incident type 192 Incident priority 193 Incident number 194 Response area 195 Status Views 196 Ability to view all active calls in a single window. Arizona State University Police Department Mobile Functional Requirements 10 of 17

11 197 Ability to view all pending calls in a single window. 198 Ability to split the screen to see active calls and pending calls. 199 Ability to view unit status by: 200 Campus 201 Individual unit 202 Shift 203 Squad 204 Ability to open any active incident to view dispatch data, units and incident notes. 205 Mobile Dispatch Operations 206 Dispatch Receipt 207 Ability to receive dispatches on the Mobile. 208 Ability to receive dispatches on multiple mobile telecommunications devices including, but not limited to: 209 Mobile computers 210 Smart phones 211 Tablets 212 Ability for dispatches to open automatically on mobile computers. 213 Ability to alert mobile users that a new dispatch has arrived: 214 Visual alert 215 Ability for all personnel dispatched to an incident to receive notification when other personnel are en route. Ability for all personnel dispatched to a call to receive notification of 216 status and location changes of other personnel dispatched to the call. 217 Ability for Mobile users to add themselves to an incident. Ability to access and read all call comments associated with a call 218 regardless of whether assigned to the call. Arizona State University Police Department Mobile Functional Requirements 11 of 17

12 219 Ability to display the following information in distinct fields or tabs (as opposed to in the call narrative) upon receipt of dispatch: 220 Assisting unit(s) 221 Comments/narrative (unlimited) 222 Date and time incident entered 223 Dispatch Time 224 Incident location 225 Incident priority 226 Incident type 227 Caution Notes/Hazard Information 228 Incident talk group 229 Number of previous calls at a specific location (e.g., Manzanita Hall, room 1221) 230 Primary Unit Assigned 231 Reporting party information (e.g., name, phone, address) 232 Suspect information 233 Premise information 234 System generated incident number 235 Ability to directly access (e.g., hyperlink, drill down) previous call information related to the address of the call for service. 236 Incident Updates Ability to display most current incident data at the top of the screen 237 without requiring the user to scroll. Ability to receive supplemental incident information (e.g., location, 238 suspect, vehicle information) without interrupting or overlaying current screen. Ability for supplemental information to be visually distinct from 239 information previously received by Mobile user (e.g., separate font color, highlighted). Arizona State University Police Department Mobile Functional Requirements 12 of 17

13 240 Ability to transmit status information to the CAD system in real time. 241 Premise and Hazard Information Ability to alert user of availability of information associated with a location (gate codes, hazards, premise history, pre-plans, etc.). Ability to indicate type of information that is attached to a call (e.g., gate code, hazard) so that user can decide whether or not to retrieve the information. Ability for field units to have the option of pulling up or not pulling up information attached to the call. 245 Ability to search premise history to find links to incidents, persons, vehicles, etc. 246 Self Initiated Calls for Service 247 Ability to initiate a call for service from the Mobile, including: 248 Call for service 249 Traffic stop 250 Subject stop 251 Administrative activity (e.g. training, field inspections) 252 Other agency defined call types. 253 Ability to initiate a call for service with a function-key. Ability, with appropriate supporting mapping/avl technology, to 254 indicate unit/incident location when initiating an incident from the field. 255 Ability to validate self-initiated call for service location at the mobile level. 256 Perimeters Arizona State University Police Department Mobile Functional Requirements 13 of 17

14 Ability to automatically generate a perimeter upon entry of a 257 location and perimeter distance (e.g., set a 3 block perimeter around 701 E Apache Blvd.). 258 Ability to receive suggested perimeter positions from dispatch. 259 Ability for suggested perimeter positions to appear mobile map upon receipt. 260 Call Disposition 261 Ability to clear calls from the Mobile. 262 Ability to require a call clearance code in order to clear a call from the Mobile. 263 Ability to select disposition code from a drop-down list. 264 Ability to provide a text field for disposition comments. 265 Ability to reject a disposition if unsuitable for the incident type. 266 Queries 267 General Queries 268 Ability to query the following systems from the mobile computer: 269 CAD 270 RMS 271 ACJIS/NCIC 272 DMV 273 CJIS 274 County Mugshots 275 Ability to search and query all appropriate databases without impacting performance of mobile dispatch operations. 276 Ability to query and retrieve premise information for an address not associated with a call for service. 277 Ability to initiate queries with a single key stroke. Arizona State University Police Department Mobile Functional Requirements 14 of 17

15 Ability to use predefined data entry forms/screens (masks) to 278 minimize data transmitted during queries. 279 Ability for agency to create standard query screen formats (masks). 280 Ability to provide pre-defined data entry/query forms, including, but not limited to: 281 Articles 282 Accident Investigation 283 Driver license query 284 Incident status 285 Location 286 License plate query 287 Logon/logoff 288 Missing person information 289 Name query 290 Premise information query 291 Previous events 292 Vehicles 293 Ability to access query forms by: 294 Command line entry 295 Drop down menus 296 Dedicated function keys 297 Unit History Queries 298 Ability to query unit history detail by: 299 Date and time range (i.e., start and end dates or times) 300 Personnel ID 301 Unit ID 302 Last name 303 Incident Queries 304 Ability to query and retrieve incident records by one or more of the following factors: Arizona State University Police Department Mobile Functional Requirements 15 of 17

16 305 Any operator ID associated with the incident 306 Any unit ID assigned to the incident 307 Caller number 308 Campus 309 Case number 310 Cross streets 311 Date and time range (e.g., start and end data and time parameters) 312 Disposition codes 313 Unit ID 314 Personnel ID 315 Geographic area (e.g., area, beat) 316 User defined radius from a location 317 Incident number 318 Incident priority 319 Incident type 320 Last name of officer/subjects 321 License plate 322 Location or partial location 323 Name (suspect, reporting party, witness, victim) 324 License Plate Queries 325 Ability to query the license plate against the RMS, MVD and ACJIS databases when a unit is on a vehicle stop. 326 Ability to conduct multiple license plate searches simultaneously. 327 Ability to run the registered owner of the vehicle in a license plate query return. 328 Ability to identify the number of times a license plate has been queried 329 Query Returns 330 Ability to save all query returns until user clears data. Arizona State University Police Department Mobile Functional Requirements 16 of 17

17 331 Ability to save all stored query returns after logoff (e.g., returns are still there the next time user logs onto the system). Ability to produce an alert when a query return contains a record 332 marked as potentially hot (e.g., contains agency-defined keywords such as stolen, wanted, missing): 333 Audible alert 334 Visual alert 335 Ability to produce an alert when a record returns a record containing a stolen vehicle: 336 Audible alert 337 Visual alert 338 Ability for mobile query returns to appear on dispatcher's screen as well as the mobile computer screen if the return contains an agencydefined keyword (e.g., stolen, missing, wanted, felony). 339 Ability to attach any database query return to incident records. Ability to drill down into query returns regarding a potentially 340 hazardous subject, vehicle, and/or location to find the details of that hazard. 341 Ability to sort query results on any returned field. Arizona State University Police Department Mobile Functional Requirements 17 of 17