RFI- Student Management System for Air University.pdf

PDF 343 KB Posted

Attached to
Air University Student Management System
Solicitation number
Not on record
Issued by

About this file

This is a Request for Information (RFI) and Sources Sought notice issued by the Department of the Air Force for a commercial off-the-shelf (COTS) Student Management System to support Air University's higher education operations. Responses are due by 5:00 PM CDT on May 27, 2026, and must not exceed 10 pages. This RFI is issued solely for market research and planning purposes and does not constitute a solicitation or promise to issue a future Request for Proposal. The government will not reimburse respondents for any costs incurred in preparing responses, and all proprietary or competition-sensitive information must be clearly marked.

Air University requires a comprehensive student management system to manage the complete student lifecycle from admissions through program completion and transcript services, supporting undergraduate degrees, graduate degrees, and non-degree professional military education programs across 23 programs. The system must be a COTS solution hosted in Department of Defense Information Level 4 (IL-4) compliant government community cloud infrastructure, with compliance to RMF or NIST accreditation standards. Key functional requirements include admissions management with bulk import and credit transfer capabilities; enrollment and registration with configurable rules-based course assignment; graduation and program completion verification with automated academic evaluations; transcript management with Learning Management System (Canvas/Blackboard) integration; program advising workflows; academic course catalog management; academic scheduling with quota distribution; credit evaluation for external transcripts and standardized tests; student bursar/financial management; and reporting and analytics functionality. The system must support role-based access control with multi-factor authentication including Department of Defense Common Access Card (CAC) integration, interface with existing Air University Identification (AUID) software, and integration with current systems including Canvas LMS, DEERS, DMDC, ACQNOW, and MILPDS. Interested vendors should submit responses electronically to the three listed Air Force points of contact and address vendor information, security and compliance capabilities, detailed technical approaches to meeting functional requirements, implementation and integration methodology with a realistic phased deployment timeline enabling initial capability within four months of award, and relevant past performance on similar contracts at large institutions.

View the file

Other files

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

SOURCES SOUGHT (SS)/ REQUEST FOR INFORMATION (RFI)

STUDENT MANAGEMENT SYSTEM FOR AIR UNIVERSITY

THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. THERE IS NO SOLICITATION

AVAILABLE AT THIS TIME. REQUESTS FOR SOLICITATION WILL NOT RECEIVE A

RESPONSE.

This RFI is issued solely for information and planning purposes. It does not constitute a Request for

Proposal (RFP) or a promise to issue an RFP in the future. This RFI does not commit the

Department of the Air Force (DAF) to contract for any supply or service whatsoever. Further, the

DAF is not seeking proposals currently. Respondents are advised that the AF will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party’s expense. it is the responsibility of the potential offerors to monitor sites for additional information pertaining to this requirement.

The information provided is considered market research and may be used by the AF in developing its acquisition strategy, and performance specifications. Interested parties are responsible for adequately marking proprietary or competition sensitive information contained in their response.

The Government reserves the right to contact the submitting parties, on an as-required basis, for further clarification on material provided. The Government reserves the right to contact additional customers to obtain information that will be used to evaluate the offeror’s interest.

The United States Government (USG), through the DAF, is issuing this Request for Information

(RFI) to obtain input from industry regarding IT services in the areas of a student management system. Responses to this notice are not offers and cannot be accepted by the Government to form a binding contract.

PURPOSE:

Air University is a military education institution delivering undergraduate degrees, graduate degrees, and non-degree programs to support the Department of Air Force and Department of War requirements for

Professional Military Education, Professional Continuing Education, and Professional Developmental

Education. Headquarters (HQ) Air University (AU) requires a contractor to provide a commercial off-the-shelf (COTS) Student Management System to meet or exceed AU’s requirement for an information system for higher education that will manage the complete student lifecycle from applications for admission through program completion to include transcript services.

RESPONSE INSTRUCTIONS:

Interested parties are invited to submit responses electronically to matthew.fapso.1@us.af.mil, alisha.barnes.1@us.af.mil and jeffery.webb.2@us.af.mil. Responses must be received no later than 5:00 PM

CDT on 27 May 2026 and shall not exceed 10 pages.

Attachments:

1. Draft Performance Work Statement and Response Requirements mailto:matthew.fapso.1@us.af.mil mailto:alisha.barnes.1@us.af.mil mailto:jeffery.webb.2@us.af.mil

