diff --git a/Day 6-9 (writing a requirements document)/Campus visits.html b/Day 6-9 (writing a requirements document)/Campus visits.html index e6af932..d4552bc 100644 --- a/Day 6-9 (writing a requirements document)/Campus visits.html +++ b/Day 6-9 (writing a requirements document)/Campus visits.html @@ -1,7 +1,7 @@ Campus visits.md

Campus visits

Prepared by: Michael Kowalczyk
-Revision date: 9/11/2024

+Revision date: 9/12/2024

Overview

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

    @@ -78,15 +78,15 @@ Revision date: 9/11/2024

    UML Diagram

    Queries

    -

    These queries can be performed by any user.

    +

    Unless stated otherwise, 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.

    +

    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.

    -

    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.

    +
  1. ChangePassword - Parameters: user, password.
    2. +
  2. SetEmailLinkTimeout - Parameters: numberOfDays. Indicates the number of days which email links remain active, after which the link gives an error message.
    3. + +

    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.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    EventCoordinatorFacultyAdmin
    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.

    \ No newline at end of file diff --git a/Day 6-9 (writing a requirements document)/CampusVisits.md b/Day 6-9 (writing a requirements document)/CampusVisits.md index 295ff72..015087e 100644 --- a/Day 6-9 (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/11/2024 +Revision date: 9/12/2024 ## Overview @@ -65,7 +65,7 @@ We would like a system to address the following: ## Queries -These queries can be performed by any user. +Unless stated otherwise, these queries can be performed by any user. - **Q1** - List visits. *Parameters: startDate, endDate, assignedFaculty, currentStatus* (any or all of these can be omitted, and assignedFaculty may be "none" to search for unassigned visits). *Result:* For each visit matching all of the parameters given: list student name(s), day, possibleTimes, decidedTime, decidedGuide, and status. Sorted by visit day. - **Q2** - View visit. *Parameters: visitID*. View all attributes for the given visit, and also the associated committment level for each faculty member in the system. @@ -74,7 +74,7 @@ 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. +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. - *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 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). @@ -86,7 +86,8 @@ There are only a few problem domain events of interest. For each of these a sou - *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. +- *ChangePassword* - *Parameters:* user, password. +- *SetEmailLinkTimeout* - *Parameters:* numberOfDays. Indicates the number of days which email links remain active, after which the link gives an error message. ![UML Diagram](eventsAndVisitStates.png "Event sequences") @@ -95,7 +96,7 @@ There are only a few problem domain events of interest. For each of these a sou **R1** - The system notifies faculty via email under any of the following circumstances: - A new *visitRequest* is made - The faculty member is the *decidedGuide* for a visit which is scheduled for tomorrow -- Periodic reminders for faculty members who have an unknown committment level for one or more proposted visits. +- Periodic reminders for faculty members who have an unknown committment level for one or more proposed visits. **R2** - The system notifies coordinators via email under any of the following circumstances: - Periodic reminders for visits that are in the *proposed* state. @@ -111,27 +112,31 @@ There are only a few problem domain events of interest. For each of these a sou ## 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: -- 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: -- 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: -- create a new user. -- change any user's name, email, password, or roles. - -Any user can: -- change their password. +| 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. +**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.