RFP_26O-0924_Student_Information_Systems_specs_.pdf

PDF 361 KB Posted

Attached to
Student Information Systems
Solicitation number
26O-0924
Issued by
Maricopa County, Arizona

About this file

This is a Request for Proposal (RFP 26O-0924) Scope of Work and Specifications document issued by Mohave, a purchasing consortium, for Student Information Systems (SIS) software to serve approximately 488 public agencies across Arizona. The solicitation seeks comprehensive SIS solutions that operate in cloud and web-based environments with 24/7 availability and support multiple modules including attendance, grades, discipline, special education, scheduling, staff management, fees and billing, food service, immunization and health records, parent/guardian portals, and online registration. The RFP permits partial proposals and allows offerors to submit brand-equivalent alternatives to specified products, provided Mohave approves them as meeting quality and performance standards. Contracts will be awarded for an initial one-year term with four potential one-year renewal options. The solicitation accommodates both new vendors and legacy pricing for software renewals under previous Mohave contracts.

The specifications establish mandatory compliance with multiple federal and state data security and privacy regulations, including FERPA, COPPA, IDEA, HIPAA, Section 508 accessibility standards, WCAG 2.2 AA guidelines, Arizona Department of Education (ADE) standards, Arizona Education Data Standards (AzEDS), and specific Arizona Revised Statutes (A.R.S. 15-117, 15-141, 15-142, 15-241, 15-1046, 18-551, 18-552). Offerors must execute data security and confidentiality agreements with member agencies accessing, storing, processing, or hosting data. Vendors are required to provide introductory training at member sites with options for intermediate and advanced training at additional cost, including instructor-led, virtual, self-paced, and recorded formats with emphasis on "training-the-trainer" approaches. All offerors must indicate compliance or take clearly documented exceptions/deviations to each specification; unacceptable deviations may render proposals non-responsive. New modules, features, and enhancements developed during the contract term may be added to contract pricing upon Mohave's written approval if they integrate with the existing SIS platform.

View the file

Other files

Show all 16

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

RFP 26O-0924

REQUEST FOR PROPOSAL 26O-0924

Student Information Systems

Scope of Work Specifications

SPECIFICATIONS

Purpose of specifications: Specifications are designed to enable offeror to satisfy a requirement for a product, material, process, or service. A specification may be expressed as a standard, part of a standard, or independent of a standard. No specification is intended to limit competition by eliminating items capable of satisfactorily meeting the requirements of the procurement. If offeror believes a specification is unnecessarily restrictive, offeror must notify Mohave prior to specified proposal due date and time.

Partial proposals: Mohave may consider partial proposals for award of a contract.

Use of brand names: Brand names, trade names, model numbers, and/or catalog numbers may be used to describe the standard of quality, performance, and other characteristics needed to meet member requirements. Use of the name of a manufacturer, brand, make, or catalog number is not intended to limit or restrict competition, nor does it restrict offeror from the submission of brand equivalent offers. However, Mohave reserves the right to decide whether alternatives are equivalent to the materials and/or equipment described in the solicitation. Mohave shall be the sole judge of equivalent quality, and Mohave’s decision shall be final.

Compliance with specifications: Offerors shall offer products, materials, processes, or services they believe meet the specifications. The fact that a manufacturer, supplier, or offeror chooses not to produce or provide product, material, process, or services to meet the specifications shall not be considered sufficient cause to adjudge the specifications as restrictive.

Additional references and definitions used for specifications and product specifications:

(acronyms used in the solicitation are noted in bold font below):

Arizona Department of Education (ADE): https://www.azed.gov Standards (AzEDS): https://www.azed.gov/information-technology/azeds Children's Online Privacy Protection Rule (COPPA): https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa Every Student Succeeds Act (ESSA): https://www.ed.gov/laws-and-policy/laws-preschool-grade-12-education/every-student-succeeds-act-essa?src=ft Family Education Rights and Privacy Act (FERPA): https://studentprivacy.ed.gov/faq/what-ferpa General Data Protection Regulation (GDPR): https://gdpr-info.eu/ U.S. Department of Health and Human Services (HIPAA): https://www.hhs.gov/hipaa/for-individuals/index.html Individuals with Disabilities Education Act (IDEA): https://sites.ed.gov/idea/regs/b Protection of Pupil Rights Amendment (PPRA): https://studentprivacy.ed.gov/faq/what-protection-pupil-rights-amendment-ppra Section 508 (ADA): https://www.section508.gov/manage/laws-and-policies/ Student Data Privacy Consortium: https://privacy.a4l.org/ Uniform System of Financial Records for Arizona School Districts (USFR):

