Campus visits

Prepared by: Michael Kowalczyk
Revision date: 9/12/2024

Overview

In the Math and CS Department, the current workflow for campus visits works as follows.

  1. The department secretary receives a campus visit request from the campus visit office.
  2. The secretary sends an email to the computer science professors asking if someone could take the visit. Information pertaining to the visit is included in this email (prospective student’s name, anticipated major, hometown, date of visit, and possible times that could be scheduled that day).
  3. Professors email back saying that they can take the visit (or not) and at what time.

The main problem is with the last step. Professors will often delay in responding, for a variety of reasons. For example:

This results in the secretary having to send multiple emails asking for someone to take the visit, and/or the CS chair polling the secretary to see if a visit is taken yet. When an incoming student doesn’t know if they will be meeting with a professor it sets a bad impression, especially for those who travel great distances for the campus visit.

System expectations

We would like a system to address the following:

Entities

UML Diagram

Queries

Unless stated otherwise, these queries can be performed by any user.

Events

There are a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.

UML Diagram

Notifications

R1 - The system notifies faculty via email under any of the following circumstances:

R2 - The system notifies coordinators via email under any of the following circumstances:

R3 - Both faculty and coordinators are notified if a faculty member has claimed or abandoned a visit (except for a faculty member who changed his own status)

Platform

R4 - All users can log into the system as a web app to perform actions suitable to their role(s).

R5 - Notifications are delivered via email, with embedded unguessable links so that likely actions pertaining to the notification can be performed in one click without logging in.

User permissions

Users act in different roles with regard to editing the system’s internal model of campus visits.

Event Coordinator Faculty Admin
VisitRequest
ClaimVisit ✔*
ConfirmVisit
CancelVisit
AbaondonVisit ✔*
VisitTimePassed (automatic)
AdjustNotificationFrequency
SetCommittmentLevel ✔*
EditAvailableTimes ✔*
CreateUser
EditUser
ChangePassword ✔+
SetEmailLinkTimeout

Legend:
✔ = The action is allowed by this user role.
✔* = The action can be performed by the coordinator, acting on behalf of a faculty member.
✔+ = The admin can change any user’s password (other users can only change their own).

Security

R6 - The web app portal is password-protected and served over HTTPS, exclusively.

R7 - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.

Preferences

Unnecessary email should be minimized. Within notification frequency, it would be preferable to have a single email containing notifications for all relevant visits rather than receiving a separate email for each notification.

Likely changes

Rules guiding notification frequency are likely to change. The coordinator has limited control over this, but experience with the system will help to understand how to best give the coordinator more granular control.