Spreadsheet: 189e7500-2c3c-451b-8252-51033e8fccb9
Sheet: Global

Spokane County Request for Proposals #P8705
Public Safety Information Systems Replacement Project
Global System Functional Requirements
 | Global_System_Features
 | Code Table Administration
 | Security_Admin
 | Logons
 | User_IDs
 | Audit_Trails
 | Global Report and Query Features
 | Online_Documentation
Item # | Global Functional Requirements | C | N | A | M | T | Comments
1 | Global System Features
 | Ability to provide the user with feedback as to the success or failure of a system task, including, but not limited to:
 | Audible alert
 | Visual alert
 | Other
 | Ability to continue work in progress during alert (i.e., alert does not "lock out" user from continuing work in progress) .
 | Ability for system to automatically adjust number sequencing for new calendar years.
 | Ability for system to automatically account for daylight savings time and any required parameter changes to daylight savings.
 | Ability to date and time stamp all system transactions.
 | Ability to have a single master time stamp for all application components.
 | Ability for system administrator to add supplemental fields.
 | Ability to operate in a standard Windows operating system.
 | Code Table Administration
 | Ability for the County to define codes for drop down menus (e.g., BN for brown, BL for blue, etc.).
 | Ability to support code table sets defined by each discipline (e.g., law enforcement has a separate code table than fire).
 | Ability to support code table sets defined by each agency within each discipline (e.g., Sheriff's Office would have different code tables than City Police Department).
 | Ability to support aliases for code tables (e.g., Sacred Heart Hospital, SHH, SHMC, etc.) defined by the County.
 | Ability for the County to maintain code tables, without contacting vendor.
 | Ability to make changes and additions to the code tables without modification to or recompilation of the application software.
 | Ability to share code tables among application components.
 | Ability for code table updates to propagate throughout the system (e.g. an update in a code table for one application component updates the same code table in other application components).
 | Ability to designate code table values as obsolete and unavailable for current use, preventing further entry of that value, yet retain the value in the table for inquiries on historical data.
 | Ability to create a new code and merge/link historical records to a new code.
 | Ability to store the date a code table value becomes obsolete.
 | Ability to store the date a code table value becomes effective.
 | Ability to prevent display of obsolete code table values on drop down lists.
 | Ability to sort and search code tables.
 | Security Administration
 | Ability to comply with all NCIC software/application security requirements.
 | Ability to encrypt data transmissions, per NCIC requirements.
 | Ability to create multiple security groups.
 | Ability to assign personnel to security groups.
 | Ability to assign users to multiple security groups.
 | Ability for agencies to define access permissions for each security group.
 | Ability to view, add, maintain, modify and delete user profiles based on:
 | Agency
 | Security group
 | User ID
 | User name
 | Any combination of the above
 | Ability to tie security to personnel module for automated security provisioning driven by certification status (e.g., NCIC certification).
 | Ability to restrict user access or security group access to files and data fields for specified transactions:
 | Add/create
 | Attach to email or send via other electronic method
 | Delete
 | Inquiry
 | Modify
 | Print
 | View
 | Ability to separately secure add, modify, delete, and inquiry functions.
 | Ability to maintain an archive of all deleted information.
 | Ability to query the archive of deleted information.
 | Ability to provide security at the following levels:
 | Application
 | Database
 | Field
 | Record
 | Screen/Transaction
 | System
 | Ability to create temporary security profiles.
 | Ability to tie security profiles to Active Directory user groups.
 | Ability for applications to work independently in the event [NAME] becomes unavailable.
 | Ability to support alternate authentication technologies (i.e., ID card, security token, biometrics, etc.).
 | Ability to flag a data element as confidential information for security purposes.
 | Ability for users who are not authorized to access confidential information to see that the information exists, but not view the actual information.
 | Logons and Logoffs
 | Ability to support a single user logon ID and password across all proposed applications.
 | Ability for system administrator to change user IDs.
 | Ability to remotely log out a workstation (mobile or desktop).
 | Ability to identify method of log-on (e.g., desktop, remotely, etc.)
 | Ability to be logged onto multiple workstations at the same time (e.g., logged into mobile computer in a vehicle and logged onto a station computer at the same time):
 | Different types of workstation (e.g., desktop and laptop)
 | Same types of workstations (e.g., two desktops)
 | Ability to track user logon/logoff times and locations for time reporting purposes.
 | Ability to support LDAP or Active Directory authentication.
 | Ability to support two-factor logon.
 | Ability to automatically logoff a user after a County-defined predetermined period of inactivity.
 | Ability to disable automatic logoff for secured workstations.
 | Ability to save user's data or session prior to automatically logging off the user.
 | Ability to tie security to both device and user (e.g., both the workstation and User ID both require NCIC access)
 | User IDs and Passwords
 | Ability for the County to define password and user ID creation criteria.
 | Ability to require passwords be changed at County-defined intervals, by user, with the ability to set a global maximum time.
 | Ability to require passwords to be changed at a County-defined date.
 | Ability to maintain a history of de-activated user IDs.
 | Ability to disable password expiration feature.
 | Ability to produce auto-notification of impending password expiration.
 | Ability to enforce passwords per NCIC requirements.
 | Ability for individual system users to change their own passwords.
 | Ability for system administrator to add and delete users.
 | Ability to deactivate/disable a user as opposed to delete a user.
 | Ability for system administrator to disable an account.
 | Ability for system administrator to re-enable an account.
 | Ability to mask passwords when typed.
 | Audit Trails
 | Ability to create a security group defining who has audit trail access permissions.
 | Ability to maintain an audit trail at the following levels:
 | Individual
 | Record
 | Module
 | Application
 | Workstation
 | Ability to view all audit trail records.
 | Ability to log all actions including, but not limited to :
 | Changes
 | Updates
 | Errors
 | Attempted breaches
 | File maintenance transactions (e.g., create, read, add, update, delete transactions)
 | Inquiries to all internal and external systems
 | Print jobs
 | Override
 | Successful sign-on
 | Unsuccessful sign-on attempts
 | Ability for the County to configure which transactions are recorded in the audit log.
 | Ability to store audit trail data including, but not limited to:
 | User ID
 | User name
 | Terminal ID
 | IP address
 | Workstation
 | Printer ID
 | Security level
 | Date and time stamp
 | Transaction type
 | Before and after values of modified data
 | Ability to review all computer activity performed by a specified user during a period of time.
 | Ability to log all vendor access to system (e.g., record a description of all vendor activity).
 | Ability to maintain historical data based on a County-defined length of time.
 | Ability to maintain file history so that field value changes can be viewed both before and after change occurred.
 | Ability to set audit log purge criteria.
 | Ability to perform purge based on criteria.
 | Ability to display audit trail data in a sequential manner.
 | Ability to export audit trail data to standard formats.
 | Ability to date, timestamp, view and audit all inquiries.
 | Ability to comply with NCIC III logging requirements.
 | Ability to view audit trails online.
 | Ability to pull up a record and  see:
 | Who made last change to record
 | Time and date stamp of last change to record
 | Modifications made to record (before and after values)
 | Ability to extract reports from the audit trail.
 | Ability to secure audit log from user tampering.
 | Ability to archive audit trails based on transaction type and/or date.
 | Ability to manually archive information based upon user-specified parameters (time, file size, etc.).
 | Global Report, Query and Search Features
 | Reporting
 | Ability to provide a native reporting tool that can:
 | Create reports based on any operational data field in any system database
 | Create reports based on multiple operational data fields in any system database
 | Allow the end user to design report format
 | Access multiple files and tables
 | Ability for the report generating tool to handle:
 | Arithmetic operations, including fractiles and percentiles
 | A full suite of statistical operations
 | Logic operations
 | Ability to maintain a general library of user-created reports.
 | Ability to preserve all user-created reports during updates and upgrades.
 | Ability for all authorized users to access the general library of user-created reports.
 | Ability for users to put their own reports in a "dashboard" for later use.
 | Ability to send reports to individuals or groups (via system or agency email).
 | Ability to copy an existing report and modify certain data values (e.g., existing report serves as a template for a new report).
 | Ability to generate reports on a pre-determined schedule.
 | Ability to automatically send scheduled reports to distribution groups.
 | Ability to import data from standard types, including but not limited to the following data sources:
 | CSV
 | Standard MS Windows applications
 | Standard image files
 | Excel
 | CDW
 | Ability to export data from standard document types, including but not limited to the following data sources:
 | CSV
 | Standard MS Windows applications
 | Excel
 | Standard image files
 | CDW
 | Queries
 | Ability to query upon any data element stored within the database.
 | Ability to run a query on:
 | Report number
 | Incident number
 | ORI
 | Officer information, including:
 | Name
 | ID
 | Unit number
 | Agency type
 | Incident type
 | Date
 | Date Range
 | Name information, including:
 | Name
 | Identification number (driver's license, social security number, etc.).
 | Phone number
 | Address information, including:
 | Exact address
 | Street
 | Business name
 | Common name
 | Intersection
 | Address range
 | Vehicle information, including:
 | Vehicle identification number
 | License plate number
 | Make
 | Model
 | Color
 | Any standard vehicle identifier
 | Ability to search and query all appropriate databases with one query request.
 | Ability to provide check boxes for users to indicate which databases to query.
 | Ability to perform ad hoc queries
 | Ability to set County-defined defaults for databases to query within each application.
 | Ability for query returns to indicate the information source (e.g., NCIC, RMS, etc.).
 | Ability to select any result from a query and drill down for detailed information (e.g., hyperlink).
 | Ability to save queries for later use.
 | Ability to search on any operational data field.
 | Ability to search on multiple operational data fields.
 | Ability to search narrative fields.
 | Ability to exclude specified text when conducting narrative text searches.
 | Ability to conduct searches based on:
 | Soundex
 | "Wild cards"
 | Microsoft Wildcard set
 | Exact match
 | Partial information
 | Boolean operators (e.g., "and," "or," "not", etc.)
 | Date ranges
 | Ability to narrow down searches (search within a search).
 | Ability to select any result from a search and drill down for detailed information (e.g., hyperlink).
 | Ability to restrict searches that result in large volumes of data by:
 | Providing a warning of the size of records found
 | Requesting users to prompt the system to continue the search
 | Requesting users to prompt the system to cancel the search
 | Online Documentation
 | Ability to access an online help menu.
 | Ability to provide context-sensitive help in the form of prompts and instructions.
 | Ability to provide training modules through help menu.
 | Ability to search help files by keywords.
 | Ability to provide help facility via function key or icon from any screen or field within any application.
 | Ability to edit text in help files to address County-specific topics.
 | Ability to maintain online the County-specific documentation and procedures, including:
 | Glossary of terms
 | Glossary of error codes
 | Ability to provide a recommended  course of action upon encountering an error.
 | Ability to augment vendor-supplied online help tables with additional information (e.g., add notes to a topic that are viewable along with the vendor-supplied information).
 | Ability for help file to automatically update at the time of all version/release updates.
 | Ability to prevent software updates from overriding County-specific online documentation and help files.
 | Ability for system administrator to create error messages.
 | Ability for system administrator to edit error messages.
 | Ability to track revisions to online documentation and help files, including:
 | User ID
 | Date and time
 | Ability to provide help files in a Windows help format.
 | Ability to bookmark topics by:
 | Individual
 | Agency