https://www.azauditor.gov/sites/default/files/2026-07/USFR_Issued_63026.pdf U.S. Department of Education: https://www.ed.gov Web Content Accessibility Guidelines 2.2 (WCAG): https://www.w3.org/TR/WCAG22/

SPECIFICATION INSTRUCTIONS

Exceptions/Deviations from specifications: Offerors will respond to each numbered specification by checking the appropriate “Comply” or “Exception/Deviation*” box. “No Bid” items shall be marked as such in the appropriate “Exception/Deviation*” box. Your exceptions/deviations must be clearly explained.

Reference the specification that you are taking exceptions/deviations to detail any proposed substitute language, and clearly explain how the exceptions/deviations meet or exceed specifications. Unacceptable exceptions/deviations shall remove your proposal from consideration for award. Mohave shall be the sole judge on the acceptance of exceptions and Mohave’s decision shall be final. Details for exceptions/deviations shall be listed by specification number on the Scope of Work and Specifications Acceptance Form.

Specifications

Comply Exception Deviation*

1.1 Student Information System – General Specifications

1.1.01 Student Information System (SIS) shall operate in currently supported operating system, cloud, and web browser environments.

1.1.02 SIS shall allow secure, web-based, real-time user access with twenty-four (24) hours, seven (7) days a week availability preferred.

1.1.03 SIS shall provide an easy-to-use interface and support single or multi-user access through a Local Area Network (LAN), Wide Area Network (WAN), or secure internet connection.

1.1.04 SIS shall be accessible through supported web browsers on multiple device types and, where applicable, through mobile applications compatible with major commercially available mobile operating systems.

1.1.05 SIS shall employ industry-standard cybersecurity controls to protect confidential student, employee, and institutional information.

1.1.06 SIS shall allow for security passwords, limiting access to confidential information. Security access shall be defined according to the type of authorized user role (e.g. administrator, parent/guardian, student, or teacher).

1.1.07 SIS shall allow for security permissions to be defined at all field levels within the system.

1.1.08 SIS shall require multifactor authentication for, at a minimum, all employees/contractors with remote access, administrative access, or access to critical IT systems.

1.1.09 SIS security shall integrate with active directory and/or appropriate Lightweight Directory Access Protocols.

1.1.10 It is preferred that the SIS support industry-recognized interoperability standards or equivalent technologies to facilitate secure data exchange with other educational systems.

1.1.11 SIS shall have online help available, allowing user to look up information on any field, screen, or module.

1.1.12 SIS shall provide pre-defined and user-defined reports. All information contained in the database shall be available for inclusion in the user-defined reports. Pre-defined reports shall be compliant with Arizona Department of Education, U.S. Department of Education, and Every Student Succeeds Act requirements.

1.1.13 SIS shall allow for the display of real-time information including, but not limited to: attendance, student schedule, teacher contact information, and grades.

1.1.14 SIS shall allow for audited transactions (e.g. time and date stamp).

1.1.15 SIS shall allow user to manage activity, student, and class fees.

1.1.16 SIS shall support current, industry-recognized database standards and formats.

Deviation*

1.1 Student Information System – General Specifications

(Cont’d.)

1.1.17 SIS functionality shall include, but not be limited to: attendance, grades, report cards, teacher grade book, student immunization and health, class scheduling, attachment of student specific documents, discipline, special education, school curriculum, Arizona Education Data Standards (AzEDS), and student/parent/guardian portal.

1.1.18 For software sold under previous Mohave contract(s), contract vendor may offer software renewals, maintenance, and support at legacy pricing. Legacy Account Pricing should be submitted in 26O – Student Information System Pricing workbook on Legacy Pricing tab.

1.2 Module Functionality Specifications

1.2.01 Module functional interface shall allow user to enter and extract information through a user-friendly interface.

1.2.02 Individual modules shall integrate with other modules to allow users to extract specific information needed to support each module's function.

1.2.03 Module functionality shall allow user to input or view information in a variety of ways including, but not limited to: class, grade, track, student name, student I.D. number, or other grouping methods.

