Appendix_C_-_Non-Functional_Requirements.xlsx

Instructions State of Minnesota Department of Corrections (MNDOC) Corrections Operations Management Solution (OMS)

The Responder is further encouraged to provide comments, clarification, or references to other areas of the proposal which provide additional details related to the requirement. Responder should NOT rely on references to documents that are not included in the proposal in their response, including URL links to information on the Internet.

Responses in the Response Code column are limited to the choices below. Entry of an incorrect Response Code will be considered unresponsive; if Responder enters multiple Response Codes for one requirement the State may assign a code of its own choosing. Where ‘C’ is the response, the required customization must be fully described, and any additional cost to the State identified in Attachment C: Cost Detail. Where ‘N’ is the response, a full description of all features that the software will not provide and all respects in which it will not satisfy the requirement must be provided. Do not include cost detail in Appendix C. If cost detail is included in this document, the State may disqualify the proposal as non-responsive.

Non-Functional Requirements

(For responses N and C)

The system should provide the capability to perform expungements by authorized personnel.

Architecture Performance/Retention:

The system should provide the capability to support purges/archiving by authorized personnel, in compliance with Department and state retention policies (e.g. reports/filters, dashboard, logs, automated scripting etc.).

Architecture Equipment Integration:

The system should provide the capability to support external data capturing equipment (e.g., card scanners, barcode readers, cameras).

Architecture Multiple Windows:

The system should provide the capability to view multiple windows at a time while maintaining data and session integrity.

Architecture Modifiable:

The system should allow authorized Department staff to easily add new screens and modify existing screens.

Architecture Context-Sensitivity:

The system should provide the capability to dynamically display menus, pages, data fields and functionality based on the security access and roles defined of the user.

a) No more than three seconds ninety-eight percent of the time for any transaction

b) No more than two seconds ninety percent of the time for any transaction

c) No more than one second eighty percent of the time for any transaction

Solution should accept and provide attachments from/to other sources & applications via APIs.

Solution should have the ability to store, index and retrieve attachment files. Solution should associate the attachments to an Client/IP and for the appropriate logical unit within the Client/IP record as ppropriate (for example - signed property sheet document should be associated with the property screen for that Client/IP). The attachment should be readily retrievable and available by the user when accessing the Client/IP record.

API Solution should support APIs for all the major functionalities.

Realtime interfacing via APIs is required to all major functions of the solution.

The APIs should be flexible to allow faster turnaround times for changes and enhancements.

Licensing Solution should include the licensing for all the software stack and any dependent third-party solutions/software.

Explicitly list all licensing that’s covered and if any that’s not covered.

Also explicitly list all dependent infrastructure and software that’s required for operation of the solution.

Describe any third-party relationships or dependencies that would be relied upon for the solution.

Cloud Hosted Solution The solution should be available/implemented on secured government or secured commercial cloud platform

(a) please specify the cloud platform supported (Ex AWS, Azure etc.)

(b) The system and all subcontracted systems should be hosted on (a) certified FedRAMP, cloud-based server(s) for which the the vendor will be fully responsible (O/S upgrades, backups, DRP, etc.)

(c) Comply with Gov Cloud hosting requirements for CJIS data

• Standard naming conventions

• Pointing device support

• Pop-up windows

• Keyboard functionality

• Button navigation

• Drop-down lists

• Auto fill

User Interface Solution User Interface should use Responsive design and be compatible with tablets and mobile devices.

UI should adapt and respond to user device’s screen size and orientation.

Availability Solution should support high availability configurations. Please specify/describe your approach to provide high availability. The Offender Management System is a round-the-clock system (7 x 24 x 365) that should have reliability and high availability. The system may operate in a reduced capacity should an issue such as hardware failure occur. In such a case, no data is lost or corrupted and the user can perform all system functionality, albeit with slower response times. Provide details of the solution’s High Availability architecture. Solution should support up time of 99.9%.

Solution should be available and operational, except for predefined patching & updating downtime windows.

Upgrades, patching and rollbacks should be completed in the predefined time windows.

Describe any CI/CD solutions that the solution may be implementing.

Availability Should support Active-Active and Active-Warm highly available deployment models.

