BBB BUC Prof MngLecture
Manage Lectures
Brief Description:
User can manage lectures by creating, editing, and excluding them.
Scenario 1: Create new lecture.
Preconditions:
- User is authenticated.
- User is accessing the home page.
| Step# | Actor | System | Data Used |
|---|---|---|---|
| 1 | Clicks on the empty section of a calendar date or clicks the "Create Event" button. | Returns a page with editable fields regarding lecture details. | Database is not affected. |
| 2 | Chooses "Lecture" as type of event from the drop-down list. | "Event Type" field is set to "Lecture". | Database is not affected. |
| 3 | Fills in editable fields. | Filled in fields are respectively set. | Database is not affected. |
| 4 | Optionally, chooses to create a schedule by clicking the "Edit Schedule" button. | Returns a screen with editable fields regarding schedule details. | Database is not affected. |
| 5 | Fills in editable fields and chooses to save schedule. | Prompts if schedule information is correct. | Database is not affected. |
| 6 | Confirms whether or not inserted information is correct. | Returns to the page with previously filled in lecture details including updated schedule information. | Database is not affected. |
| 7 | (1). Chooses to save lecture, or (2). chooses to cancel lecture creation process. | (1). Persists lecture and schedule details. | (1). Lecture title, presenter-only camera, public whiteboard, lecture recorded, lecture date, lecture schedule, and attendees whitelist definitions are updated in the database. All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| (2). Discards inserted lecture and schedule details. | (2). Database is not affected. |
| Alternative event flow. |
Successful Post-conditions:
- User gets a feedback message informing that transaction was successful.
- A new lecture is added to user's calendar.
- On the screen, user has the option to create another lecture, to view the created lecture being shown in the calendar, and to simply return to the calendar page.
Scenario 2: Edit lecture.
Preconditions:
- User is authenticated.
- User is accessing the home page.
| Step# | Actor | System | Data Used |
|---|---|---|---|
| 1 | Searches a lecture by using the calendar and clicks the lecture label. | Returns a page with editable fields regarding the respective lecture. | All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| 2 | Makes changes in editable fields. | Filled in fields are correspondingly set. | Database is not affected. |
| 3 | Optionally, chooses to modify the schedule by clicking the "Edit Schedule" button. | Returns a screen with editable fields regarding schedule details. | Database is not affected. |
| 4 | Makes changes in editable fields and chooses to save schedule. | Prompts if edited schedule information is correct. | Database is not affected. |
| 5 | Confirms whether or not inserted information is correct. | Returns to the page with previously filled in lecture details including updated schedule information. | All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| 6 | (1). Chooses to save edited lecture, or (2). chooses to cancel lecture editing process. | (1). Persists edited lecture and schedule details. | (1). Lecture title, presenter-only camera, public whiteboard, lecture recorded, lecture date, lecture schedule, and attendees whitelist definitions are updated in the database. All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used |
| (2). Discards edited lecture and schedule details. | (2). Database is not affected. |
| Alternative event flow. |
Successful Post-conditions:
- User gets a feedback message informing that transaction was successful.
- Lecture has its information updated.
- User see updated lecture in the calendar page.
Scenario 3: Delete lecture.
Preconditions:
- User is authenticated.
- User is accessing the home page.
| Step# | Actor | System | Data Used |
|---|---|---|---|
| 1 | Searches a lecture by using the calendar, and clicks the lecture label. | Returns a page with editable fields regarding the respective lecture. | All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| 2 | Chooses to delete lecture by clicking the "Delete" button. | Prompts if lecture shall really be deleted. | All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| 3 | Confirms whether or not lecture shall be deleted. | Deletes lecture and schedule details. | All lecture data (lecture title, presenter-only camera, public whiteboard, lecture recorded, lecture date, lecture schedule, and attendees whitelist definitions) is deleted from the database. All fields in the 'lecture', 'lecture_schedule', 'lecture_presentation', 'lecture_attendance', and 'guest_lecturer' tables are used. |
| (2). Returns to home page. | (2). Database is not affected. |
Successful Post-conditions:
- User gets a feedback message informing that transaction was successful.
- Lecture is deleted.
- User see updated calendar page (without the lecture).