1.2.04 Module functionality shall allow user to input information in a variety of ways that shall include, but not be limited to: manual entry, document scanning, or importing from another source, mass entry by course, class, team, and/or group teacher.

1.2.05 Module functionality shall allow user to generate pre-defined or user-defined reports in a variety of formats.

1.2.06 Module functionality shall allow user to import text or graphics into the reports.

1.2.07 Module functionality shall be designed to support accessibility requirements in accordance with Section 508 of the Rehabilitation Act and Web Content Accessibility Guidelines (WCAG) 2.2 AA, or the current adopted accessibility standard.

1.3 Attendance Module Specifications

1.3.01 Attendance module shall handle daily, half-day, quarter-day, hourly, and period attendance information, as required for applicable student grade level. Module shall account for holidays, half-days, early dismissal, bell schedule, and custom calendars.

1.3.02 Attendance module functionality shall include, but not be limited to: recording and calculating instructional and attendance hours in accordance with current ADE reporting requirements, planned absences, individual and group attendance, recording tardies or early dismissal, bell schedules, and custom calendars.

1.3.03 Attendance module shall allow for teachers to enter daily attendance for each class and allow front office staff to access teacher attendance entry.

1.4 Discipline Module Specifications

1.4.01 Discipline module shall allow user to maintain and update student discipline records, including parental/guardian correspondence, detention and suspension status, and other related information.

1.4.02 Discipline module shall allow user to designate confidential information and restrict access based on user security permissions.

Deviation*

1.4 Discipline Module Specifications (Cont’d.)

1.4.03 Discipline module shall allow user to enter and maintain incident and student-based disciplinary information.

1.4.04 Discipline module shall allow authorized user to export student information, as permitted, for parental/guardian correspondence. The module shall support mail merge or equivalent functionality to generate correspondence for multiple parents/guardians.

1.5 Fees and Billing Module Specifications

1.5.01 Fees and billing module shall allow the user to track and manage student fees, generate billing statements, collection letters, and accept electronic fee payments. Module shall allow parents/guardians to view and pay fees through the parent/guardian portal module or other online payment system.

1.5.02 Fees and billing module shall allow user to create and define fee codes for classes, activities, and grade levels.

1.5.03 Fees and billing module shall allow user to create and maintain student fee accounts.

1.5.04 Fees and billing module shall provide payment transaction history and payment status for authorized user(s) and parents/guardians.

1.6 Food Service Module Specifications

1.6.01 Food service module shall allow the user to generate student and employee food service accounts and assign individual PINs or other unique user identifiers.

1.6.02 Food service module management functions shall include, but not be limited to: real time deposit of funds into individual accounts, centralized administration and monitoring, establish spending limits, generate alerts, and send low-balance notices.

System shall have the capability to send notifications via mail, email, voicemail, and text.

1.6.03 Food service module shall allow secure access through portal module and provide access to cafeteria information to include, but not be limited to: menu, account balances, and student meal selection.

1.6.04 Food service module may support meal eligibility and reporting in accordance with applicable federal and state requirements.

1.6.05 Food service module functionality may be provided directly by the proposed solution or through integration with a third-party food service management solution. Contract vendor shall describe the method used to provide the required functionality.

1.7 Student Grades and Report Cards Module Specifications

1.7.01 Information within the student grades and report cards module shall automatically align with user-defined grading policies and applicable state reporting standards.

1.7.02 Student grades and report cards module shall allow user to record test, quiz, and assignment scores.

1.7.03 Student grades and report cards module shall allow user to include comments regarding specific tests, quizzes, and assignments.

1.7.04 Student grades and report cards module shall allow user to enter discipline information for students.

Deviation*

1.7 Student Grades and Report Cards Module Specifications

1.7.05 Student grades and report cards module functionality shall include, but not be limited to, the ability to: enter grades; define weighting and manage individual assignments or curriculum categories; add and delete assignments; add or edit comments; print student grades; and email or print report cards.

1.7.06 Student grades and report cards module shall allow a variety of grading methods to include, but not be limited to: numeric grades, traditional letter grades, proficiency grades, percentages, and/or other evaluation codes determined by the user.

1.7.07 Student grades and report cards module shall allow user to generate, at a minimum, report cards, progress reports, transcripts, self-paced grade reporting information, parent/guardian information letters, and/or any other related reports.