Solution should support clustering within a Datacenter as well as multi center support.

Solution should incorporate appropriate Load Balancing mechanisms.

Availability The vendor should specify/describe disaster-recovery options for consideration by commonwealth for this mission critical application.

Solution should restore from varied disaster events, including but not limited to Data center outages, connection outages and infrastructure failures.

Solution should support backup and recovery to/from a cold storage.

Solution should demonstrate disaster recovery from failures within predefined RTO and RPO parameters Provide details of any Single Point of Failures

Security Solution should support Role Based Access Controls (RBAC) application security model.

Access to various functionalities within the solution should be controlled based on the user roles.

Solution should provide User Interface to manage the RBAC roles and access to resources/functionality of the system.

The system should allow the ability of user to switch their primary institution assignment.

Security Solution should support field level masking and provide a means to configure fields that need masking.

Based on Security requirements certain fields should be masked while displaying in the UI, solution should provide ability to mask fields.

Example: only last few digits of SSN should be displayed in UI but other digits are masked.

Security Solution should support detailed Audit Logging, as to Who has access to What.

- Log Integrity should be maintained. Restrict tampering and editing of Audit logs.

- Export/Stream Audit log events to centralized logging (Ex: Splunk)

The system should have ability to flag Client/IP as restricted; thereby, limiting user access.

The system should have ability to search/print

- screens a user has accessed within a date range.

- Client/IPs a user has accessed within a date range.

The system should discourage deletion of user profiles and adhere to MN Retention Policy.

security - account Account Security The system should provide the capability to create role-based user groups.

security - account Account Security:

The system should provide the capability to assign access rights levels to role-based user groups.

security - account Account Security:

The system should provide a user profile/user group management tool.

security - account Account Security:

The system should have the ability to apply a common set of security policies across all functional areas. The system should be completely integrated, so security policies (privileges of groups and business rules) need only to be applied once, though they may affect multiple functional areas.

The system should have the ability to provide a history of access for specified records, as defined by Department, including such items as: the date and time a record was viewed or changed, data values before change (if applicable), action type (e.g., read, insert, update, deactivate), data values after change (if applicable), and the user that performed the change.

Security-audit Audit:

The system should have the ability to provide a historical log of all transactions with external interfaces.

Security-audit Audit:

The system should provide the capability to generate and view audit trails at defined levels, such as record, user, office, site, facility, and agency-wide.

Security-audit Audit:

The system should provide the capability to generate and view a system-level audit trail.

Security-audit Account Management:

The system should provide the capability to restrict the number of active sessions allowed for a single user.

Security-audit Session Management:

The system should provide the ability for authorized Department technical staff to terminate sessions.

Security-audit Audit:

The system should have the ability to provide a date and time-stamp on all transactions.

Security-audit Audit:

The system should provide an audit log of transaction errors.

Security-audit Audit/Performance:

The system should support long-term storage and archival capability for historical information (e.g., Department defined threshold for storing audit logs).

Security-audit Audit:

The system should provide the capability for system administrators to identify (via the system logs) all information about logged-on users including unique user id, user name, session id, terminal id, time logged on, time logged off, transaction committed and unsuccessful transactions.

Integrate with Identity and Authentication systems and can parse tokens generated by the IDM systems. System should be able to extract ID values and roles from tokens generated by Identity and Authentication systems.

Requirements for data feeds and transformations will be provided but it is possible for these to undergo modification during execution of the project.

The solution should be flexible and configurable to accommodate changing data feed requirements, in an acceptable timeframe.

Interfaces The vendor should describe how the vendor’s solution will support the existing interfaces with each of the interface partners. The vendor should include information on the supported file formats, file encryption and configurability of these interfaces.

Inmate Trust Accounting reconciliation reports

• Work/program overdue evaluation report

• Client/IP religious preferences by unit

• Turn-out rosters by unit

• Community Correction reports

• Counsel and Treatment comparison of demographics of Client/IPs and treatment as it relates to recidivism

• Others as defined by DOC.

· Requirements, Business and System use cases etc.

· User Guides, user manuals

· Operations Guides / Runbooks