Student Management System for Air University

Draft Performance Work Statement

REQUIREMENTS:

Admissions

• Ability to manage interaction with current and prospective students.

• Allow for “bulk list” import for admissions and enrollments.

• The system shall support student transfer of credits.

• The student shall be automatically notified of the result of the process (i.e. admitted or denied).

• The system should provide accurate and comprehensive student profile information.

• The system shall provide student updates and verification.

• The system shall provide automatic instructions to students who are admitted as to the next step (i.e. School/Program enrollment).

• The system shall assign, validate, update users unique “Air University Identification (AUID)” or interface with existing AUID software.

• Identify, document, and prioritize delivery of other admission process requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

Enrollment

• List of applicable course offerings for each student available for a specific period, as defined by “rules-based” criteria (i.e.

conditions, actions, exceptions or IF- THEN-ELSE logic). “Rules-based” criteria shall be configurable by users, employing utilizing the information system data fields name/titles (i.e. military experience, organization assigned to, current job role, etc.)

as conditions/discriminators for the rules for all AU programs where required.

• Allow the bulk roster of preselected students to be admitted into AU, enrolled into an academic program, and registered for a course.

• Allow for rules-based assignment criteria (i.e. military experience, organization assigned to, current job role, etc.) used to automatically assign members to courses.

• Allow for requests that qualify for automatic registration placed on hold for final review.

• Allow for class rosters to be automatically accomplished using all approved registered students.

• Allow Student Profiles to be automatically updated with registered courses.

• Allow students to be automatically notified of the result of the process (i.e. registered or denied).

• Allow for registered students who are registered to be automatically provided with instructions for the next step (i.e. Academic

& Program Advising).

• Student profiles need to be identifiable using a number generation associated with student information and something other than using a social security number.

Graduation & Program Completion

• Allow students to apply for graduation or request program completion, as required.

• Allow for a list of students to be entered for program completion verification.

• The system shall automatically perform academic evaluations to verify graduation or completion criteria have been met.

• Approved records (based on criteria) automatically update student transcript.

• Unapproved records are sent to selected staff for review.

• Students are automatically notified of Graduation/Completion status.

• Student Profile is updated with relevant data.

• Identify, document, and prioritize delivery of other graduation and program completion requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

Transcript

• Allow for student transcripts to be updated from LMS (Canvas, Blackboard, etc) with grades, completion, withdrawal, etc.

• Allow AU Registrar to update grades, completion, withdrawal, etc.

• Allow for transcripts to be certified, upon request, and sent to requester with notification and acknowledgement.

• Allow for an uncertified (unofficial) transcript to be provided upon authorized request, to include student self-service request.

• Allow for a list of completed courses to be provided upon authorized request.

• Identify, document, and prioritize delivery of other transcript process requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

Program Advising

• Allow students an automated, inherent, and internal request for advising.

• Allow instructors an automated, inherent, and internal ability to refer students for advising.

• Allow automated notification of the advising referral.

• If academic, allow for a student to be automatically assigned to an academic advisor and provide appointment scheduling.

• If a support function, allow for a student to be automatically referred to the proper support agency or if unclear, contacted for additional specifics.

• Allow for documented acceptance by the support agency.

• Allow for documented academic recommendation or support advising “action items”.

• Allow for documented satisfactory/unsatisfactory results for academic and support advising actions.

• Any additional advising actions and rule sets not covered above will need to be defined by contractors and AU to configure product.

Academic Course Catalog

• The course master database shall allow for initiation by either a specified timeline or by authorized course sponsors/directors.

• Allow for course revisions or curriculum changes.

• Allow for establishment of a review chain with suspense dates for approval.

• Allow for automatic notifications to be sent to the “active” reviewer who fails to complete the review in the allotted time and a notification also sent to the AU Registrar.

• Allow for automatic, broad notifications to be sent to targeted groups when a newly published Course Catalog is made accessible (i.e. Directors, Schedulers, Students, etc.).

• Identify, document, and prioritize delivery of other requirements not previously defined in POC as needed to produce course master database requirements.

Academic Scheduling

• Allow student quotas (AFERB, MAJCOMs, etc.) to be automatically distributed to relevant schools/programs.

• Allow for additional resources & facility needs to be identified if baseline is exceeded.

• Allow for courses offerings to be automatically created for specific dates, locations, and student numbers.

• Allow course conflicts to be identified and de-conflicted prior to preparing and publishing course catalog process.

