Requirements, Flows, and Initial Brainstorming
As part of brainstorming how transfer equivalency is assessed and awarded at most schools, we defined these personas and tasks.
These personas were identified:
- Prospect: A student interested in applying that hasn’t yet submitted an application and is interested in having an rough idea of what credits could be transferred from a previous institution
- Applicant: A student that has applied and wants to submit a request to transfer credits from a previous institution. The student also needs to gather information about past approved transfers
- Registrar: An internal admissions employee responsible for managing, routing and approving the applicant request to transfer credits. As part of that process, the registrar needs to have access to pre-approved transfers.
These tasks/projects were identified:
- Define common use cases and parameters
- Define extensible Data Model to track pre-approved or past credit transfers. Include examples
- Define search criteria and algorithm to match pre approved credit transfers
- Define UI to allow end user to search for pre approved credit transfers based on the previous criteria
- Define process flow and UI to add new pre approved credit transfers
- Define process flow and UI to submit requests to approve credit transfers. This includes:
- Submission of a credit transfer request based on:
- Pre Approved Credit Transfers
- New requests
- Case management and routing to the proper registrar
- Statuses
- Routing to the registrars based on case status
- Submission of supporting documentation
- Iterative process that allows the student to correct and resubmit request based on comments
- Submission of a credit transfer request based on:
