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, if camera activation will only be available for the presenter, if a whiteboard will be used, if the lecture will be recorded, lecture date, lecture schedule, and attendees whitelist definitions are added to the database. All field 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. Database is not affected.
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. Database is not affected.
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, if camera activation will only be available for the presenter, if a whiteboard will be used, if the lecture will be recorded, lecture date, lecture schedule, and attendees whitelist definitions are updated in the database.
(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 field 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 field 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, if camera activation will only be available for the presenter, if a whiteboard will be used, if the lecture will be recorded, lecture date, lecture schedule, and attendees whitelist definitions) is deleted from the database. All field 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).