From d2475c484547577bc07fc391f16eee84d0854565 Mon Sep 17 00:00:00 2001 From: Some User Date: Wed, 11 Sep 2024 08:54:08 -0400 Subject: [PATCH] Day 9 --- .../Campus visits.html | 150 ----------------- .../Campus visits.html | 154 ++++++++++++++++++ .../CampusVisits.md | 34 ++-- .../entityRelationships.png | Bin .../entityRelationships.puml | 0 .../eventsAndVisitStates.png | Bin .../eventsAndVisitStates.puml | 0 7 files changed, 174 insertions(+), 164 deletions(-) delete mode 100644 Day 6-8 (writing a requirements document)/Campus visits.html create mode 100644 Day 6-9 (writing a requirements document)/Campus visits.html rename {Day 6-8 (writing a requirements document) => Day 6-9 (writing a requirements document)}/CampusVisits.md (81%) rename {Day 6-8 (writing a requirements document) => Day 6-9 (writing a requirements document)}/entityRelationships.png (100%) rename {Day 6-8 (writing a requirements document) => Day 6-9 (writing a requirements document)}/entityRelationships.puml (100%) rename {Day 6-8 (writing a requirements document) => Day 6-9 (writing a requirements document)}/eventsAndVisitStates.png (100%) rename {Day 6-8 (writing a requirements document) => Day 6-9 (writing a requirements document)}/eventsAndVisitStates.puml (100%) diff --git a/Day 6-8 (writing a requirements document)/Campus visits.html b/Day 6-8 (writing a requirements document)/Campus visits.html deleted file mode 100644 index 644d4e0..0000000 --- a/Day 6-8 (writing a requirements document)/Campus visits.html +++ /dev/null @@ -1,150 +0,0 @@ -Campus visits.md -

Campus visits

-

Prepared by: Michael Kowalczyk
-Revision date: 9/10/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. -
  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. -
  3. Professors email back saying that they can take the visit (or not) and at what time.
    4. -
-

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

-

These queries can be performed by any user.

- -

Events

-

There are only 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.

-

Users with the coordinator role can:

- -

Users with the faculty role can:

- -

Users with the admin role can:

- -

Any user can:

- -

Security

- -

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.

- - \ No newline at end of file diff --git a/Day 6-9 (writing a requirements document)/Campus visits.html b/Day 6-9 (writing a requirements document)/Campus visits.html new file mode 100644 index 0000000..e6af932 --- /dev/null +++ b/Day 6-9 (writing a requirements document)/Campus visits.html @@ -0,0 +1,154 @@ +Campus visits.md +

Campus visits

+

Prepared by: Michael Kowalczyk
+Revision date: 9/11/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. +
  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. +
  3. Professors email back saying that they can take the visit (or not) and at what time.
    4. +
+

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

+

These queries can be performed by any user.

+ +

Events

+

There are only 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.

+

Users with the coordinator role can:

+ +

Users with the faculty role can:

+ +

Users with the admin role can:

+ +

Any user can:

+ +

Security

+ +

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.

