The document outlines the use case diagrams for a course registration system, detailing various use cases including viewing results, course registration, course selection for teaching, submitting grades, and maintaining student information. Each use case specifies the scenario, triggering events, actors, preconditions, post-conditions, and potential success and failure scenarios. This structured approach serves to clarify the processes involved for students, teachers, and registrars within the system.

1. Assignment on use case
diagram using LaTex
Assignment topic:Course registration system
Submitted by:
Raisul Islam
ID:161-35-1468
Section:A
Submitted to:
Md. Alamgir Kabir
Lecturer
Department of Software Engineering
1

2. 2

3. 1 View result
1.1 Use case name: View result
1.2 Scenario:View corresponding result
1.3 Triggering event:When result published mail is seen by
student
1.4 Brief description:This use case allows a student to view
his/her result for the previously completed semester.
1.5 Actors:Student
1.6 Related use case:Submit Grades
1.7 Stakeholders:Student,University,Teacher
1.8 Preconditions:Teacher must submit result.The correspond-
ing students’ result must be in the system.
1.9 Post-conditions:The result page should be seen.
1.10 Flow of events:
1.10.1 Actor:
1. Student got the email.
2. Student put id and semester name in the box.
3. Student clicked show result button.
4. The result is shown.
1.10.2 System:
1. The system recognizes id and name.
2. If ”show result” button is clicked.The result will be displayed.
3

4. 1.11 Exception Conditions:
1. If student does not exist, the system shows error.
2. If student enter another student’s name and id, then different student’s result
will be shown.
1.12 Success scenarios:
1. The student clicked the view button and the view page is opened.
2. The student put corresponding Id and semester name in the box.
3. The student clicked the result button.
4. In the new page, there will be corresponding result.
1.13 Failure scenarios:
1. The view result button is not working.
2. The student put wrong Id and semester name in the box.
3. The student did not any course.
4. The result button is not working.
5. In the new page, there will be no corresponding result.
4

5. 2 Register for course
2.1 Use case name:Register for courses:
2.2 Scenario: To register course
2.3 Triggering event: When result was viewed, then the stu-
dent wishes to register courses, on the basis of their result.
2.4 Brief description:This use case allows a student to register
for courses in the current semester.
2.5 Actors: Student, course catalog
2.6 Related use case:View result
2.7 Stakeholders:Student, University, Register
2.8 Preconditions:The student must pass the exam
2.9 Post conditions:The student is assigned to courses
2.10 Flow of events:
2.10.1 Actor:
1. The student first view the result.
2. If the student pass all courses then he is eligible for registration.
3. The actor clicks register button.
2.10.2 System:
1. The system shows the ”Registration Completed” pop-up.
2.11 Exception Conditions:
1. If the courses are not present in the system, the student can not register for
courses.
5

6. 2. If the student clicks another subject to register, then the registration will be for
another subject.
2.12 Success scenarios:
1. The student went to ad visor.
2. The ad-visor open the course catalog.
3. The ad-visor assigned corresponding courses to the student.
2.13 Failure scenarios:
1. The ad-visor can not open the course catalog.
2. The ad-visor can not assign corresponding courses to the student.
3. The ”Registration Completed” pop-up message will not show up.
4. The student was not assigned to the courses.
6

7. 3 Select course to teach:
3.1 Use case name:Select course to teach
3.2 Scenario:To select corresponding courses for teaching.
3.3 Triggering event:Teacher was asked by the register to teach
3.4 Brief description:This use case allows a teacher to select
the courses from the course catalog for the courses that
he/she is eligible for.
3.5 Actors:Teacher, course catalog
3.6 Related use case:None
3.7 Stakeholders:Teacher, University, Register
3.8 Preconditions:Teacher must be authorized to take course
3.9 Post conditions:The teacher must take class.
3.10 Flow of events:
3.10.1 Actor:
1. The teacher is authorized to take course.
2. Teacher opens the course catalog.
3. Selects Corresponding courses to teach.
3.10.2 System:
1. The system authenticate teacher.
2. The corresponding courses selected by the teacher.
3.11 Exception Conditions:
1. If the system can not authenticate teacher, the teacher can not take courses.
7

8. 2. If teacher choose wrong course, then wrong corresponding routine will be shown.
3.12 Success scenarios:
1. The teacher opens the course catalog.
2. The teacher chose courses.
3. The registrar assigned the teacher to courses.
4. The registrar clicked the assigned button.
3.13 Failure scenarios:
1. The teacher did not open the course catalog.
2. The teacher did not chose courses.
3. The teacher could not find the corresponding courses.
4. The assigned button is not working.
8

9. 4 Submit grade
4.1 Use case name: submit result
4.2 Scenario:To submit result
4.3 Triggering event:After completion and compiling result,
the teacher submit result
4.4 Brief description:This use case allows a teacher to submit
grades for courses completed in the previous semester.
4.5 Actors:Teacher,University
4.6 Related use case:None
4.7 Stakeholders:Teacher, University
4.8 Preconditions:The teacher must compile the grades
4.9 Post conditions:The submitted grade must be correct.
4.10 Flow of events:
4.10.1 Actor:
1. The teacher compiled the corresponding Students grade.
2. After compiling grades, then the teacher submit the corresponding students
grades.
4.10.2 System:
1. The system stores the corresponding Students grades.
4.11 Exception Conditions:
1. Teacher submit grades corresponding to wrong students.
9

10. 4.12 Success scenarios:
1. The teacher clicked the submit button.
2. After clicking submit button the compiled result will be uploaded.
3. After submission pop-up message ”submitted” will be shown.
4.13 Failure scenarios:
1. The submit button will not appear.
2. After clicking submit button the compiled result will not be uploaded.
3. After submission ”Submitted” pop-up message will not be shown.
4. The ”Submit” button is not working.
10

11. 5 Maintain student info:
5.1 Use case name:Maintain student info
5.2 Scenario:Maintaining all students info
5.3 Triggering event:Register have to maintain all students’
info
5.4 Brief description:This use case allows Register to maintain
student information in the registration system.
5.5 Actors:Register
5.6 Related use case:None
5.7 Stakeholders:Registrar,Student,Teacher,University
5.8 Preconditions:None
5.9 Post conditions:Should be easy to maintain
5.10 Flow of events:
5.10.1 Actor:
1. Registrar would be able to add a student.
2. Registrar would be able to update a student.
3. Registrar would be able to delete a student.
5.10.2 System:
1. None
5.11 Exception Conditions:
1. Registrar may add a wrong Student.
2. Registrar may update a wrong Student.
11

12. 3. Registrar may delete a wrong Student.
5.12 Success scenarios:
1. When ”Maintain Student Info” button is clicked a new page is opened.
2. In this newly opened page the registrar can add a student.
3. In this newly opened page the registrar can update a student.
4. In this newly opened page the registrar can delete a student.
5. After clicking ”save” button the ”Maintain Student Info” use case ends.
5.13 Failure scenarios:
1. When ”Maintain Student Info” button clicked a new page is no opened.
2. In this newly opened page the registrar can not add a student.
3. The update button is not appeared.
4. The delete button will not appear.
5. The ”Save” button is not working.
12