BBB BUC Prof MngLecture

From CDOT Wiki
Jump to: navigation, search

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.


Successful Post-conditions:

  • User gets a feedback message informing that transaction was successful.
  • Lecture is deleted.
  • User see updated calendar page (without the lecture).