1.8 Student Immunization and Health Module Specifications

1.8.01 Student immunization and health module shall support the management of student immunization and health records in accordance with applicable federal and state laws and reporting requirements.

1.8.02 Student immunization and health module shall allow user to maintain and update student medical information regarding medical examinations, prescriptions, medication dosage, medical allergies, and other related information.

1.8.03 Student immunization and health module shall allow user to generate medical reports.

1.8.04 Student immunization and health module shall allow user to enter student health screening information.

1.8.05 Student immunization and health module shall allow for the tracking, reporting, and maintenance of student health program information and applicable government program information.

1.8.06 Student immunization and health module shall allow user to maintain student immunization records and immunization status.

1.9 Parent/Guardian and Student Portal Module Specifications

1.9.01 Parent/guardian and student portal module functionality shall include, but not be limited to, the ability to access: attendance, discipline, calendar, schedules, grades, teacher communication, fees, report cards, class assignments, notifications, and current and historical grading information.

1.9.02 Parent/guardian and student portal module shall be accessible twenty-four (24) hours and seven (7) days a week through the institution website, secure web portal, or web-based application.

1.10 Staff Registration and Enrollment Module Specifications

1.10.01 Staff registration and enrollment module functionality shall include, but not be limited to: validating student addresses, processing enrollment restrictions, assigning students to staff, alerting staff to student medical or other designated needs, adding a student picture, and linking sibling records.

1.10.02 Enrollment codes shall be aligned with current state reporting codes to ensure accuracy of state reporting.

Deviation*

1.10 Staff Registration and Enrollment Module Specifications

1.10.03 Staff registration and enrollment module search functionality shall allow user to search by unique student ID, student name, date of birth, or other user-defined identifiers.

1.10.04 Staff registration and enrollment module shall allow user to add or edit student, parent/guardian, and family information. Module shall also allow user to add or edit emergency contact information.

1.11 Student Online Registration Module Specifications

1.11.01 Student online registration shall be accomplished using the parent/guardian portal module or educational institution webpage.

All information shall be secure and protected through user authentication and appropriate security controls.

1.11.02 Student online registration module interface shall allow user access to all required forms and facilitate the entry of required information.

Module interface shall allow user to upload documents, as necessary, to complete registration process.

1.11.03 Student online registration module interface shall allow user to view and edit information as needed. Module interface shall allow user to download or print all documents.

1.11.04 Student online registration module shall allow the educational institution to generate email communications to parents/guardians requesting additional information or documentation.

1.12 Reporting Module Specifications

1.12.01 Reporting module shall allow user to create reports in various formats using pre-defined or user-defined information to meet current applicable state and federal reporting requirements.

1.12.02 SIS shall provide integrated functionality that meets current applicable AzEDS reporting requirements from the educational institution site.

1.12.03 SIS shall allow user to build and/or extract records, as required by current applicable data reporting requirements of AzEDS.

1.12.04 SIS shall provide user with ability to edit information, prior to submission to the AzEDS.

1.12.05 SIS shall include regular updates to maintain compliance with current applicable AzEDS reporting requirements.

1.12.06 SIS updates shall include revised data tables, as they are made available from the ADE.

1.12.07 SIS shall allow user to track reporting errors, monitor the acceptance of AzEDS transmission transactions, and make necessary corrections before resubmission of SIS data.

1.12.08 SIS may include report features for forecasting student enrollments.

1.13 Scheduling Module Specifications

1.13.01 Scheduling module functionality shall include, but not be limited to:

managing multiple school schedules, integration with the staff registration and enrollment module, tracking teacher availability, and creation of master schedules.

1.13.02 Scheduling module shall allow user to maintain and update class information regarding multiple tracks, class prerequisites, balancing schedules, course fees and supplemental costs, varied timetables, classroom seating restrictions, homerooms, and student accommodation requirements.

1.13.03 Scheduling module shall allow user to efficiently assign new, returning, and transferring students to classes and schedules.

Deviation*

1.13 Scheduling Module Specifications (Cont’d.)

1.13.04 Scheduling module shall display requested courses and alternate course selections.

1.14 Staff Management Module Specifications

1.14.01 Staff management module functionality shall include, but not be limited to: add, edit, or view staff database, staff schedules, track staff roles and application permissions, and assign user accounts and access permissions.

