Use Case Descriptions

Use Case 1: Input Constraints for Scheduling
Actors: User
Stakeholders and Needs:
User—To input the constraints for scheduling.
Participant—To receive best scheduling results, with all the constraints being considered.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The constraints are accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Constraints will not be saved if the User log out of the system or cancel the operation.
Trigger:
The User initiates the input constraints operation.
Basic Flow:
1. The User initiates the input constraints operation and enters the computer identifier.
2. The System displays the fields to be filled in.
3. The User enters all available constraints.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input constraints.
6. The System saves the constraints and informs the User that the operation is complete.
Extensions:
*a.The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the constraints.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.

Use Case 2: Input Required Data for Scheduling
Actors: User
Stakeholders and Needs:
User—To input required data such as participants’ matriculation numbers,
timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Data will not be saved if the User log out of the System or cancel the operation.
Trigger:
The User initiates the input data operation.
Basic Flow:
1. The User initiates the input data operation and enters the computer identifier.
2. The System displays the fields to be filled in and allows the uploading of files.
3. The User enters all available data and uploads required files.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
3a. The System is unable to accept uploaded files or uploaded files have
exceeded the maximum capacity.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled, the use case ends.

Use Case 2: Input Required Data for Scheduling
Actors: Server, User
Stakeholders and Needs:
User—To request the Server to input relevant data.
Server—To input required data such as participants’ matriculation numbers, timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The Server is allowed to interact with the System and has an identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the data. Data will not be saved if the Server closes connection with the System or the User initiates the cancellation of the operation.
Trigger:
The User requests for Server to input data into the System.
Basic Flow:
1. The User requests for Server to input data into the System and enters the computer identifier.
2. The User enters the Server identifier.
3. The Server starts searching for information and inputs data into the System.
4. The System verifies the inputs and asks for the User’s confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
2a. The Server identifier is invalid:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and activity resumes
3a. The Server is unable to acquire all relevant information.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes or he may
choose to cancel the operation.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes or he may
choose to end the operation.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled,
the use case ends.

Use Case 3: Request for Scheduling Results
Actors: User
Stakeholders and Needs:
User—To request for scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The scheduling process has completed successfully.
Postconditions:
The scheduling process gives the best possible result, considering all the constraints and input data.
Trigger:
The User initiates the request results operation.
Basic Flow:
1. The User initiates the request results operation after scheduling has been completed.
2. The System displays the best possible result.
3. The User can choose to send the results to the participants or log out
from the System.
Extensions:
*a.The User cancels the operation: The use case ends.
2a.No possible results can be generated:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and tries to reschedule or he can choose to end the operation.

Use Case 4: Send Scheduling Results to Participants
Actors: User, Participants
Stakeholders and Needs:
User—Approve the sending of scheduling results.
Participants—Get notified of the scheduling results.
Preconditions:
The scheduling process has completed successfully and the user has approved to sending out the results.
Postconditions:
Participants receive the best possible result successfully.
Trigger:
The User initiates the send results operation.
Basic Flow:
1. The User approves the result that the System has generated and initiates the send results operation.
2. The Participants get notified via email or other channels.
Extensions:
*a.The User cancels the operation: The use case ends.
1a. The User does not approve to the sending of results: the use case ends.
2a. Unsuccessful sending of results to the Participants:
2a1. The System alerts the User of the problem.
2a2. The User can choose to resend the results or cancel the operation.