• Allow for the final approved AU schedule to be sent to the LMS (Canvas).

• Allow students to be notified when new course offering registration is available.

• Allow for students to be placed on hold (i.e. “waitlist”) if a course offering is full, for faculty/staff to assign/drop student to the class.

• Identify, document, and prioritize delivery of other requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

Transfer & Test Credit Evaluation Process Requirements

• Allow for automated transcripts or test (CLEP, DANTES, SAT, ACT, etc.) results to be received and processed.

• Transcripts or test results are evaluated based on accredited criteria.

• Student records are updated with accepted results.

• Students are notified of Evaluation Process results.

• Receive and process transcripts external to the organization directly into the system

• Receive and process National Student Clearing House transfer credits and degrees.

Student Bursar

• Financial obligations are entered into student record upon successful course registration.

• Authorized invoices are sent to the student/sponsor agency and Bursar office.

• The system shall provide a payment method for the sponsor (i.e. government) agency.

• The system updates student accounts with payment.

• Student/sponsor agency are notified of account update or discrepancy.

• Students can register in additional courses without resolution of account.

• Identify, document, and prioritize delivery of other student bursar process requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

User Report Requirements

• Automated scheduled reports

• Ability to create custom reports based on data entered in the system.

• Allow for authorized user reports to be retrieved/generated and include any tools / software required.

• Identify, document, and prioritize delivery of other user report requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

User Logon Requirements

