Exhibit A Technical Requirements Matrix.xlsx
XLSX spreadsheet 258 KB Posted
- Solicitation number
- NSP7149 Z1
- Issued by
- Blaine County, Nebraska
About this file
This document is an Exhibit A Technical Requirements Matrix for a Computer Aided Dispatch (CAD) and Mobile Data System Request for Proposal (RFP) issued by the Nebraska State Patrol (NSP), identified as RFP 7194 Z1. The comprehensive matrix details extensive technical requirements across multiple modules including CAD, Mobile, Interfaces, and system capabilities. The RFP seeks a solution that supports a statewide CAD environment with multiple dispatch centers, capable of managing 197,500 annual calls, supporting 21 combined call taker/dispatcher positions, and serving 7 law areas with 2 dispatched agencies. The system must integrate with numerous existing technologies, support Next Generation 9-1-1 standards, provide real-time mapping and routing, enable comprehensive reporting, and facilitate multi-agency operations.
The technical matrix reveals a complex technological ecosystem requiring robust integration capabilities, with specific requirements for data entry, user interfaces, mapping, automatic vehicle location (AVL), emergency button functionality, and extensive query capabilities. The proposed system must support 350 mobile users across multiple platforms (PC, Android, iOS), interface with over 20 existing systems including state and national databases, and provide comprehensive security and audit logging. The matrix indicates a preference for a solution that offers multi-factor authentication, flexible configuration options, offline capabilities, and advanced features like automatic narrative generation, extensive quality assurance tools, and seamless data exchange between CAD, mobile, and records management systems.
View the file
Other files
Show 40 more
50 files listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Agency Info
| Requirements Evaluation Matrix | BIDDER COMPLETING THIS MATRIX: |
| Nebraska State Patrol - RFP 7194 Z1 |
tc={7445AA41-D3F2-4F11-97F7-B52F50AF4ABF}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Should the RFP be listed as NSP7194 Z1 as that's how it's named on all other documents? BIDDER NAME
| Exhibit A | |
| Agency Logistics and Information | |
| Computer-Aided Dispatch | |
| Question | Answer |
| Current CAD system vendor | TEG |
| Production CAD positions: | |
| Number of combined call taker/dispatcher positions | 21 |
| Total: | 21 |
| Training / Test / Backup positions | |
| Test positions | |
| Training positions | 4 |
| Total: | 4 |
| CAD Users | |
| Number of Call Takers and Dispatchers | 50 |
| Total: | 50 |
| Annual calls a year | 197,500 |
| Annual calls dispatched a year | 197,500 |
| Is this a Primary PSAP? | No |
| Number of law areas they dispatch for | 7 |
| Number of agencies they dispatch for | 2 |
| Is there a back-up dispatch center? | Yes - each center operates as a backup for the other |
| Do they have GIS staff or do they use a vendor? | Staff |
| Is the Dispatch Center part of the fiduciary agency? | Yes |
| If , specify name of the agency | Nebraska State Patrol |
| Do any calls get transferred to other dispatch centers? | Yes |
| E-911 vendor | Intrado |
| Radio system vendor | Motorola |
| Mobile Data System | |
| Question | Answer |
| Current Mobile being used | TEG |
| PC | x |
| Android phone | MACH |
| Android tablet | |
| iOS phone | MACH |
| iOS tablet | |
| Apple Watch | |
| Law Users | |
| PC | 350 |
| Android phone | |
| Android tablet | |
| iOS phone | |
| iOS tablet | |
| Apple Watch | |
| Total: | 350 |
Grand Total of all Mobile users: 350
Should the RFP be listed as NSP7194 Z1 as that's how it's named on all other documents?
Instructions
| Exhibit A |
| Matrix Submission Instructions |
| Please respond to each line item requirement by placing an X in the appropriate column to indicate your response |
| Currently Complies: This indicates the proposed solution meets all aspects of the requirement. |
| Comments: Bidders should explain how their solution satisfies the matrix requirement item. |
| Does Not Comply: This indicates the proposed solution does not meet the requirement. |
| Comments: Bidders should explain why their solution does not meet the requirement. |
| Partially Comply: This indicates the proposed solution meets part of the requirement. |
| Comments: Bidders should provide details indicating which part of the requirement cannot be met by the proposed solution and how the vendor partially complies (e.g., in conjunction with a third-party solution, "workaround", etc). |
| Will Comply: This indicates that while the proposed solution does not currently meet the requirement, the vendor will comply with the requirement item. |
| Comments: Bidders should explain how their solution will comply (e.g., if this is a future development roadmap item - including the approximate date of expected compliance, if it is an item the vendor is willing to develop and provide as a contract deliverable, if the solution can be used in conjunction with a third-party application or "workaround" to achieve full compliance, etc.). |
| The Excel version of this matrix must be included with your proposal submission |
CAD
| BIDDER NAME | ||||||
| Exhibit A | ||||||
| Item Number | Module/Description of Requirement | Currently Complies | Does not Comply | Partially Comply | Will Comply | Comments |
| General CAD Requirements | ||||||
| 1.00 | The solution should have the ability to support a statewide CAD environment with multiple dispatch centers | |||||
| 2.00 | The solution should have the ability to support dispatch centers on the same CAD instance that operate in different time zones, and maintains accurate time stamps for all CAD and mobile activity | |||||
| 3.00 | The solution should have the ability to support and dispatch for multiple agencies simultaneously | |||||
| 4.00 | The solution should have the ability to comply and maintain compliance with published NENA NG-911 standards | |||||
| 5.00 | The solution should have the ability to dispatch only law units from a specific Troop area from a single CAD window (the ability to filter out other agencies from non-relevant unit recommendations) | |||||
| 6.00 | The solution should have the ability to capture all CAD transactions in an audit log | |||||
| 7.00 | The solution should have the ability to support multiple monitors | |||||
| 8.00 | The solution should allow for agency administrators to set a default profile using multiple windows and monitors that are accessible by all users | |||||
| 9.00 | The solution should allow users with appropriate permissions to set multiple profiles using multiple monitors and windows that can be saved and shared with other users | |||||
| 10.00 | The solution should have the ability for the system to automatically generate a case/incident number from the Niche RMS application | |||||
| 11.00 | The solution should have the ability for each agency to have a unique identifier regarding incident numbers | |||||
| 12.00 | The solution should have the ability to support remote access to the CAD (e.g., via VPN or other secure connection) | |||||
| 13.00 | The solution should have the ability to perform the following via remote access: | -- | -- | -- | -- | -- |
| 13.01 | Monitor and create calls | |||||
| 13.02 | Monitor units and unit statuses | |||||
| 13.03 | Create and dispatch calls | |||||
| 13.04 | Run queries | |||||
| 14.00 | The solution should include an "offline" mode so users may continue to perform basic CAD functions if network connectivity is lost | |||||
| 15.00 | The system should include a "back up" or "catch up" mode to allow users to input CAD information following a CAD system outage | |||||
| Application User Interface | ||||||
| 16.00 | The solution should have the ability to configure the graphical user interface at the following levels: | -- | -- | -- | -- | -- |
| 16.01 | User | |||||
| 16.02 | PSAP | |||||
| 16.03 | Agency | |||||
| 17.00 | The solution should have the ability to customize the following, including but not limited to: (If certain features are customizable at only the user or agency level, indicate as such in the "Comments" field) | -- | -- | -- | -- | -- |
| 17.01 | Font types, sizes and colors | |||||
| 17.02 | Window background color, sizes, and locations | |||||
| 17.03 | The order in which fields are displayed | |||||
| 17.04 | The ability to configure field names for display (e.g., "Troop Area" instead of "Beat", etc). | |||||
| 18.00 | The solution should have the ability for administrators to define which options are configurable by the user | |||||
| 19.00 | The solution should have the ability for administrators to define fields that are required to display in status windows | |||||
| 20.00 | The solution should have the ability for user to enlarge and shrink columns in their status windows | |||||
| 21.00 | The solution should allow users to detach, move, and resize all windows | |||||
| 22.00 | The solution should have the ability to save CAD layout configurations based on user IDs (e.g., not workstation-specific) | |||||
| 23.00 | The solution should have the ability to reset their current layout configuration to default settings | |||||
| 24.00 | The solution should have the ability to maintain configuration settings during upgrades (user screen templates and layouts are not lost after software upgrades) | |||||
| 25.00 | The solution should have the ability to support MS Windows functionality, including but not limited to: | -- | -- | -- | -- | -- |
| 25.01 | Minimize/maximize windows | |||||
| 25.02 | The ability to have multiple windows open simultaneously | |||||
| 25.03 | Tile/cascade windows | |||||
| 26.00 | The solution should have the ability to display system messages without affecting a user's work in progress | |||||
| 27.00 | The solution should have the ability to display multiple call windows simultaneously, allowing for each to be configured differently (if desired by the user) | |||||
| 28.00 | The solution should have the ability to display multiple unit status windows simultaneously | |||||
| 29.00 | The solution should allow for users to configure each unit status window uniquely (e.g., sorting, filtering, choosing which desired columns to view) | |||||
| General Data Entry | ||||||
| 30.00 | The solution should have the ability to support data entry via: | -- | -- | -- | -- | -- |
| 30.01 | Mouse and Keyboard if required | |||||
| 30.02 | Command line entry | |||||
| 30.03 | Function keys/hot keys that provide preformatted data entry screens (e.g., designated data fields) | |||||
| 31.00 | The solution should have the ability to click on the map and transfer the location into the address field in a call for service | |||||
| 32.00 | The solution should have the ability to provide type-ahead capability where the user can continue entering data while the system is processing a previous transaction | |||||
| 33.00 | The solution should have the ability to support drop-down menus and auto completion | |||||
| 34.00 | The solution should sort/filter any pick list by type and description | |||||
| 35.00 | The solution should allow for the selection of items from a pick list by keyboard navigation and mouse (point and click) | |||||
| 36.00 | The solution should have the ability to provide word processing capabilities on narrative and comment fields including text wrap, spell check, and copy/paste | |||||
| 37.00 | The solution should have the ability for new call narrative/notes to appear at the top of the call narrative section, with the ability to quickly switch to chronological view | |||||
| Command Line | ||||||
| 38.00 | The solution should allow for multiple command lines that can be placed anywhere on the user's screens | |||||
| 39.00 | The solution should provide command help or fields the user can tab into to enter information | |||||
| 40.00 | The solution should have the ability to string multiple commands together for a single command line entry, executing both commands when the user selects the "Enter" key (e.g., for unit statuses: One unit is at scene and another unit is enroute) | |||||
| 41.00 | The solution should allow for hot keys to execute commonly used commands (e.g., typing the unit number, location, plate, and state, then selecting a function key that is specific to a traffic stop) | |||||
| 42.00 | The solution should allow the users to enter either the unit or the actual desired command first. | |||||
| 43.00 | The solution should allow for a drop-down list of previous commands and allow users to select from the list to populate the command line with that command string | |||||
| 44.00 | The solution should allow users to open, close, and toggle between command lines with a single keystroke | |||||
| 45.00 | The solution should allow the agency to configure their desired command format/syntax | |||||
| 46.00 | The solution should include commands that combine multiple status updates simultaneously (e.g., dispatched and enroute or dispatched and at scene) and log appropriate time stamps for each | |||||
| 47.00 | The solution should include a call-specific command line or have the ability to default a command to the selected call for service | |||||
| 48.00 | The solution should provide the ability for the command line to allow for updates of all units on a call simultaneously using call for service number (e.g., all units at scene at the same time, all units in service at the same time) | |||||
| 49.00 | The solution should provide the ability for the command line to allow for all commands to be executed using a unit number or call for service number (where applicable) | |||||
| 50.00 | The solution should allow agency administrators to alias vendor commands | |||||
| Timers and Time Stamps | ||||||
| 51.00 | The solution should have the ability to automatically time stamp all activities. Time stamps should include the date/time, unit numbers, and the user(s) performing the function/activity | |||||
| 52.00 | The solution should have the ability to configure timers and alerts based upon agency-defined parameters to include any and all combinations of the following: Unit status, call status, call priority, and call type | |||||
| 53.00 | The solution should automatically reset timers as unit and call statuses change | |||||
| 54.00 | The solution should have the ability to associate timers with: | -- | -- | -- | -- | -- |
| 54.01 | Unit status updates | |||||
| 54.02 | Call type timers | |||||
| 54.03 | Agency-defined time in current unit or call status | |||||
| 54.04 | Call priority | |||||
| 55.00 | The solution should allow for timers to be configured at the agency level (e.g., each agency on the system may have their own timers) | |||||
| 56.00 | The solution should allow for timers to be configured for any agency- defined statuses | |||||
| 57.00 | The solution should allow for timers to be set automatically and manually for calls and units | |||||
| 58.00 | The solution should allow for a "generic" timer that can be set by a user for any reason and time | |||||
| 59.00 | The solution should allow users the option to clear and snooze timers | |||||
| 60.00 | The solution should have the ability to alert users to the expiration of timers via: | -- | -- | -- | -- | -- |
| 60.01 | Audible alert | |||||
| 60.02 | Visual alert | |||||
| 61.00 | The solution should include the ability for agency administrators to configure whether timers are audible, visual or both | |||||
| 62.00 | The solution should have the ability to automatically present visual and/or audible alerts/flags associated with the address, upon entering an address, including but not limited to: | -- | -- | -- | ||
| 62.01 | Alert/hazard information | |||||
| 62.02 | Premise history information | |||||
| 63.00 | The solution should have the ability to enter an apartment, lot, or suite number in a separate designated field for address verification | |||||
| 64.00 | The solution should have the ability to log when dispatchers have viewed alerts | |||||
| 65.00 | The solution should have the ability when querying a name for users to be notified of an associated alert (e.g., if a person was flagged in the RMS, if a person is wanted via NCIC) | |||||
| 66.00 | The solution should have the ability for flags/alerts to be dynamic (e.g., users can click on flag for additional information) | |||||
| 67.00 | The solution should have the ability to provide a call history at an address when creating a call | |||||
| 68.00 | The solution should have the ability for users to sort a summary of previous calls by: | -- | -- | -- | -- | -- |
| 68.01 | Chronological order (most or least recent) | |||||
| 68.02 | Call type | |||||
| 69.00 | The solution should have the ability to alert users of previous calls for service at a specific location within an agency-defined timeframe, based on specified call types | |||||
| 70.00 | The solution should have the ability for user to add a new alert/flag | |||||
| 71.00 | The solution should have the ability to associate an expiration with a alert/flag | |||||
| 72.00 | The solution should have the ability to include alert information with dispatches sent to responding units | |||||
| 73.00 | The solution should include the ability to alert/flag based on a specific address and unit/apartment number | |||||
| Call Taking | ||||||
| 74.00 | The solution should have the ability to receive call data from: | -- | -- | -- | -- | -- |
| 74.01 | E-911 Phone system | |||||
| 74.02 | Private alarm companies (via ASAP to PSAP interface) | |||||
| 74.03 | TDD/TTY | |||||
| 75.00 | The solution should have the ability to enter calls using pre-formatted screens | |||||
| 76.00 | The solution should have the ability for an agency to determine the order of fields and the tab order in pre-formatted screens | |||||
| 77.00 | The solution should have the ability for an agency to determine what data elements are captured as part of the pre-formatted screen | |||||
| 78.00 | The solution should have the ability to automatically populate the call entry screen with information from the E9-1-1 application (no manual intervention required) | |||||
| 79.00 | The solution should have the ability to populate the CAD screen with information from the E9-1-1 application via manual intervention (e.g., function key, mouse click) | |||||
| 80.00 | The solution should have the ability for narrative fields to allow for an unlimited number of characters | |||||
| 81.00 | The solution should have the ability to enter standard information in defined fields for the following: | -- | -- | -- | -- | -- |
| 81.01 | Persons (callers, witnesses, suspects), including description(s) | |||||
| 81.02 | Vehicles (including license plate and vehicle description) | |||||
| 81.03 | Location | |||||
| 82.00 | The solution should have the ability to alert dispatchers that the call taker has added information by means of: | -- | -- | -- | -- | -- |
| 82.01 | Audible alert | |||||
| 82.02 | Visual alert | |||||
| 83.00 | The solution should allow the agency to configure whether call update alerts will be audible, visual, or both | |||||
| 84.00 | The solution should have the ability for agency-defined fields to automatically query the Nebraska state and NCIC systems (if applicable), and attach returns to the call record | |||||
| 85.00 | The solution should have the ability to generate a call from a previous call | |||||
| 86.00 | The solution should have the ability for call takers and dispatchers to work on the same call for service simultaneously | |||||
| 87.00 | The solution should have the ability for call takers to add comments to a call after it has been dispatched and automatically update the dispatcher's call screen | |||||
| 88.00 | The solution should include the ability for users to mark call comments and messages as urgent/high priority | |||||
| 89.00 | The solution should have the ability to receive Phase I and Phase II geographic X/Y coordinates from a cellular telephone carrier | |||||
| 90.00 | The solution should have the ability to relate X/Y coordinates to an actual address | |||||
| 91.00 | The solution should have the ability to transform X/Y coordinates to the map for display | |||||
| 92.00 | The solution should have the ability to capture the call location separately from caller location | |||||
| 93.00 | The solution should have the ability to capture multiple locations outside of caller location, including multiple secondary unit locations | |||||
| 94.00 | The solution should have the ability to enter a location for an event by entering any of the following: | -- | -- | -- | -- | -- |
| 94.01 | Street address | |||||
| 94.02 | Block number or address range | |||||
| 94.03 | Intersections - including intersections by partial street names | |||||
| 94.04 | Latitude/Longitude | |||||
| 94.05 | Mile markers by 1/10th of a mile on interstates | |||||
| 94.06 | Common place names | |||||
| 94.07 | Street and highway name aliases | |||||
| 94.08 | Point and click on the map | |||||
| 95.00 | The solution should have the ability to validate intersections, regardless of which street name is entered first (e.g., Main St / Broadway, or Broadway / Main St). | |||||
| 96.00 | The solution should have the ability to save identical intersection names with different address points | |||||
| 97.00 | The solution should have the ability to parse address data into any of the following elements: | -- | -- | -- | -- | -- |
| 97.01 | Street number | |||||
| 97.02 | Mile marker | |||||
| 97.03 | Apartment, lot, or suite information | |||||
| 97.04 | Street name | |||||
| 97.05 | Street prefix | |||||
| 97.06 | Street type (e.g., Ave., Ln., St, Rd, Way, etc.) | |||||
| 97.07 | Unit type | |||||
| 97.08 | Unit number | |||||
| 97.09 | City | |||||
| 98.00 | The solution should have the ability to capture the following information upon receipt of a wireless 9-1-1 call: | -- | -- | -- | -- | -- |
| 98.01 | Latitude/Longitude | |||||
| 98.02 | Closest street address | |||||
| 98.03 | Nearest cross street | |||||
| 99.00 | The solution should have the ability to geoverify the location of all entered addresses | |||||
| 100.00 | The solution should have the ability to override the geoverified location | |||||
| 101.00 | The solution should have the ability to validate a location entry upon: | -- | -- | -- | -- | -- |
| 101.01 | Operator request (e.g., press a button) | |||||
| 101.02 | Entry into a location field | |||||
| 102.00 | The solution should have the ability to create a report of all overridden geoverified locations | |||||
| 103.00 | The solution should have the ability upon address verification, for the system to auto-populate associated fields (e.g., zip code, town, etc.) | |||||
| 104.00 | The solution should have the ability for addresses entered by field units (e.g., on a self-dispatch) to correctly populate all address fields in the CAD call | |||||
| 105.00 | The solution should have the ability to support RapidSOS integration | |||||
| 106.00 | The solution should have the ability to use the E9-1-1 ALI reported location address for address verification | |||||
| 107.00 | The solution should have the ability to use the coordinate-based GIS to determine if there are premise or hazard records within a defined radius of the call | |||||
| 108.00 | The solution should have the ability to enter a street name and be presented with: | -- | -- | -- | -- | -- |
| 108.01 | Aliases | |||||
| 108.02 | Associated address ranges | |||||
| 108.03 | List of cross streets | |||||
| 109.00 | The solution should have the ability to automatically display the following data elements that are relevant, upon entry of a verified address: | -- | -- | -- | -- | -- |
| 109.01 | High/low cross streets | |||||
| 109.02 | Common place names | |||||
| 109.03 | Business names | |||||
| 109.04 | Law Enforcement response area/Troop area | |||||
| 109.05 | Apartment complex names | |||||
| 110.00 | The solution should have the ability to translate the call location to the appropriate public safety geographical boundary/Troop area | |||||
| 111.00 | The solution should have the ability to translate street alias names to actual street names or addresses | |||||
| 112.00 | The solution should have the ability to enter a common place name and be presented with a list of addresses with that common place name (e.g., McDonald's search) | |||||
| 113.00 | The solution should have the ability to notify users through a visual and/or audible flag if multiple street addresses, street names, or intersections are found in GIS | |||||
| 114.00 | The solution should have the ability to offer a list of address options if multiple similar addresses, intersections, or street names are found in GIS | |||||
| 115.00 | The solution should have the ability to display, on a map, the call location in relation to other active calls on the map during the call entry process | |||||
| 116.00 | The solution should have the ability to manually verify an address without creating an event | |||||
| 117.00 | The solution should have the ability to display a drop-down list containing call types | |||||
| 118.00 | The solution should filter the list of possible call type candidates by code and description, allowing users to easily filter and select the appropriate call type via keyboard function | |||||
| 119.00 | The solution should allow authorized users to override the default call priority | |||||
| Call Creation | ||||||
| 120.00 | The solution should have the ability to create a CAD call by entering a location and call type, at minimum | |||||
| 121.00 | The solution should have the ability to input all call and narrative information on one screen | |||||
| 122.00 | The solution should have the ability to display a blank form for entering new calls with a single keystroke, mouse click, or function key upon initiation of a CAD call | |||||
| 123.00 | The solution should have the ability to enter calls using: | -- | -- | -- | ||
| 123.01 | Standard call entry form | |||||
| 123.02 | Command line | |||||
| 124.00 | The solution should have the ability to suspend the entry of a call (hold) | |||||
| 125.00 | The solution should allow CAD users with appropriate permissions to access and complete calls that were suspended (held) by other users prior to completion | |||||
| 126.00 | The solution should have the ability to support multiple partially completed/suspended calls | |||||
| 127.00 | The solution should have the ability to exclude partially completed/ suspended calls in CAD for viewing by Mobile users | |||||
| 128.00 | The solution should have the ability for the call for service record to indicate if call data entry was suspended | |||||
| 129.00 | The solution should have the ability to time stamp suspension and reactivation of call entry | |||||
| 130.00 | The solution should have the ability to auto-spawn a call for another agency based on a specific on demand (e.g., Capitol Security is needed in addition to NSP) | |||||
| Duplicate Call Management | ||||||
| 131.00 | The solution should have the ability to identify and flag potential duplicate calls during the call taking process in a manner that allows users to quickly identify potential duplicate calls to determine if a current call should be supplemented or a new call created | |||||
| 132.00 | The solution should have the ability to display proximity calls on a map (e.g., calls within a specified distance of each other to assist users in identifying possible duplicate calls) | |||||
| 133.00 | The solution should have the ability for the agency to define parameters of duplicate call identification (e.g., defined proximity, definition of "recently closed", etc.) | |||||
| 134.00 | The solution should have the ability to automatically provide users with call details about possible duplicate calls (including time of call, location, call type, and proximity) | |||||
| 135.00 | The solution should maintain all call information when a call is supplemented using the duplicate call/merging functions (e.g., caller names, phone number(s) and remarks, etc.), with appropriate date and time stamps | |||||
| Premise Information Retrieval | ||||||
| 136.00 | The solution should have the ability to search for premise information based on any of the following data elements: | -- | -- | -- | -- | -- |
| 136.01 | Address | |||||
| 136.02 | Sub-address (e.g., unit number, building floor, apartment number, etc.) | |||||
| 136.03 | Block ranges | |||||
| 136.04 | Business name | |||||
| 136.05 | Historic business name (unlimited number) | |||||
| 136.06 | Common place names | |||||
| 136.07 | Intersections (including intersections by partial street names) | |||||
| 136.08 | Name | |||||
| 136.09 | Phone number | |||||
| 137.00 | The solution should have the ability to query the Niche RMS system on demand or based on specific parameters (high risk, etc.) | |||||
| 138.00 | The solution should have the ability to automatically initiate a search for associated premise information in CAD upon address entry | |||||
| 139.00 | The solution should automatically alert users to premise information on locations not associated with calls based on a specific address or user defined radius | |||||
| 140.00 | The solution should have the ability to automatically alert users to premise history related to a current call | |||||
| 141.00 | The solution should have the ability to indicate the number of prior calls at a location | |||||
| 142.00 | The solution should have the ability to retrieve any information associated with the premise (e.g., floorplans, prior calls for service, etc.) and link it to a newly created CAD call for service | |||||
| 143.00 | The solution should include any alerts flagged as hazards on a location as part of the CAD call for service for any newly created CAD calls at the same location | |||||
| 144.00 | The solution should have the ability for the CAD map to display all known alerts/hazards within a user-defined radius. | |||||
| 145.00 | The solution should include the ability to configure the types of alerts/hazards that are visible to each agency/user group, with a default of including all alerts/hazards associated to a location | |||||
| 146.00 | The solution should have the ability for premise information to be presented and available to users but not prevent the users from continuing current work (e.g., window does not cover the entire workstation or call screen) | |||||
| Call Scheduling | ||||||
| 147.00 | The solution should have the ability to enter calls scheduled for dispatching at a later time, maintaining the original time of entry | |||||
| 148.00 | The solution should have the ability to schedule recurring calls with expiration dates (similar to MS Outlook) | |||||
| 149.00 | The solution should have the ability to modify calls scheduled for dispatching at a later time | |||||
| 150.00 | The solution should have the ability for scheduled calls to be visible in a separate "scheduled" call queue. Such calls may also be included in the main call queue, however they should be sorted and/or filtered separately by the user's preference | |||||
| 151.00 | The solution should have the ability for scheduled calls to automatically enter the pending call queue at their prescribed time | |||||
| 152.00 | The solution should have the ability for officers to self-dispatch to scheduled calls based on appropriate permissions (once the call for service has moved from the scheduled to a pending queue) | |||||
| 153.00 | The solution should have the ability to visually distinguish and display scheduled calls to CAD users | |||||
| Non-Dispatched Calls | ||||||
| 154.00 | The solution should have the ability to enter calls in which no dispatch occurs | |||||
| 155.00 | The solution should have the ability to re-open a non-dispatched call and maintain all original and updated times | |||||
| 156.00 | The solution should have the ability for non-dispatched calls to be excluded from status windows (e.g., pending queue) | |||||
| Dispatching | ||||||
| 157.00 | The solution should have the ability to retrieve a CAD call and review all available information already entered up to the point of call retrieval | |||||
| 158.00 | The solution should have the ability to keep calls in a pending queue indefinitely | |||||
| 159.00 | The solution should have the ability to sort pending calls by priority, location, call type, and time in pending status, including highest priority calls and longest waiting calls | |||||
| 160.00 | The solution should have the ability to associate timers with call priority and/or call type in pending queues (e.g., alert user after 5 minutes in a pending queue if a priority 3 call, 2 minutes if a priority 2 call, 1 minute if it is a burglary in progress call, etc.) | |||||
| Unit and Resource Recommendations | ||||||
| 161.00 | The solution should have the ability to create and configure unit recommendations to calls based on any combination of the following: | -- | -- | -- | -- | -- |
| 161.01 | AVL (automatic vehicle location): Based on live routing and the unit's ETA to the call for service location | |||||
| 161.02 | Area/beat | |||||
| 161.03 | Natural boundaries | |||||
| 161.04 | Obstacles | |||||
| 161.05 | Traffic | |||||
| 161.06 | Speed limits | |||||
| 161.07 | Street network | |||||
| 161.08 | Street direction | |||||
| 161.09 | Equipment required | |||||
| 161.10 | Call location | |||||
| 161.11 | Call type | |||||
| 161.12 | Occupancy (e.g., residential, office building, etc.) | |||||
| 161.13 | Priority | |||||
| 161.14 | Pre-defined response plans | |||||
| 161.15 | Unit or station run order | |||||
| 161.16 | Special conditions (e.g., heightened response, etc.) | |||||
| 161.17 | Special skills required | |||||
| 161.18 | Type of units required | |||||
| 161.19 | Number of units required | |||||
| 161.20 | Current unit status | |||||
| 162.00 | The solution should have the ability to determine resource recommendations based on unique response plans per agency | |||||
| 163.00 | The solution should have the ability to recommend units from multiple agencies on the system | |||||
| 164.00 | The solution should have the ability for CAD to automatically update unit recommendations if the user makes relevant call information changes (e.g., call type or location change) | |||||
| 165.00 | The solution should have the ability to visually alert users when the system updates unit recommendations | |||||
| 166.00 | The solution should have the ability to record the unit recommendations as presented to the dispatcher | |||||
| 167.00 | The solution should have the ability to query the system for unit recommendations without creating a call (e.g., verifying a response plan) | |||||
| 168.00 | The solution should have the ability to create and track temporary units (e.g. outside agency assist units) | |||||
| 169.00 | The solution should include an agency-accessible report/audit trail for temporary units in order to report on responses and response times by outside agencies | |||||
| 170.00 | The solution should have the ability to enter response plans with pre-defined recommendations by any combination of the following: | -- | -- | -- | -- | -- |
| 170.01 | Business/location type (e.g., high rise building, parking deck, school, etc.) | |||||
| 170.02 | Specific address | |||||
| 170.03 | Address type | |||||
| 170.04 | Address range | |||||
| 170.05 | Call type | |||||
| 170.06 | Agency-defined geographic areas and zones | |||||
| 171.00 | The solution should have the ability to define response areas using polygons on the map | |||||
| 172.00 | The solution should have the ability to export response plans to MS Excel | |||||
| 173.00 | The solution should have the ability to define a day/time range that a response plan is active | |||||
| 174.00 | The solution should have the ability to have multiple backup units continually checked so they are always recommended in the order prescribed. | |||||
| 175.00 | The solution should have the ability to add special response narratives or comments to response plans (e.g., pre-arrival instructions) | |||||
| 176.00 | The solution should have the ability for agency-authorized personnel to modify response plans based on user permissions | |||||
| 177.00 | The solution should have the ability to remove a unit from a call and reassign the unit to a new call (pre-empt) via: | -- | -- | -- | -- | -- |
| 177.01 | Single command | |||||
| 177.02 | Drag and drop | |||||
| 177.03 | Multi-select (select/right click or drag and drop) | |||||
| 177.04 | Preformatted data entry screens (e.g., dedicated data fields) | |||||
| 178.00 | The solution should have the ability to dispatch units by: | -- | -- | -- | -- | -- |
| 178.01 | Accepting the recommended units | |||||
| 178.02 | Selecting and dispatching units other than those initially recommended | |||||
| 178.03 | Selecting some, but not all of the initially recommended units | |||||
| 178.04 | Selecting a combination of recommended units and manually adding additional units in a single command or function | |||||
| 179.00 | The solution should have the ability to log unit recommendation overrides in the audit trail (e.g., logging initially recommended units versus actual dispatched units) | |||||
| 180.00 | The solution should include a clear indication on the unit recommendations screen if recommendations are made based on AVL (automatic vehicle location) for the following data elements including, but not limited to: | -- | -- | -- | -- | -- |
| 180.01 | ETA for each unit | |||||
| 180.02 | Unit recommendations based on AVL (automatic vehicle location)versus assigned Troop area | |||||
| 180.03 | An option to switch between AVL and non AVL-based unit recommendations | |||||
| 181.00 | The solution should allow for dispatchers to assign multiple units to a call from command line or function key, multi-select and/or drag and drop | |||||
| Special Skills | ||||||
| 182.00 | The solution should have the ability to view a list of special skills/equipment for all personnel logged onto the system | |||||
| 183.00 | The solution should have the ability to identify all personnel with a specific skill (e.g., language, training, special team) with indicators who is logged on and available and not available or not logged on | |||||
| Alternate Response Plans/Modes | ||||||
| 184.00 | The solution should allow for an alternate response plan mode (e.g., storm mode) to allow for different responses to be utilized temporarily | |||||
| 185.00 | The solution should allow for the agency to configure different response plans based on agency and area for alternate response plan modes (e.g., hurricane, flooding, special event, low staffing, etc.) | |||||
| 186.00 | The solution should allow agency administrators to set alternate response plans that can be activated and deactivated on-the-fly | |||||
| 187.00 | The solution should provide for designated authorized users to turn on an alternate response plan for individual agencies/areas | |||||
| 188.00 | The solution should allow for on-the-fly creation of alternate response plans | |||||
| 189.00 | The solution should allow for automatically initiating an alternate response plan for a specific area/agency based on time of day and day of week (e.g., Friday night from 1900-0300 is a 2 unit response when other times are a 1 unit response) | |||||
| Field-Initiated Calls for Service | ||||||
| 190.00 | The solution should have the ability for users to perform the following when a unit is placed on a traffic stop: | -- | -- | -- | -- | -- |
| 190.01 | Assign the recommended or requested units | |||||
| 190.02 | Send any existing call the unit is on to a stacked/pending queue | |||||
| 190.03 | Send the call to the assigned unit's Mobile device | |||||
| 190.04 | Start the call and/or unit status timers | |||||
| 190.05 | Update the call and unit status displays | |||||
| 191.00 | The solution should allow field users to self-initiate for agency-specified call types from Mobile devices | |||||
| 192.00 | The solution should have the ability to assign or add multiple units to a call with a single command | |||||
| 193.00 | The solution should have the ability to assign a unit to a call to which it was not originally recommended | |||||
| 194.00 | The solution should have the ability to dispatch multiple agency units (e.g., NSP and CapSec) to the same call | |||||
| 195.00 | The solution should have the ability to provide notifications that dispatches have been successfully delivered to Mobile devices | |||||
| 196.00 | The solution should have the ability for users to enter field-initiated calls of any nature | |||||
| 197.00 | The solution should have the ability to add additional units to a field-initiated call (e.g., traffic stop, subject stop) | |||||
| 198.00 | The solution should have the ability to capture unit ID numbers when calls are initiated by units in the field | |||||
| 199.00 | The solution should have the ability for users to utilize a single command to enter a field-initiated call and automatically place the initiating unit in an "at scene" status | |||||
| 200.00 | The solution should have the ability for users to record the following information when a unit is placed in a traffic stop status and the information is available: | -- | -- | -- | -- | -- |
| 200.01 | Location of the stop | |||||
| 200.02 | Vehicle license plate | |||||
| 200.03 | State of registration | |||||
| 200.04 | Driver information | |||||
| 200.05 | Additional narrative comments | |||||
| 201.00 | The solution should have the ability for users to place a unit on a traffic stop and run the vehicle plate in one step | |||||
| 202.00 | The solution should have the ability to geo-validate locations on field-initiated calls | |||||
| 203.00 | The solution should have the ability to capture AVL (automatic vehicle location) coordinates when field personnel initiate a call for service from a mobile device and reverse-geocode to the closest physical address, intersection, or mile marker | |||||
| Call Stacking/Queuing | ||||||
| 204.00 | The solution should have the ability to automatically stack/hold a call for a unit when they are dispatched or assigned to a different call | |||||
| 205.00 | The solution should have the ability to automatically (without user intervention) notify the dispatcher of a held call when the unit becomes available | |||||
| 206.00 | The solution should have the ability for users to hold/stack more than one call to a given unit or resource | |||||
| 207.00 | The solution should have the ability for CAD administrators to turn call stacking on and off | |||||
| 208.00 | The solution should have the ability to stack calls and sort/list based on call priority order | |||||
| Call Preemption | ||||||
| 209.00 | The solution should have the ability to remove a unit from a call and reassign the unit to a new call automatically | |||||
| 210.00 | The solution should notify the field unit via message that they are removing them from an existing call and placing them on a new call | |||||
| 211.00 | The solution should have the option to return a call to a pending queue if all units are removed from an active call | |||||
| 212.00 | The solution should have the ability to visually indicate a preempted call (e.g., by color code or other means) | |||||
| 213.00 | The solution should have the ability to support a swap feature to allow two units to swap (exchange) calls with a single command | |||||
| Standard Operating Procedures / Guidelines | ||||||
| 214.00 | The solution should have the ability to access agency standard operating procedures or guidelines from the CAD application | |||||
| 215.00 | The solution should have the ability to display standard operating procedures or guidelines without overriding the CAD display | |||||
| 216.00 | The solution should allow agencies to create/define their own standard operating procedures or guidelines to include instructions, questions, and checklists that are associated to calls based on call type and location | |||||
| 217.00 | The solution should have the ability to access the standard operating procedures or guidelines based on call type and/or location | |||||
| Unit Management | ||||||
| 218.00 | The solution should have the ability to log one or more units on-duty/off-duty with a single command | |||||
| 219.00 | The solution should have the ability to require agency-defined criteria upon log-on | |||||
| 220.00 | The solution should have the ability to automatically assign a beat to a unit upon log-on | |||||
| 221.00 | The solution should have the ability to define a shift roster | |||||
| 222.00 | The solution should have the ability to place all units in a previously defined shift roster on or off-duty | |||||
| 223.00 | The solution should have the ability for mobile units to log themselves onto the system | |||||
| 224.00 | The solution should have the ability for personnel to be associated with any mobile unit identifier | |||||
| 225.00 | The solution should have the ability to visually distinguish units with multiple personnel | |||||
| 226.00 | The solution should have the ability to indicate a unit that does not have a mobile device | |||||
| 227.00 | The solution should have the ability to place a unit back in service when it is within an agency-defined radius of its station (geofencing) | |||||
| 228.00 | The solution should have the ability to assign a unit to a defined area (e.g., Troop area, beat, etc.) | |||||
| 229.00 | The solution should have the ability to assign a unit to multiple Troop Areas | |||||
| 230.00 | The solution should have the ability to modify a unit's assignment at any time | |||||
| AVL (Automatic Vehicle Location) | ||||||
| 231.00 | The solution should have the ability to support the use of a continuous, real-time AVL (automatic vehicle location) system in CAD | |||||
| 232.00 | The solution should have the ability to auto enroute/auto at scene units based on AVL locations (geofencing) | |||||
| 233.00 | The solution should have the ability for system administrators to turn AVL on/off by: | -- | -- | -- | -- | -- |
| 233.01 | Agency | |||||
| 233.02 | Unit | |||||
| 233.03 | Unit type | |||||
| 234.00 | The solution should have the ability to default to agency-defined settings (e.g., assigned Troop area/beat, assigned station, last known geographic location) for dispatching when the unit's AVL is turned off | |||||
| 235.00 | The solution should have the ability to display the average speed of a vehicle (unit) between two points, when data is polled. | |||||
| 236.00 | The solution should allow for automatically changing a unit status to at scene (geofencing) based on both a primary and secondary radius (e.g., staging location or call location) | |||||
| 237.00 | The solution should have the ability to provide an AVL playback utility based on specific units and a date/time range | |||||
| 238.00 | The solution should have the ability for the AVL playback utility to be utilized outside of the CAD application in a common format or other application | |||||
| 239.00 | The solution should have the ability for the AVL playback utility to show activity on a map | |||||
| 240.00 | The solution should have the ability to generate reports from AVL data, including: | -- | -- | -- | -- | -- |
| 240.01 | Vehicle route | |||||
| 240.02 | Speed along the route | |||||
| 241.00 | The solution should consider agency GIS data to include turnouts and barriers on freeways when making AVL-based unit recommendations | |||||
| Unit Activity Tracking | ||||||
| 242.00 | The solution should have the ability to record all unit activity and assignments | |||||
| 243.00 | The solution should have the ability to record all unit locations, including secondary and staging locations | |||||
| 244.00 | The solution should have the ability to record all unit status changes | |||||
| 245.00 | The solution should have the ability to review unit status history within the application | |||||
| 246.00 | The solution should have the ability to search unit activity by: | -- | -- | -- | -- | -- |
| 246.01 | Unit | |||||
| 246.02 | Call Number | |||||
| 246.03 | Location | |||||
| 246.04 | Date and time range | |||||
| 247.00 | The solution should have the ability for all unit activity to be linked to the call for service record | |||||
| Unit Status Display | ||||||
| 248.00 | The solution should have the ability to monitor an unlimited number of units | |||||
| 249.00 | The solution should have the ability to update unit status (indicate methods for updating unit statuses in the "Comments" field) | |||||
| 250.00 | The solution should have the ability to track and display all unit statuses | |||||
| 251.00 | The solution should have the ability for the agency to define all unit statuses in the system | |||||
| 252.00 | The solution should have the ability to associate a default availability with each unit status (e.g., units are available when in particular statuses) | |||||
| 253.00 | The solution should have the ability to pair units so that if one unit is in a status, the paired unit is automatically placed in the same status (this should apply for any unit status). This function is important for field training officers and trainees who are both logged in with their own radio IDs | |||||
| 254.00 | The solution should have the ability to display the following unit information: | -- | -- | -- | -- | -- |
| 254.01 | Troop area/beat | |||||
| 254.02 | Call type | |||||
| 254.03 | Current call number | |||||
| 254.04 | Current location | |||||
| 254.05 | Status | |||||
| 254.06 | Elapsed time in status | |||||
| 254.07 | Last known location | |||||
| 254.08 | Logged onto Mobile (Y/N) | |||||
| 254.09 | Original location | |||||
| 254.10 | Radio ID | |||||
| 254.11 | Special skills/equipment | |||||
| 254.12 | Station | |||||
| 254.13 | Unit ID/call sign | |||||
| 254.14 | Agency | |||||
| 255.00 | The solution should have the ability to automatically update and display unit statuses | |||||
| 256.00 | The solution should have the ability for users to refine/filter which agency units to display (i.e. specific Troop areas) | |||||
| 257.00 | The solution should have the ability to divide unit status views by any unit information (e.g., all units assigned to a special assignment could be displayed in a separate window) | |||||
| 258.00 | The solution should have the ability to sort displayed data by any unit information (e.g., station, shift, call, unit, location, unit status) | |||||
| 259.00 | The solution should have the ability to visually differentiate units in varying unit statuses with color, text and/or symbol | |||||
| 260.00 | The solution should have the ability to visually differentiate unit types with color, text and/or symbol | |||||
| 261.00 | The solution should have the ability to show units on the CAD map | |||||
| 262.00 | The solution should have the ability to use icons and colors to distinguish unit types and unit statuses on the CAD map | |||||
| Enroute and On-Scene Arrival Tracking | ||||||
| 263.00 | The solution should have the ability to record multiple arrival times associated with different unit statuses (e.g., arrival at a staging area, arrival at scene) | |||||
| 264.00 | The solution should provide for all auto-unit statusing (geofencing) functionality based on AVL to be configurable by each individual agency and not be set at the system level | |||||
| 265.00 | The solution should have the ability to record multiple units arriving: | -- | -- | -- | -- | -- |
| 265.01 | Simultaneously | |||||
| 265.02 | At different times | |||||
| Status Monitoring | ||||||
| 266.00 | The solution should have the ability to initiate call status changes via the following methods: | -- | -- | -- | -- | -- |
| 266.01 | Data fields | |||||
| 266.02 | Function key and/or command line function | |||||
| 266.03 | Mouse click | |||||
| 267.00 | The solution should have the ability to automatically notify users monitoring or displaying a call that information has changed via a visual alert or audible alert | |||||
| Unit Clearance | ||||||
| 268.00 | The solution should have the ability to clear one unit from a call while allowing the other assigned units to remain on the call | |||||
| 269.00 | The solution should have the ability to select any number of units to clear from a call | |||||
| 270.00 | The solution should have the ability to clear all units simultaneously from a call. | |||||
| 271.00 | The solution should have the ability to clear all units from a call using a single command on the command line (e.g., by call #) | |||||
| 272.00 | The solution should allow for users to clear all units and the call with a single command. | |||||
| 273.00 | The solution should have the ability to require a disposition (specified by call type) to be entered prior to clearing the last unit from a call | |||||
| Call Management | ||||||
| 274.00 | The solution should have the ability to monitor an unlimited number of calls | |||||
| 275.00 | The solution should have the ability to add an unlimited number of units to a call | |||||
| 276.00 | The solution should have the ability to allow for an unlimited number of agency-defined call statuses | |||||
| 277.00 | The solution should have the ability to display a window listing pending and held calls entered from any CAD workstation | |||||
| 278.00 | The solution should have the ability to view call details of one or more calls at a time | |||||
| 279.00 | The solution should have the ability to click on an active call and highlight all assigned units in the unit monitoring window | |||||
| 280.00 | The solution should have the ability to show calls on the CAD map | |||||
| 281.00 | The solution should have the ability to use agency-defined colors to distinguish call priority and status | |||||
| CAD Call Updates | ||||||
| 282.00 | The solution should have the ability to query the following upon entry of a name to a call: | -- | -- | -- | -- | -- |
| 282.01 | Niche RMS | |||||
| 282.02 | State/NCIC | |||||
| 283.00 | The solution should have the ability for any authorized user to add new or additional information to a call | |||||
| 284.00 | The solution should have the ability for one or more users to simultaneously add information to a call | |||||
| 285.00 | The solution should have the ability to automatically identify (e.g., ID stamp) the user adding information to a call, along with the date, time, and workstation ID | |||||
| 286.00 | The solution should have the ability to update the status of a call as new information is received including, but not limited to: | -- | -- | -- | -- | -- |
| 286.01 | Call type | |||||
| 286.02 | Call priority | |||||
| 286.03 | Call location | |||||
| 286.04 | Narrative/comments | |||||
| 287.00 | The solution should have the ability to display updated call information automatically after new information is added to an open call | |||||
| 288.00 | The solution should have the ability to simultaneously notify users and field units of updated call information | |||||
| 289.00 | The solution should have the ability to time stamp all updates to a call record | |||||
| 290.00 | The solution should have the ability to attach all state/NCIC system returns to call records | |||||
| 291.00 | The solution should allow users to query state/NCIC systems on behalf of a call and associate the query and returns to the call, if desired | |||||
| 292.00 | The solution should have the ability to attach information to a closed call | |||||
| Reopening CAD Calls | ||||||
| 293.00 | The solution should have the ability to reopen closed calls | |||||
| 294.00 | The solution should have the ability to reopen a closed call without losing previously recorded date and time stamps | |||||
| 295.00 | The solution should accurately report original response times when calls are reopened |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .