APPENDIX A - CAMPUS MOBILE APP REQUIREMENTS FINAL.xlsx
XLSX spreadsheet 25 KB Posted
- Attached to
- 9280-26-R-IFBD-00037
- Solicitation number
- 3160007942
- Issued by
- Greene County, Mississippi
About this file
This is a requirements specification document for a campus mobile application being procured by the University of Southern Mississippi, with sealed bids due on Tuesday, April 7, 2026, at 2:00 p.m. to the Office of the Director of Procurement Services. The university seeks a comprehensive mobile application solution that supports iOS and Android platforms with extensive reporting, analytics, and administrative functionality. The solution must integrate with the university's existing systems, including PeopleSoft (SIS), Canvas (LMS), and Azure AD/SSO identity management, while providing configurable dashboards, custom reporting capabilities, real-time analytics, and feature-level engagement metrics across dining, maps, events, and shuttle tracking functionalities. The vendor must provide full implementation support, including project management, app store submission assistance, comprehensive training for technical and functional users, and help desk support during and after deployment. The solution requires a test environment separate from production, support for role-based access controls, and multi-language functionality with offline capabilities.
The solution must meet stringent security, compliance, and accessibility requirements, including FedRAMP Low baseline controls, GDPR compliance, WCAG 2.2 accessibility standards, and ADA compliance with Section 504 requirements. All data must be hosted on U.S. infrastructure with no storage or processing outside U.S. geographic boundaries, and the vendor must provide complete data exportability in non-proprietary formats upon contract termination. The vendor must present a Service Level Agreement with defined response times, escalation procedures, and system uptime guarantees, along with a documented disaster recovery plan and patch management process. Additionally, the solution must include a collaborative user community, support integration with Google Analytics and Firebase SDK, provide CSS customization for branding, and include no-code, drag-and-drop development capabilities for administrative users to create screens and content independently.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| USM BID 26-36 LEGAL AD.pdf | ||
| RFP FOR CAMPUS MOBILE APPLICATION_FINAL.pdf |
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
Sheet1
| Identifier | Required/Optional | REQUIREMENTS | Yes/No | DETAILS (May also be attached to document. Must reference Requirement ID#) |
| Reporting, Monitoring & Analytics | ||||
| 1 | R | The vendor must provide a comprehensive reporting suite that includes at a minimum the information below. Provide details. | ||
| 1.1 | Usage Statistics (Daily, Weekly, Monthly Active Users) | |||
| 1.2 | Feature-level engagement metrics (dining, maps, events, shuttle tracking, etc.) | |||
| 1.3 | User behavior trends and interaction patterns | |||
| 1.4 | System performance and uptime reports | |||
| 1.5 | Error, crash and exception logs | |||
| 2 | R | The solution must include configurable dashboards that allow university administrators to: | ||
| 2.1 | Create, modify and save custom views | |||
| 2.2 | Filter data by date range, user type, device type or feature | |||
| 2.3 | Export dashboard data in common formats (CSV, Excel, PDF) | |||
| 2.4 | Schedule automated delivery of dashboard reports to designated recipients | |||
| 3 | R | The solution must allow custom reports to be created. Please describe how custom reports will be created. | ||
| 4 | R | The vendor must provide real-time or near real-time reporting for: | ||
| 4.1 | App logins and session activity | |||
| 4.2 | High traffic periods | |||
| 4.3 | Feature usage spikes | |||
| 4.4 | System alerts or outages | |||
| 5 | R | The solution must include built-in visualization options such as: | ||
| 5.1 | Charts and graphs | |||
| 5.2 | Trend lines and comparative views | |||
| 5.3 | Drill-down capabilities for deeper analysis | |||
| 6 | R | The solution must allow the management of analytics filtered by : Provide details. | ||
| 6.1 | Device Types | |||
| 6.2 | Platform | |||
| 6.3 | Authentication | |||
| 6.4 | Locations | |||
| 6.5 | Roles | |||
| 6.6 | Screens | |||
| 6.7 | Searches | |||
| 7 | R | The solution must provide reports about the delivery status of communications, messages or channels. | ||
| 8 | R | The solution must provide a method to access and report historical analytics data. | ||
| 9 | R | The solution must provide the ability to utilize APIs to aggregate analytics data from multiple sources into a single, unified dashboard and support integration with Google Analytics, including full compatibility with the Firebase SDK for mobile analytics as documented by Google. | ||
| Implementation, Deployment & Support | ||||
| 10 | R | The vendor must initiate and maintain a comprehensive project plan that includes activities, responsibilities and timelines for both university personnel and the solution provider’s staff. The proposal must include documentation of the vendor’s project management methodology and processes, including tools, communication practices and governance structure. | ||
| 11 | O | The solution should be installed with minimal interruption to current operation. | ||
| 12 | R | The vendor must provide app configuration and branding support. | ||
| 13 | R | The vendor must provide app store submission and approval support. | ||
| 14 | O | The solution must allow for CSS customization, especially for look and feel, allowing the University to meet university graphic standards for branding, logos, etc. | ||
| 15 | R | The vendor must provide services by experienced staff and experts for technical support during installation and until the product is successfully and fully implemented according to the specifications outlined in the RFP. | ||
| 16 | R | The vendor must provide comprehensive training for The University’s technical users and functional (power) users. Training must include, at a minimum, telephone-based technical support, web-based training sessions and robust self-service resources such as a searchable knowledge base and access to established user communities for sharing expertise. The vendor must describe in detail the types of training offered by their organization, including delivery methods materials provided, and ongoing support options. | ||
| 17 | R | The vendor must provide direct support as part of the proposed services. The proposal must clearly describe the types of direct support offered, which may include user training, development of additional dashboards, deep-dive analytical services or the creation of new product roadmaps. | ||
| 18 | R | The vendor must provide comprehensive and timely help desk support to The University's technical/support staff. Describe hours and level of support. | ||
| 19 | R | The vendor must provide a documented plan for software upgrades or new releases. | ||
| 20 | R | The vendor must provide a formal process that enables The University to request and initiate infrastructure modifications to the mobile application. | ||
| 21 | R | The vendor must provide a support system that allows The University to submit support tickets and receive timely responses for all requested issues, enhancements, and operational needs. | ||
| 22 | R | The vendor must provide prompt responses and remediation plans for updates, platform changes and security issues originating from Apple and Google mobile operating systems, app store requirements or related ecosystem updates. | ||
| 23 | R | The vendor must present a Service Level Agreement (SLA) for review by The University. The SLA will include a service plan designed to respond to and resolve all service calls within a mutually-agreed upon timeframe given the priority of the service call. The SLA must include a timeframe for service engagement to ensure resolution of service calls within the specified time and escalation process and procedures in the event that service calls are not answered in the agreed upon timeframe. | ||
| 24 | R | The vendor must have a service management process. Describe the process for engaging your support team for incidents and issue escalation. Include standard service levels, response times and system uptime. | ||
| 25 | R | Upon award of the contract, the selected vendor must provide all required documentation in electronic form within ten (10) business days of contract approval. The vendor must specify the file format of all submitted materials, such as PDF, Microsoft Word, or HTML, and ensure that all documentation is accessible and compatible with standard office software. | ||
| Collaboration and Sharing | ||||
| 26 | R | Describe any collaboration or sharing features, if any, that are available in your solution. | ||
| 27 | O | The vendor should maintain a collaborative user community that enables customers to share experiences, ideas, improvements, best practices and other insights with one another. The proposal should describe the structure and features of this community and how customers engage within it. | ||
| Integration | ||||
| 28 | R | The solution must integrate with The University's SIS (PeopleSoft). | ||
| 29 | R | The solution must integrate with The University's LMS (Canvas). | ||
| 30 | R | The solution must integrate with The University's Identity and Access Management, including but not limited to SSO, Azure AD, and SAML. | ||
| 31 | R | The solution must allow for the management of different calendar feeds. | ||
| 32 | R | The solution must allow for the use of different data sources (e.g. calendar feed, alert feeds, CSV files, ICS calendars, social media platforms, video, etc). Please list the data sources supported by the solution. | ||
| Technical Requirements: Hardware and Software | ||||
| 33 | R | Define the environment required to run the software including the hardware and software requirements and integration considerations to operate and maintain the proposed system. | ||
| 34 | R | The solution must provide non-functional requirements such as functionality, efficiency, reliability, maintainability, scalability, availability etc. Describe how your solution will meet these requirements. | ||
| 35 | R | The vendor must provide a formal and documented Disaster Recovery Plan for business continuity. Please provide your documentation. | ||
| 36 | R | The solution must include a web-based administrative interface for configuration and management. | ||
| 37 | R | The solution must be accessible through the certified standard web browsers such as Safari, Mozilla Firefox, Google Chrome, Microsoft Edge, etc. Provide a list of all web browsers and associated versions that are usable. | ||
| 38 | R | The solution software must be updated and patched regularly. We require documentation including details about how patches and updates are delivered for your product and who performs the updates. | ||
| 39 | R | The solution must support a mobile-responsive display on smartphones and tablets. | ||
| 40 | R | The solution must work with the Android and iOS, and other standard mobile operating systems. | ||
| 41 | R | The solution must contain a test environment to test the full application before activating it in the production environment. | ||
| 42 | R | The solution must be a native application downloadable to the devices as a test application and a production application. | ||
| 43 | R | The solution must include granular deployment of screens and other components into the test and production environment independently. | ||
| 44 | R | The solution must allow messages to be sent to a test environment before they are sent to the production environment. | ||
| 45 | R | The solution must validate URLs in the applications to be sure they return a successful https code. | ||
| 46 | R | The solution must allow for centralized management of one software system with multiple and separate campus locations. | ||
| 47 | R | The solution must define and document all API rate limits and throttling policies, including request limits, enforcement methods, and available options for monitoring usage or requesting increased limits. | ||
| Functional Requirements | ||||
| 48 | R | The solution must support role-based access controls for students, faculty, staff and administrators. | ||
| 49 | R | The solution must be configurable to add more information as needed by functional or administrative users of the system. | ||
| 50 | R | The solution must provide a no-code platform that uses a visual development environment to allow layman users to create applications, through methods such as drag-and-drop, adding application components to create a complete application. | ||
| 51 | R | The solution must allow for the creation of independent screens that can be managed by their respective creators and administrators. | ||
| 52 | R | The solution must allow for the creation of content so that creators and managers can organize projects separately with their own modules, screens, data sources and other components pertaining to the project. | ||
| 53 | R | The solution must allow the creation of locations that will allow administrators to bind roles by location. | ||
| 54 | R | The solution must allow for the creation of roles that will facilitate administrators to deliver the content of the application by targeting the specific user's roles as needed. | ||
| 55 | O | The solution should allow scheduling a switch from one user's role to another. | ||
| 56 | O | The solution should include polls, either scaled and/or as multiple choice polls. | ||
| 57 | R | The solution must allow the creation of screens and/or templates that are flexible in design in order to deliver content that meets the user's needs. | ||
| 58 | O | The solution should provide the ability to design product themes. For example, including but not limited to basic html tags, custom web (hexadecimal) colors, css, xml. | ||
| 59 | R | The solution must allow us to link to other modules/screens as well as to external media. | ||
| 60 | R | The solution must allow us to embed content from external sources. | ||
| 61 | R | The solution must allow the creation and submission of forms. | ||
| 62 | R | The solution must allow the creation of messages, filtered and targeted, by roles through push notifications and/or email. | ||
| 63 | R | The solution must allow the scheduling of messages ahead of time (daily, weekly, monthly). | ||
| 64 | R | The solution must provide opt-in channels for communications. | ||
| 65 | O | The solution should include approval workflow to ensure the application complies with university image and guidelines. | ||
| 66 | O | The solution should include a seamless social media integration such as Facebook, X, Instagram etc. and not be limited to only picture sharing. | ||
| 67 | R | The solution must support multi-language functionality, allowing the mobile application interface and content to be presented in multiple languages. | ||
| 68 | R | The solution must support standard internationalization practices, including the ability to configure and manage translations for user interface elements and content without requiring custom development. | ||
| 69 | R | The solution must support offline functionality that allows users to access selected content and features when an internet connection is unavailable. | ||
| 70 | R | The solution must automatically synchronize data and updates once connectivity is restored. | ||
| Security | ||||
| 71 | R | Delivered code must be hardened against and tested for injection vulnerabilities. | ||
| 72 | R | Delivered code must validate, filter and sanitize input. | ||
| 73 | R | Delivered code must be hardened against cross-site scripting attacks. | ||
| 74 | R | Delivered code must escape any user-provided or untrusted data being presented to the client. | ||
| 75 | R | Delivered code must either not accept untrusted serialized objects or must be hardened against serialized attacks. | ||
| 76 | R | Delivered code must not use any components or libraries with known vulnerabilities at the time of delivery. | ||
| 77 | R | Delivered code must not provide detailed error messages to clients. | ||
| 78 | R | Delivered code must be hardened against cross-site request forgery attacks. | ||
| 79 | R | Delivered code must not expose session IDs in URLs. | ||
| 80 | R | Provider must address and fix any discovered vulnerabilities within 90 days. | ||
| 81 | R | If the code is doing any authentication, techniques to prevent authentication attacks, including brute-force attacks and credential stuffing attacks, must be implemented. | ||
| 82 | R | If the code is doing any authentication, it must not use or provide default credentials. | ||
| 83 | R | The solution must be cloud-hosted in a secure, scalable, and highly available environment, comply with institutional data security, privacy, and regulatory standards, and, if delivered as a cloud service, must have implemented FedRAMP Low baseline controls. | ||
| 84 | R | The solution must be hosted on infrastructure physically located within the United States. All application data, backups, disaster recovery environments, and support systems must reside on servers located within U.S. geographic boundaries. Vendors must disclose the cloud service provider and confirm that no application data is stored, processed or transmitted outside of the United States. | ||
| 85 | R | The solution must be compliant to the General Data Protection Regulations (GDPR) standards to ensure an utmost private and secure process of the users data. | ||
| 86 | R | The solution must provide role-based security using our authentication framework using Active Directory and Microsoft Azure Single Sign-On and allows us to grant and revoke privileges in an automated system. | ||
| 87 | R | The solution must allow the administrators to have different levels of access (roles) for data management and reporting. | ||
| 88 | R | The solution must log all events that occur in the system to form an audit trail. | ||
| 89 | R | The solution must provide for the logging and reporting of user and administrator system access. | ||
| 90 | R | The solution must provide logging and reporting of changes to user and administrator accounts, including the modification of privileges, access and roles. | ||
| 91 | R | The solution must provide for the logging and reporting of modifications to settings and parameters. | ||
| 92 | O | The solution should offer HIPAA compliance as a standard feature. | ||
| 93 | O | The solution should offer GLBA compliance as a standard feature. | ||
| 94 | R | The solution must provide The University with the ability to export all institutional data at any time during the contract period and upon contract termination. Data must be exportable in a non-proprietary, machine-readable format (such as CSV) without requiring additional vendor software. | ||
| 95 | R | The vendor must provide documentation of the data schema and export process and must support the University in retrieving a complete data extract within a reasonable timeframe to facilitate migration to another system, if needed. | ||
| 96 | R | The solution must support configurable data retention policies that allow The University to define how long data is stored and when it is archived or deleted. | ||
| 97 | R | The vendor must document default retention periods and ensure that data retention and disposal practices comply with applicable institutional policies and regulatory requirements. | ||
| User Interface/Accessibility | ||||
| 98 | R | Web content must meet ISO/IEC 40500:2025 [Web Content Accessibility Guidelines (WCAG) 2.2]. | ||
| 99 | R | The vendor must ensure that mobile applications are independently accessible to and usable by persons with disabilities by ensuring that mobile applications conform to a recognized set of software accessibility standards, such as, EN 301-549:2021, Section 11 (Software). | ||
| 100 | R | The solution must be uncluttered and straightforward, with design elements placed in proper context, space, and size, supporting wayfinding and comprehension for diverse users (including those using assistive technologies as scoped by EN 301-549). | ||
| 101 | R | The solution must provide a reliable touch experience (taps, swipes, gestures), including visible focus/activation indicators and adequate target sizes consistent with mobile usability best practices and EN 301-549 Section 11 expectations for operability. | ||
| 102 | R | The solution must include an in-product feedback feature for users to report accessibility/usability issues and general experience. Vendor shall triage and track resolution as part of maintenance. | ||
| 103 | R | The solution must comply with Section 504 of the Rehabilitation Act and ADA requirements, meeting WCAG 2.1 AA standards. Vendor must provide documentation of accessibility testing and remediation to ensure equitable access for all students, faculty, and staff. |
File details come from the government source that posted it. Updated .