• The system shall support multi-factor authentication, including DoD Common Access Card (CAC) and integration with single sign-on solutions (i.e. Security Assertion Mark- up Language (SAML).

• Automated account notifications (changes, updates, security requirements, etc.).

• Allow for service desk functionality, to include administrative support to assist with user logon issues.

• Identify, document, and prioritize delivery of other user login requirements not previously defined in POC as needed to produce functionality of scheduling process requirements.

Access Control

• The system shall support role-based access control A single user account shall support multiple roles (i.e. “Adjunct

Faculty/Teacher” role at one school, “Student” role at a second school, and “School Admin” role at third school).

• Contractor shall provide a baseline matrix of roles and permissions inherent to the system that AU will model for deployment.

System Compliance

• Should comply with RMF or NIST accreditation of applications within Information Level 4 (IL4) DoD Government

Community Cloud and will be maintained compliant throughout this effort or life of the contract.

• Core software updates shall not impact current configured APIs when updating/patching software.

• Application shall have full functionality while hosted within IL4 Government Community Cloud.

• Should include an internal and external communication feature, that can transmit and receive messages from United States

Government e-mail exchanges (i.e. @us.af.mil, @mail.mil), with automated and configurable messages, able to inform, as defined by rules-based criteria, users (faculty, staff, students) of:

• Admissions, enrollment, registration, and assignment process actions

• Global, program, and course announcements

• Upcoming and overdue task and assignment alerts

• Message delivery failure

• Should include configurable “rules,” with condition(s), actions(s), and exception(s) parameters (i.e. IF-THEN-ELSE logic) that apply across the entire system.

Additional Information/Assumptions:

• AU is currently running SAP SLcM hosted in C1 AWS. AU’s Student Information System (SIS) has integrations with a LMS, DEERS, DMDC, ACQNOW, and MILPDS. The SIS manages the learner’s record from the time they enter the Air Force or apply for a program at

Air University. The learning record supports PCE, PME, and Higher Education degree granting programs.

• System data is PII - CUI

• Milestones - The critical milestones are immediate delivery capability to facilitate efficient onboarding.

• AU’s data is already in a data warehouse. ETL has been accomplished.

• Data Integrity - Data in system is accurate; there will be no cleansing LOE.

Student Management System for Air University

Response Requirements

Please include the following information in your contractor capability responses:

1. Vendor Information & Corporate Overview - This section establishes the vendor's basic credentials and eligibility for DoW contracts.

Information Requested Vendor Response

Company Name & CAGE Code

Point of Contact (Name, Email, Phone)

Business Size / Socio-Economic Status

Current Facility Clearance Level (FCL)

2. Security, Compliance & Hosting Capabilities - This section addresses the critical requirements for operating within a DoW IL-4 environment and ensuring system security.

Capability Requirement Vendor Approach /

Proposed Solution

Proof of Success (Certifications / ATOs)

DoW IL-4 Compliance Ability to design, manage, and maintain an architecture that meets DISA CC

SRG IL-4 for CUI.

Vendor Input Vendor Input: Provide details on existing

Provisional Authorizations or ATOs for IL-4 environments.

GovCloud Experience deploying and maintaining workloads specifically within Joint Warfighter

Community Cloud or Air Force Cloud 1.

Vendor Input Vendor Input: List relevant AWS

Competencies, specific contract numbers, or case studies.

User Authentication/System Integration Support for multi-factor authentication, including DoW

Common Access Card (CAC) and integration with

DoW business systems with single sign-on (SAML).

Vendor Input Vendor Input: Describe previous integrations with DoW authentication systems.

Access Control System support for role-based access control, where a single user can have multiple roles across different schools/programs.

Vendor Input Vendor Input: Provide a baseline matrix of roles and permissions inherent to the COTS solution.

3. Student information system or student management system requirements - This section requires vendors to detail their solution's ability to meet the specific functional requirements for each stage of the student lifecycle.

Capability Requirement Vendor's Technical Approach &

COTS Functionality

Proof of Success (Case Study / Metrics)

Admissions Process Managing prospective students, bulk import for admissions, credit transfer, automated notifications, and AUID assignment/interfacing.

Vendor Input Vendor Input: e.g., Number of applications processed annually, client examples.

Enrollment & Registration Configurable "rules-based" course assignment, bulk roster enrollment, automated roster creation, and waitlist management.

Vendor Input Vendor Input: e.g., Time saved via automated registration, number of students supported.

Graduation & Program Completion Automated academic evaluations for graduation verification, automated transcript updates, and status notifications.

Vendor Input Vendor Input: e.g., Accuracy rate of automated evaluations, client references.

Transcript Management Integration with Canvas

LMS for grade updates, registrar grade management, and generation of official/unofficial transcripts.

Vendor Input Vendor Input: e.g., Examples of successful

LMS integrations.

Program & Academic Advising Automated workflows for student or instructor-initiated advising referrals, advisor assignment, and documenting outcomes.

Vendor Input Vendor Input: e.g., Description of advising module functionality at a similar institution.

Academic Course Catalog Management of course databases, curriculum changes with approval chains, and automated notifications for catalog publication.

Vendor Input Vendor Input: e.g., Case study on curriculum management efficiency.

Academic Scheduling Automatic distribution of student quotas, resource/facility management, conflict identification, and integration with Canvas

LMS.

Vendor Input Vendor Input: e.g., Metrics on scheduling efficiency or conflict reduction.

Credit Evaluation Automated processing of external transcripts (CLEP, DANTES, National

Student Clearing House) and test results against accredited criteria.

Vendor Input Vendor Input: e.g., List of standard tests/sources supported out-of-the-box.

Reporting & Analytics Capability for automated/scheduled reports and allowing authorized users to create custom reports from system data.

Vendor Input Vendor Input: e.g., Showcase the user interface for custom report generation.

4. Implementation & Integration Methodology - This section addresses the vendor's strategy for deployment, customization, and integration.

Topic Vendor Response

Deployment Timeline & Methodology

Provide a realistic, phased timeline from award to Full Operational Capability (FOC), assuming an agile deployment for 23 programs. Should be iteratively deployable building out and enabling AU programs to go live with initial capabilities withing four months of award and maintain a level of delivery until all programs are migrated.

COTS vs. Customization What percentage of the requirements can be met with out-of-the-box COTS functionality? The only acceptable custom development is for military persona data.

Integration Strategy How will you architect integrations with existing systems (AUID, Canvas LMS, etc.) for ingestion into the Envision data fabric? Describe your use of standard APIs, middleware, or custom connectors.

Project Resourcing Describe the team of SMEs you will provide to accomplish this transformation, assuming minimal technical support from the Air Force.

5. Past Performance - Vendors should provide verifiable details on their most relevant past contracts, prioritizing mature products in use at equally large institutions.

Past Performance Detail Contract Reference 1 Contract Reference 2

Customer / Agency / School Name / Program types / Number of programs

Vendor Input Vendor Input

Contract Scope (Must mention Cloud, IL-4, Student Management or

Student Information System)

Vendor Input Vendor Input

Measurable Outcomes (e.g., Deployed a COTS SIS for X users, achieved Y% efficiency gain. Include schedule/cost)

Vendor Input Vendor Input

Customer Point of Contact (For verification) Vendor Input Vendor Input

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