1.14.02 Staff management module shall allow user access to current and former staff records, track staff qualifications, and assign staff their grade level, classes, and subjects.

1.15 Special Education Module Specifications

1.15.01 Special education module shall allow user to maintain and update information regarding student requirements, class loads, instructional aide availability, state, local, or federal government reporting data, and other related information.

1.15.02 Special education module shall allow user to create and maintain Individualized Education Programs (IEPs). User shall be able to track data relating to disability, case manager, or other special services.

1.15.03 Special education module shall allow user to generate reports for applicable state, local, or federal government reporting requirements, and other related reports.

1.16 Addition of Modules Specifications

1.16.01 Contract vendor shall provide information regarding any new modules, features, enhancements, or functionality developed during the contract term. Upon review and written approval by Mohave, such offerings may be added to contract pricing.

1.16.02 New modules shall integrate with the existing SIS and function as part of the overall solution. Stand-alone modules that do not integrate with the SIS are not preferred.

1.17 Training Specifications

1.17.01 Introductory training shall be held at member site, unless otherwise specified by member.

1.17.02 Intermediate and advanced training may be offered at additional costs. This shall allow users to customize their training, depending on their needs.

1.17.03 Subject matter experts shall administer training.

1.17.04 Training aimed at “training-the-trainer” is requested.

1.17.05 Training may be instructor-led, virtual instructor-led, self-paced online, recorded, or onsite.

1.17.06 Contract vendor shall offer training and support packages to member agencies on an as-needed basis. Training and support packages shall include, but not be limited to: instruction on the use, administration, and operation of the Student Information System (SIS), as well as telephone, online, remote, and other support services.

1.18 Data Security Agreements Specifications

1.18.01 Contract vendor agrees to comply with the current applicable requirements of FERPA, PPRA, COPPA, IDEA, HIPAA, Section 508 of the Rehabilitation Act, ADA, GDPR, and any other applicable federal and/or other state law governing the privacy of Covered Data Information (CDI) or the accessibility of products and services. CDI includes student records, employee records, personally identifiable information, and other non-public information, including 'covered information' as defined by applicable Arizona law.

Deviation*

1.18 Data Security Agreements Specifications (Cont’d.)

1.18.02 Contract vendor specifically agrees to comply with A.R.S. §§ 15-117, 15-141, 15-142, 15-241, 15-1046, 18-551, 18-552, as amended, and any other applicable state law governing cybersecurity, student data privacy, and CDI.

1.18.03 Member may be required under the USFR Compliance Questionnaire IT08, audit requirements, and any other applicable laws to maintain data security agreements with contract vendor accessing, storing, processing, transmitting, or hosting member data.

A sample Data Security and Confidentiality Agreement has been provided in OpenGov Attachments section. Indicate “Comply” if your firm will work with member to comply with the USFR. If your firm will not sign a data security agreement with member, indicate “Deviate”.

• Mohave shall not manage nor administer member data-security agreements. The provided sample data security agreement is solely to provide contract vendor with the language commonly used by member. Member may use alternate agreement, language, and forms.

• As this solicitation is primarily for the use of Educational Institutions, failure to comply may render your proposal as non-responsive.

*Exceptions/deviations must be listed on the Scope of Work and Specifications Acceptance Form. List the specification number for each exception/deviation.

Scope of Work and Specifications Acceptance Form

Signature on the Offer and Acceptance Form certifies complete acceptance of the Scope of Work and Specifications in this solicitation, except as noted below (additional pages may be attached, if necessary).

Check one of the following responses to the Scope of Work and Specifications:

1 We take no exceptions/deviations to the Scope of Work and Specifications.

(Note: If nothing is listed below, it is understood that no exceptions/deviations are taken.)

1 We take the following exceptions/deviations to the Scope of Work and Specifications.

All exceptions/deviations shall be clearly explained. Reference the corresponding Scope of Work or Specifications that you are taking exceptions/deviations to. Provide details on your exceptions/deviations below:

(Note: All requested exceptions/deviations must be clearly explained. Reference the specific language that you are taking exceptions/deviations to detail any proposed substitute language, and clearly explain how the exceptions/deviations meet or exceed Scope of Work and Specifications. Unacceptable exceptions/deviations may remove your proposal from consideration for award. Mohave shall be the sole judge on the acceptance of exceptions/deviations and Mohave’s decision shall be final.)

File details come from the government source that posted it. Updated .