+ \ No newline at end of file diff --git a/Day 6-8 (writing a requirements document)/CampusVisits.md b/Day 6-9 (writing a requirements document)/CampusVisits.md similarity index 81% rename from Day 6-8 (writing a requirements document)/CampusVisits.md rename to Day 6-9 (writing a requirements document)/CampusVisits.md index 451af02..295ff72 100644 --- a/Day 6-8 (writing a requirements document)/CampusVisits.md +++ b/Day 6-9 (writing a requirements document)/CampusVisits.md @@ -2,7 +2,7 @@ # Campus visits Prepared by: Michael Kowalczyk -Revision date: 9/10/2024 +Revision date: 9/11/2024 ## Overview @@ -76,11 +76,17 @@ These queries can be performed by any user. There are only 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. - *VisitRequest* - the Campus Visit office contacts the department secretary with information pertaining to a new campus visit. *Parameters*: date, possible times, student name, other visitor names, and majors/minors of interest. *Source:* department secretary keys in the data (coordinator role). -- *ClaimVisit* - a faculty member decides to do a visit. *Parameters*: visit, decidedGuide, decidedTime. *Source:* faculty member. +- *ClaimVisit* - a faculty member decides to do a visit. *Parameters*: visit, decidedGuide, decidedTime. *Source:* faculty member or coordinator. NOTE: If the coordinator claims a visit for a faculty member, then the faculty member must receive a notification (unlike the case where a faculty member claims a visit for himself). - *ConfirmVisit* - the department secretary contacts the Campus Visit office that someone has taken the visit. Parameters: visit's *decidedGuide* and *decided time*. *Source:* department secretary (coordinator role). - *CancelVisit* - the campus visit office notifies the department secretary that the visit has been cancelled by the student. *Parameters:* Visit. *Source:* department secretary (coordinator role). - *AbaondonVisit* - some circumstance has caused the faculty member to vacate the guide position for a visit. *Parameters:* Visit. *Source:* faculty member. - *VisitTimePassed* - the *decidedTime* for the visit plus an hour has passed in Eastern Time. +- *AdjustNotificationFrequency* - *Parameters:* Visit, numberOfDays. Sets the frequency for periodic notifications to the given number of days. *Source:* department secretary (coordinator role) +- *SetCommittmentLevel* - a faculty member sets (or clears) their committment level for a particular visit. *Parameters:* faculty, visit, level. *Source:* faculty. Invariant: The committment level must always be "can do" for the assigned guide, if any. +- *EditAvailableTimes* - *Parameters:* faculty, subset of daytime hours for each weekday. Sets the available times for that faculty member. +- *CreateUser* - *Parameters:* name, email, password, roles. +- *EditUser* - *Parameters:* user, plus one or more of: name, email, password, roles. +- *Change password* - *Parameters:* user, password. ![UML Diagram](eventsAndVisitStates.png "Event sequences") @@ -106,26 +112,26 @@ There are only a few problem domain events of interest. For each of these a sou Users act in different roles with regard to editing the system's internal model of campus visits. Users with the coordinator role can: -- **R6** - adjust notification frequency for **R1** and **R2** on a per-visit basis. -- **R7** - establish a new visit request. -- **R8** - claim a visit, acting on behalf of a faculty member (Note: in this case, the faculty member must still get the visit claim notification). -- **R9** - set an *assigned* visit to *confirmed*, and can set a visit to *canceled* at any time. +- adjust notification frequency for **R1** and **R2** on a per-visit basis. +- establish a new visit request. +- claim a visit, acting on behalf of a faculty member (Note: in this case, the faculty member must still get the visit claim notification). +- set an *assigned* visit to *confirmed*, and can set a visit to *canceled* at any time. Users with the faculty role can: -- **R10** - set a level of committment and/or claim visits that are in the *proposed* state. Note that a "*can do*" level of committment is implied when a faculty member is the guide for a given visit. -- **R11** - abandon visits for which they are the *decidedGuide*. -- **R12** - edit *availableTimes* +- set a level of committment and/or claim visits that are in the *proposed* state. Note that a "*can do*" level of committment is implied when a faculty member is the guide for a given visit. +- abandon visits for which they are the *decidedGuide*. +- edit *availableTimes* Users with the admin role can: -- **R13** - create a new user. -- **R14** - change any user's name, email, password, or roles. +- create a new user. +- change any user's name, email, password, or roles. Any user can: -- **R15** - change their password. +- change their password. ## Security -- **R16** - The web app portal is password-protected and served over HTTPS, exclusively. -- **R17** - 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. +- **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. diff --git a/Day 6-8 (writing a requirements document)/entityRelationships.png b/Day 6-9 (writing a requirements document)/entityRelationships.png similarity index 100% rename from Day 6-8 (writing a requirements document)/entityRelationships.png rename to Day 6-9 (writing a requirements document)/entityRelationships.png diff --git a/Day 6-8 (writing a requirements document)/entityRelationships.puml b/Day 6-9 (writing a requirements document)/entityRelationships.puml similarity index 100% rename from Day 6-8 (writing a requirements document)/entityRelationships.puml rename to Day 6-9 (writing a requirements document)/entityRelationships.puml diff --git a/Day 6-8 (writing a requirements document)/eventsAndVisitStates.png b/Day 6-9 (writing a requirements document)/eventsAndVisitStates.png similarity index 100% rename from Day 6-8 (writing a requirements document)/eventsAndVisitStates.png rename to Day 6-9 (writing a requirements document)/eventsAndVisitStates.png diff --git a/Day 6-8 (writing a requirements document)/eventsAndVisitStates.puml b/Day 6-9 (writing a requirements document)/eventsAndVisitStates.puml similarity index 100% rename from Day 6-8 (writing a requirements document)/eventsAndVisitStates.puml rename to Day 6-9 (writing a requirements document)/eventsAndVisitStates.puml