The file's text, extracted by GovTribe without its formatting.
Exhibit 1 – CDFW California Monitoring Program Requirements Requirements The following table lists the key functional/non-functional requirements. Collectively, these requirements define the functional/non-functional aspects of the proposed solution.
Requirements are prioritized as follows:
M (Mandatory) – Absolutely vital features; project shall be canceled if not included regulation required functionality.
R (Required) – Features are not essential, but together they affect the viability of the project; additional functionality not specified by regulation; category of functionality that may be optional or a later system enhancement.
D (Desired) – One or more of these features could be omitted without affecting the project viability; nice-to-have function (e.g., bells and whistles); high-cost unique requirements.
VE (Vendor Evaluation) – The requirement will be used to evaluate additional functionality of the vendor solution.
Vendor Instructions: Analyze each requirement and determine the degree to which you meet the requirement and place an “X” in the appropriate “Requirement Met” column. Options are:
Y (Yes) – The requirement is satisfied in its entirety.
P (Partial) – The requirement is partially satisfied. Provide comments in the “Vendor Comments” Section and explain how the requirement is partially satisfied, if the requirement can be met with configuration or customization (please include discussion of time and fees to configure or customize the solution to meet this requirement), or if the requirement will be fully met in a new version of the product (please include the timeframe the new version will be available).
N (No) – The requirement is not met. If needed, provide comments in the “Vendor Comments” Section and explain if the requirement can be met with configuration or customization (please include discussion of time and fees to configure or customize the solution to meet this requirement), or if the requirement will be fully met in a new version of the product (please include the timeframe the new version will be available).
| ID |
| Requirements Description |
| Priority |
| Requirement Met? |
| Vendor Comments |
| 1.1 |
| The system shall be a web-based system. |
| M |
| 1.2 |
| The application shall be designed to provide access to a minimum of 36 users. |
| M |
| 1.3 |
| CDFW staff designated as developer and admin users shall be able to identify the number and identities of CMP users and add, remove, and change permissions of users as needed. |
| M |
| 1.4 |
| Permission groups shall be established to manage access, editing, extracting, and visibility of datasets and fields. |
| M |
| 1.5 |
| Multiple concurrent users shall be able to upload, enter, view and extract data. |
| M |
| 1.6 |
| The system must have separate development, test, and production environments. |
| R |
| 1.7 |
| The web application shall utilize Microsoft technology where possible, excluding Microsoft Access. |
| D |
| 1.8 |
| The web application shall follow the State’s standards for ADA compliance. |
| M |
| 1.9 |
| The web application shall utilize the current version of the State web template. |
| M |
| 1.10 |
| The application shall be maintained by the DTD IT Systems Branch Marine-Fisheries Unit (MFU). Any technology used shall be technology already familiar to MFU or technology where needed training can occur during the project. |
| M |
| 1.11 |
| The application shall be built in a way that future enhancements and bug fixes can be made by the Marine Fisheries Unit, not requiring any technical work by other CDFW staff. |
| M |
| 2.0 |
| Data Entry Requirements |
| 2.1 |
| CDFW employees with access to the application shall be able to enter data from paper or electronic forms into the application in an efficient manner. |
| R |
| 2.2 |
| Authorized users shall use a web-based data entry interface for data entry, which may consist of a single, customizable interface or multiple interfaces, depending on the survey type. |
| M |
| 2.2.1 |
| The data entry interface shall be intuitive and user-friendly, minimizing training time and reducing data entry errors. |
| R |
| 2.2.2 |
| The application shall provide clear field-level guidance or tooltips to assist users in understanding required data formats and expected inputs. |
| D |
| 2.2.3 |
| All mandatory data fields shall be clearly indicated to the user, and validation rules shall stop users from completing entries missing these values. |
| R |
| 2.2.4 |
| The system shall utilize appropriate input controls (e.g., date pickers, dropdowns, checkboxes, numeric input only) based on the data type of each field. |
| R |
| 2.2.5 |
| Where applicable, the system shall offer auto-population or lookup functionalities for common entries (e.g., species names, etc.) to reduce manual input and ensure consistency. |
| D |
| 2.3 |
| The application shall include functionality for batch uploading .csv files of data from Pendragon forms or other intermediary sources, which may include Excel or .csv files. |
| M |
| 2.3.1 |
| The system shall provide downloadable templates for batch data uploads to guide users on the required format and fields. |
| D |
| 2.3.2 |
| The system shall clearly indicate which records, if any, failed during a batch upload and provide reasons for failure, allowing for correction and re-upload of only the problematic records. |
| M |
| 2.3.3 |
| A document upload pathway for accessory document storage shall be made available through the data entry interface. |
| R |
| 2.4 |
| Data validation rules shall be implemented, which shall occur at the point of data upload or entry. |
| M |
| 2.4.1 |
| Errors shall be highlighted immediately on the data entry screen (e.g., red border, error message) when a user attempts to leave a field or save a record. |
| D |
| 2.5 |
| Errors shall prevent records from being saved or committed to the database until corrected. |
| R |
| 2.5.1 |
| Validation rules shall include but not be limited to: |
* Ensuring all mandatory fields contain data.
* Ensuring data conforms to expected types (e.g., numeric for numbers, date for dates).
* Ensuring numeric values fall within specified minimum and maximum ranges.
* Ensuring data adheres to specific patterns (e.g., email format, specific ID patterns).
* Validating input against predefined lists of values or existing data in lookup tables.
* Validating data against other related fields within the same record (e.g., end date after start date).
R
| 2.6 |
| Authorized users shall be able to perform data QA/QC processes. |
| R |
| 2.6.1 |
| The system shall support customizable workflows for data quality assurance and quality control (QA/QC), allowing designated users to review, flag, and correct data. |
| D |
| 2.6.2 |
| The system shall provide tools for reporting, tracking, and resolving data errors identified during QA/QC. |
| D |
| 2.6.3 |
| The system shall maintain a detailed audit trail of all data modifications, including who made the change, what was changed, and when. |
| D |
| 2.7 |
| Data upload notification alerts shall be sent to the person who completes the upload, as well as the CDFW Fisheries Branch CMP coordinator, after the uploading process is complete. |
| D |
| 2.7.1 |
| Notifications shall include details such as the success/failure status of the upload, the number of records processed, and any identified errors. |
| D |
| 2.7.2 |
| The system shall allow for configuration of additional notification recipients based on user roles or project assignments. |
| D |
| 2.8 |
| The process for entering data shall avoid duplicative work by staff wherever possible. |
| D |
| 2.8.1 |
| The system shall facilitate the reuse of common data elements (e.g., site locations, project details) across different data entry forms or projects. |
| R |
| 2.8.2 |
| Where feasible, the system should integrate with existing authoritative data sources to pull in relevant information rather than requiring re-entry. |
| R |
| 2.8.3 |
| Core project and site information should only need to be entered once and then referenced by other data collection activities. |
R
| 3.0 |
| Database Requirements |
| 3.1 |
| The existing SQL transactional database for the current CMP application (version 1.1) shall also be used for the new application. |
| M |
| 3.1.1 |
| The database system shall be designed and configured to ensure optimal performance, supporting concurrent users and rapid data retrieval and storage, even as data volume grows. |
| M |
| 3.1.2 |
| The database architecture shall be scalable to accommodate significant future growth in data volume and the number of concurrent users without requiring major re-architecture. |
| R |
| 3.2 |
| Data storage shall be centralized, with all necessary data tables residing in one transactional database. |
| M |
| 3.2.1 |
| The database shall enforce referential integrity to ensure relationships between tables are consistently maintained, preventing orphaned records and ensuring data accuracy. |
| M |
| 3.2.2 |
| The database schema shall follow appropriate normalization principles to minimize data redundancy and improve data integrity. |
| D |
| 3.2.3 |
| Storage for accessory documents shall be created. |
| R |
| 3.3 |
| The existing database schema shall be updated by the addition or removal of tables and fields, as needed. |
| M |
| 3.3.1 |
| All schema changes (additions, removals, modifications) shall be thoroughly documented, including rationale and impact assessments. |
| D |
| 3.3.2 |
| A robust version control system shall be used to manage and track all database schema changes. |
| R |
| 3.4 |
| The application shall include the data currently available in the CMP SQL database, the CMP Population Data, data tables from the CMP Survey Management Switchboard, and data from any other added tables or fields in a single application. |
| M |
| 3.4.1 |
| The integrated application shall ensure that the centralized SQL database serves as the single authoritative source for all CMP data, eliminating data silos. |
| R |
| 3.5 |
| The database system shall include robust backup and recovery mechanisms to protect against data loss. |
| M |
| 3.5.1 |
| The database system shall allow for full and incremental backups of the database and shall be performed regularly (e.g., daily full backups, hourly incremental backups) with a defined retention policy. |
| R |
| 3.6 |
| The database shall implement strong security measures to protect sensitive CMP data. |
| M |
| 3.6.1 |
| Role-based access control (RBAC) shall be enforced at the database level, ensuring users can only access data relevant to their assigned roles and permissions. |
| M |
| 3.6.2 |
| Data shall be encrypted both in transit (e.g., via SSL/TLS for connections) and at rest (e.g., transparent data encryption for sensitive tables/columns) if deemed necessary for compliance or data sensitivity. |
| M |
| 3.6.3 |
| The database shall log all significant data access and modification events for auditing purposes. |
M
| 4.0 |
| Security Requirements |
| 4.1 |
| The system shall meet Federal and State laws, policies, and regulations for security, privacy and confidentiality of data as outlined in State of California Statewide Administrative Manual (SAM) 5300 and National Institute of Standards and Technology (NIST) SP 800-53 (rev 4). |
| M |
| 4.1.1 |
| The system shall be designed to undergo regular security audits and penetration testing to identify and remediate vulnerabilities. |
| M |
| 4.1.2 |
| The system shall be designed and developed with privacy-enhancing technologies and practices, ensuring data minimization, purpose limitation, and data subject rights. |
| R |
| 4.1.3 |
| The system shall support data classification to ensure appropriate security controls are applied based on the sensitivity and criticality of the information. All data handling procedures shall align with CDFW's data classification policy. |
| R |
| 4.2 |
| The system shall support Federated Identity single sign-on security controls, such as strong passwords, two-factor authentication, and restricted access to specific screens, fields and processes. |
| R |
| 4.3 |
| The system shall provide the ability to define and grant/revoke different levels of access to the system based on defined user roles ensuring the principle of least privilege is enforced (users only have access to what they absolutely need). |
| M |
| 4.3.1 |
| The system shall implement secure session management, including automatic session termination after a period of inactivity and preventing session hijacking. |
| R |
| 4.3.2 |
| User credentials (e.g., passwords) shall be stored securely using industry-standard hashing algorithms and salting. |
| M |
| 4.3.3 |
| User roles shall include: |
1. Developer (1) – Access to full database. Can add/edit/remove admins, designers, and users and assign designers and users to projects. Can update database schema, backend, and frontend and perform database maintenance. Limited to CDFW DTD staff only.
1. Admin (4) – Access to full database. Can enter/upload, edit, query, and download data and edit and download lookup tables. Can add/edit/remove admins, designers, and users and assign designers and users to projects. Limited to CDFW staff only.
1. Designer (~15) – Access limited to specified projects only. Can enter/upload, edit, query, and download data and edit and download lookup tables. Limited to CDFW staff only.
1. Super User (~5) -Access limited to specified projects only. Can only enter/upload data and edit and download lookup tables. Super Users can be internal or external to CDFW.
1. User (~10) – Access limited to specified projects only. Can enter/upload data and download lookup tables only. Users can be internal or external to CDFW.
1. Read-Only (1) – Access limited specified projects only. Can view and query data. Limited to CDFW staff only.
R
| 4.4 |
| The system shall provide the ability to track and report auditing, including the ability to track and monitor users access actions, changes and modifications by date and time and make this information available to authorized user roles. |
| R |
| 4.4.1 |
| Audit logs shall capture sufficient detail to reconstruct key events, including successful and failed login attempts, data access, modifications, deletions, and system configuration changes. |
| R |
| 4.4.2 |
| Audit logs shall be protected from unauthorized modification or deletion. |
| R |
| 4.4.3 |
| The system shall have the capability to generate alerts for suspicious activities detected in audit logs (e.g., multiple failed login attempts, unusual data access patterns). |
| R |
| 4.5 |
| The system shall provide self-service account management functionalities. Some of these functionalities include but are not limited to: |
1. Account creation requests (creation, review, approval)
1. Application/role requests (request, review, approval)
1. Provide users with the ability to update their personal information, but all changes must be reviewed and certified by an administrator before being finalized. Account assistance functions (password reset via question and answer, email/text/mobile application, image specification and recognition, one-time passwords)
1. Two-factor authentication (e.g., text message, email, or token-based authentication) R
| 4.5.1 |
| All account and role requests shall follow a defined approval workflow, ensuring appropriate authorization before access is granted. |
| R |
| 4.5.2 |
| Users shall be able to change their own passwords securely, adhering to password complexity policies. |
| R |
| 4.6 |
| The system shall expire all accounts based on pre-set intervals with application specific or user types/roles maximums. Security based administrative override for account disabling will lock accounts completely without options for 1st or 2nd level help desk assistance (requiring Information Security Office (ISO) or system admin level approval for re-activation). |
| R |
| 4.6.1 |
| The system shall automatically deactivate accounts that remain inactive for a configurable period. |
| D |
| 4.6.2 |
| A clear and secure process shall be defined for reactivating disabled accounts, ensuring proper verification and authorization. |
| R |
| 4.6.3 |
| The system shall support the immediate deactivation of user accounts to prevent access by former CDFW or partner organization personnel. |
| M |
| 4.6.4 |
| All data transmitted between the user interface and the system, and between system components, shall be encrypted using industry-standard protocols (e.g., TLS 1.2 or higher). |
| R |
| 4.6.5 |
| Sensitive data stored within the database and on file systems shall be encrypted at rest (e.g., Transparent Data Encryption, file-level encryption). |
| R |
| 4.6.6 |
| The development and operational processes shall include a comprehensive vulnerability management program to identify, assess, and mitigate security vulnerabilities in a timely manner. |
| R |
| 5.0 |
| Business Analytics and Reporting Requirements |
| 5.1 |
| The application shall include an interface allowing users to extract CMP data. |
| M |
| 5.1.1 |
| Users shall be able to generate custom data extracts, filtering data on specified tables and fields and generating the extract as common formats like text (CSV, Excel, TXT, etc.). |
| M |
| 5.1.2 |
| Users shall be able to generate custom views relative to data extracts with functionality similar to Microsoft Access Query Builder, enabling intuitive query creation without direct SQL knowledge. This includes features like drag-and-drop table/field selection, join specification, filtering, and sorting. |
| R |
| 5.1.3 |
| The application shall provide access to a data dictionary or metadata, allowing users to understand the meaning, format, and relationships of fields before performing extractions. |
| R |
| 5.1.4 |
| API access shall be established to the backend database for select users. |
| M |
| 5.2 |
| The application shall restrict direct public access to sensitive data, including the identities of data recorders. |
| M |
| 5.2.1 |
| The system shall support mechanisms for anonymizing or aggregating sensitive data for public reporting, ensuring individual privacy is maintained. |
| D |
| 5.2.2 |
| The system shall enforce strict role-based data visibility, ensuring users only see data they are authorized to access, even within reporting interfaces. |
| M |
| 5.3 |
| Users shall have access only to the data for their specific survey, with the exception of identified CDFW CMP administrators and developers, who shall have access to all CMP data. |
| M |
| 5.4 |
| The application shall allow authorized users to view and download all data over time related to their survey(s), rather than access to data within a specific year. |
| R |
| 5.5 |
| The application shall allow authorized users to submit queries to the centralized data store. |
| R |
| 5.5.1 |
| The system shall ensure that user-generated queries execute efficiently and return results in a timely manner, even for large datasets. |
| R |
| 5.5.2 |
| Authorized users may have the option to save frequently used custom queries for future use or share them with other authorized users. |
| R |
| 5.5.3 |
| The application must include a set of standard reports for common CMP data analysis. |
| D |
| 5.5.3 |
| The system shall allow authorized users to schedule reports to be sent to specific recipients on a recurring basis. |
| D |
| 6.0 |
| System Testing Requirements |
| 6.1 |
| The selected vendor shall prepare a Requirements Traceability test plan for all implemented software modules. This plan must demonstrate how each system requirement is linked to one or more test cases. |
| M |
| 6.2 |
| The selected vendor shall prepare a User Acceptance Test Plan with input from CDFW program staff. This plan must outline specific scenarios and criteria that CDFW users will use to validate the system that meets their business needs. |
| M |
| 6.2.1 |
| The vendor shall conduct a comprehensive suite of tests, including, but not limited to: |
1. Functional Testing: All features and functionalities of the application shall be thoroughly tested to ensure they perform as specified in the requirements. This includes testing all data entry screens, upload processes, query builders, and reporting functions.
M
| 6.2.2 |
| 1. Integration Testing: All integrated components and modules (e.g., database, web interface, SMS application, external interfaces) shall be tested to ensure they communicate and function together seamlessly. |
| M |
| 6.2.3 |
| 1. Performance Testing: The system shall undergo performance testing to ensure it meets specified response times, throughput, and resource utilization under expected and peak load conditions. This includes testing data upload speeds, query execution times, and concurrent user performance. |
| M |
| 6.2.4 |
| 1. Load Testing: The system shall be tested under anticipated concurrent user loads to verify stability and performance. |
| M |
| 6.2.5 |
| 1. Stress Testing: The system shall be tested under extreme load conditions to determine its breaking point and how it recovers from overload. |
| M |
| 6.2.6 |
| 1. Security Testing: The system shall undergo comprehensive security testing, including vulnerability scanning, penetration testing, and authentication/authorization testing, to identify and mitigate security flaws. |
| M |
| 6.2.7 |
| 1. Usability Testing: The user interface and overall user experience shall be tested with representative CDFW users to ensure intuitiveness, ease of use, and efficiency for data entry and extraction tasks. |
| M |
| 6.2.8 |
| 1. The application shall be tested across specified web browsers (e.g., Chrome, Firefox, Edge, Safari) and operating systems to ensure consistent functionality and appearance. |
| M |
| 6.2.9 |
| 1. The integrity and accuracy of migrated historical data shall be thoroughly verified after the migration process, ensuring no data loss or corruption occurred. This includes spot checks and reconciliation reports between source and target data. |
| M |
| 6.2.10 |
| 1. Regression Testing: After any bug fixes, enhancements, or new releases, a subset of existing test cases shall be re-executed to ensure that new changes have not negatively impacted existing functionalities. |
| M |
| 6.2.11 |
| 1. Test Environments: Dedicated test environments (e.g., Development, Staging, UAT) shall be provided and maintained, separate from the production environment, for conducting various testing phases. |
| M |
| 6.2.12 |
| 1. Defect Management: The vendor shall implement a robust defect management process, including logging, tracking, prioritizing, and resolving identified defects. All defects shall be tracked until resolution. |
| M |
| 6.2.13 |
| 1. Test Progress Reporting: The vendor shall provide regular test progress reports to CDFW, detailing test coverage, executed test cases, passed/failed rates, and open defect status. |
| M |
| 6.2.14 |
| 1. Sign-off Criteria: Clear criteria shall be established for successful completion and sign-off of each testing phase (e.g., number of critical defects remaining, test coverage percentage). |
| M |