Admissions Application - Kosudo/nextSIS GitHub Wiki

Outline

The following student application process must be supported:

• A secure online application form outside the normal login authorisation
• Prior email verification system for the online form to protect against spam
• Support for multiple languages (parents do not necessary speak the same language as the school)
• Documentation upload and document approval/query management

Document approval/query management

While the process envisages that documents will be uploaded rather than posted, the system should support either method. The outline process is:

• [Create an account] (admissions-create-an-account) - incorporating an initial checklist which the prospective student must meet
• nextSIS emails applicant to confirm account creation (spam protection)
• Applicant can now access an application form, which is completed and documents uploaded
• Office staff see completed application and decline, approve or query back to applicant
• Once the application is accepted, the applicant is prompted for payment
• Once payment is made, the student joins the waiting list and the applicant is informed
• The student can now be assigned to classes for the following year while on the waiting list

Specifying the process at admin level (probably version 2)

While we can specify an outline process, in developing a system for use across many schools we face the reality that they have different procedures, so a designed needs to be arrived at to model this. The result is that we need to model the workflow of each school, and it helps to define this in project management terms, as a series of tasks with dependencies. So in our system an administrator should be able to define this workflow by specifying tasks which are then presented within a management interface to the admissions office.

For example, the user enters a task called 'Letter A', which is the initial application pack sent to a parent. This contains 'Form B' within it which we are expecting to receive along with 'Document C' and 'Document D' - which the school requires. If 'Form B' is received but there is a problem with 'Document C' - or it simply isn't received - this is flagged up in the interface and the system knows that any dependent tasks can't begin. Along the way, certain individuals need to approve documents or the whole application, so these can be assigned to tasks in the system.

These task lists serve as an interface to the completed documents or the screens required to approve a document or application. The list supports paper documents with the option to allow electronic documents within the system to be supported.

This is probably functionality for version 2 unless it doesn't prove possible to design a simpler fixed system which can accommodate the project's current stakeholders.

To summarise:

• Admissions tasks are created
• Tasks can have dependencies
• Tasks can have people assigned to them
• The task list models the school's admissions workflow and acts as an interface to documents and the approval process