As outlined in the UI Overview, the Scheduler system is comprised of three levels of access. The access level of each user is predetermined by the system and the user is shown only what they have access to. Students only have access to view published schedules. Teachers have access to view schedules as well as fill in their teaching time and course preferences. Admins have full access to the Scheduler application.

If the authentication system has determined that the curent user is a student, the application loads all information pertaining to the most recently published schedule for the student to see. The student has the ability to filter the schedule by instructor, course, and room, but no other actions may be performed by the student. Implementation of the interface for a student will require a full application with the appropriate options disabled.

If the authentication system determines that the current user is a teacher, the application not only loads all information from the most recently published schedule, but it also allows the teacher access to much more information. A teacher is also able to enter day and time preferences for when they like to teach classes as well as provide preferences to which classes they like to teach. Any changes made to the teacher's preferences is automatically updated on a department server. Implementation of the interface for a teacher will also require a scaled version of the application with certain options enabled and others disabled.

Those with administrator privledges have complete access. This level of access provides the administrator with the ability to generate a schedule. The algorithm that generates a schedule takes into account all resource constraints such as day and time patterns, teacher and course preferences, and all other administrative global constraints. The algorithm maps teachers to sections of courses and sections of courses to rooms on campus and ensures there are no time overlaps for a single teacher or time overlaps for classes in a room, and tries to minimize time overlap for popular courses that students like to take together. These constraints help to formulate the most appropriate schedule for the department. There is an algorithm to measure the schedule's ability to meet teacher preferences (fairness) and there is also an algorithm to measure the schedule's ability to meet teacher preferences and global constraints (goodness). Implementation of the schedule generation algorithm will be very complicated and must be done with extreme care to maximize efficency of the application and minimize errors that could be produced from schedule generation.

Administrators also manage the resources (Course, Instructor, Room) databases, the schedule database, the admin database, the blackout times, and the day patterns. Database management will be key, so a DMBS like MySQL will be used.

The distributed processing of the networked Scheduler environment will require specific development expertise. In particular, the developers need knowledge of client/server design and implementation. Functionality to support client/server architectures is available in many modern libraries. It will make sense for the developers to choose an implementation language in which client/server support is available, dependable, and well documented.