· Detailed Architecture documents: Logical, Network, Component, Deployment, etc.

· Detailed Interface document with Data model per interface

· Database Schema and Data Dictionary

· Release Notes for every major/minor release with detailed log of changes

· List of software/libraries stack used

· Entity Relationship models

· Design documentation

· Online Help

· Release Notes

· Upgrade and Migration Documentation Feedback Solution should have ability to Solicit Feedback from the users in at least two aspects. - Ease of use in graded scale rating Open ended comments, feature suggestions and feedback Streaming Solution should offer the framework for streaming of relevant functional events to pub/sub mechanisms. Example: Stream new Client/IP record creation event.

Events can be published to a streaming solution, like Kafka, RabbitMQ etc., and will be subscribed & consumed by various downstream systems.

Solution should provide & support post incident Analysis and detailed unscheduled outage reports and analysis.

Secure Remote Administration The solution should allow for secure remote administration as well as on-site administration. The administration functions should include at a minimum:

· user account and password management,

· system security management,

· system log review and maintenance,

· system reports,

· notification management,

· software threshold parameter management,

· system and database backup initiation.

· segregation of administration duties The system should maintain a historical record of all changes made to the system’s components. It should ensure that system error and events for software, hardware, interfaces, operating system, and network are written to a system event log accessible and searchable by a system administrator. The system administrator should be able to easily monitor the system status directly or remotely.

Support Should support detailed logging and streaming of application logs to centralized logging (Ex: Splunk, ELK, etc.)

Logs should contain context and required information for operational and production support teams to troubleshoot issues.

Granularity of logging should be dynamically configurable.

The Testing team needs Production Data to validate and test certain use cases. Access to a production replica dataset is required.

· End Users of the system (Train the Trainer)

· Production Operational Team

· Application Administrators

· Interface Developers The vendor should describe the training methodology and training plan.

1. Module

2. Tab

3. Field

4. Report

5. Data - This solution would need to allow users access certain IP data, locations, programs, incidents The solution should integrate multiple assigned roles, applying a resulting set of access permissions that is predictable, consistent, and well documented.

The solution should provide management tools including the ability to print summary reports of roles, access permissions, and accounts to whom each role is granted.

The solution should provide audit logs and a suitable way to track and report changes to permissions, roles, application table maintenance and integrity actions The solution should provide the ability to add/edit roles.

The solution will include an internal “early alert/warning system” to identify irregularities of a user/access.

CJIS flag to indicate users having completed CJIS security/training

Manage Information Technology Capability 2 The solution should provide the ability to easily modify the contents of all tables used to control data consistency, including, but not limited to:

1. Drop down tables

2. Housing (unit, room, and bed) tables

3. Classification

4. Count Locations

5. Run time parameter table

6. Screening questions, answers and scoring

7. Statutes Manage Information Technology Capability 3 The proposes solution should provide the ability to perform, store, track, and report on:

1. Add/modify table of charges

2. Deletion of any information (e.g., Discipline Reports, Incident reports, Client/IP photos)

3. Expunge a booking

4. Reverse a release

5. Merge duplicate visitor ID’s

6. Merge duplicate Client/IP ID’s

7. Perform other integrity functions as the application may dictate Provide the ability to manage all of the data being entered into the system, to ensure the data coming out at the end is accurate and complete. This should also be captured in user profiles, e.g., who can do these things.

Manage Users Capability 1 The solution should provide the ability to perform store, track and report on all users including:

1. Employee ID

2. Suffix Last Name

3. First Name

4. Middle Initial

5. Preferred Pronoun

6. Logon ID

7. Password

8. Active/inactive status

9. Account creation date

10. Account inactivated date

11. User should change password at next logon

12. All user activity 13 status of Locked to differentiate those staff no longer employed from those whose log on’s have lapsed 14 Include type of account (i.e. default of DOC, Parole, [specific] vendor, etc.)

15 History of name changes 16 User e-mail

17. Time and Date of user changes

1. Identify next process

2. Identify completed processes

3. Alert/Notify functional areas/users of pending transactions

1. User ID

2. Time Stamp

3. Workstation ID

&D&T

&Z&F&A &P of &N