Use cases

Client-defined use cases

These use cases serve as a foundation for the development and implementation of features within the application.

General use cases

User wants to create an account or log in

1. User opens the application
2. User gets redirected to the application (if not yet logged in)
3. User clicks on "Log In"
4. User logs in using CAS
5. User gets redirected to the application dashboard

For the use cases that follow, we assume the user has already succesfully logged in

Student use cases

Student wants to access information regarding a specific course

1. Student lands on the dashboard
2. Student selects a course
3. Student lands on the information page about this course

Student wants to upload a submission

1. Student lands on the dashboard
2. Student selects a course
3. Student selects a project from the information page about this course
4. Student clicks on the "Upload a submission" button
5. Student selects files and clicks on the "Submit" button

Student wants to see recent submissions for a course

1. Student lands on the dashboard
2. Student selects a course
3. Student can see the most recent submissions for this course

Student wants to join a group

1. Student lands on the dashboard
2. Student selects a course
3. Student selects a project
4. Student gets an overview of the available groups
5. Student selects the group they want to join

Professor use cases

Professor wants to create a course

1. Professor lands on the dashboard
2. Professor clicks on the "create a course" button
3. Professor fills out necessary course fields
4. Professor submits the form

Professor wants a summary of submissions for a project

1. Professor lands on the dashboard
2. Professor selects (or searches) a course
3. Professor selects a project under the selected course
4. Professor sees an overview of submissions for the selected project

Professor wants to manage basic submission tests for a project

1. Professor lands on the dashboard
2. Professor selects (or searches) a course
3. Professor selects a project under the selected course
4. Professor clicks on the "Edit Project" button
5. Professor lands on the "Edit Project" interface
6. Professor changes the basic tests

Professor wants to change visibility of a project

1. Professor lands on the dashboard
2. Professor selects (or searches) a course
3. Professor selects a project under the selected course
4. Professor toggles the visibility of the selected project

Professor wants to manage assistants

1. Professor lands on the dashboard
2. Professor selects (or searches) a course
3. Professor sees a list of assistants for the selected course
   • Professor clicks on the "add" button, a pop-up appears with a search input for adding assistants
   • Professor clicks on the "remove" button to remove assistants from the list

Professor wants to download submissions for a project

1. Professor lands on the dashboard
2. Professor selects (or searches) a course
3. Professor selects a project under the selected course
4. Professor has the option to either:
   • Download all the submissions for the project
   • Download a single submission, given a group

Assistant use cases

These use cases overlap with those of professors, minus some professor-specific capabilities such as creating a course or managing assistants of a course.

Admin use cases

Admin wants to manage roles

1. Admin lands on the dashboard
2. Admin selects (or searches) the name of a specific user
3. Admin changes the role of this user