From 6eef1720e860c0f163fc6dd4c78c6ecbec077947 Mon Sep 17 00:00:00 2001 From: Some User Date: Thu, 5 Sep 2024 12:50:18 -0400 Subject: [PATCH] Day 6 --- Day 6 (problem domain entities)/CampusVisits.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Day 6 (problem domain entities)/CampusVisits.md b/Day 6 (problem domain entities)/CampusVisits.md index 9fc3601..4be316e 100644 --- a/Day 6 (problem domain entities)/CampusVisits.md +++ b/Day 6 (problem domain entities)/CampusVisits.md @@ -6,12 +6,12 @@ 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. 1. 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). - 1. Professors email back saying that they can take the visit and at what time. + 1. 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: - A professor might be *technically* available for a certain day, but it would be hectic to fit it in so they would rather someone else take that one. - Professors might delay in responding, reasoning that if they delay then someone else will take it. - - A professor might not be able to, but won't actually respond saying so. + - A professor might not be able to take the visit, but won't actually respond saying so. 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. @@ -21,13 +21,13 @@ We would like a system to address the following: - There should be some way of encouraging a balance between the number of visits assigned to various professors (perhaps there should be a record of number of visits taken, etc.) - We expect a quick turnaround time, so that the student has confirmation of which professor they are meeting with in, say, within a few days of the visit info coming to the department secretary. -- The system should eliminate the need for the secretary to nag and for the CS chair to poll to see if visits are taken or not. -- Address the "social loafing" problem by managing better communication between the professors (for example, some quick and convenient way of expressing "I can do this visit if nobody else is available, but I would rather not") +- The system should eliminate the need for the secretary to nag and for the CS chair to keep polling to see if visits are taken or not. +- Address the "social loafing" problem by managing better communication between the professors (for example, some quick and convenient way of expressing "I can do this visit if nobody else is available, but I would rather not"). The system may take this information into account when sending auto-notifications to the faculty. ## Entities - Users - - Role: zero or more of (Coordinator, admin, tour guide) + - Role: boolean for each of: (coordinator, admin, tour guide) - Busy times (for guides) - Visits - Possible times (start and end intervals) @@ -37,7 +37,7 @@ We would like a system to address the following: - Decided guide (if any) - Status (proposed, assigned, completed, cancelled, conflicting) - Visitors - - Role (propsective student, parent, etc.) + - Role (prospective student, parent, etc.) - Antipicated start semester - Antipicated majors, minors - Existing campus visit system to sync with?