Use Case Diagrams & Detailed Use Cases — School Management System (SMS)

byMy Scribble Pads •

Contents

  1. High-Level Use Case Diagram (visual)
  2. Module-level Use Case Diagrams (visual)
  3. Detailed Use Case Templates (reusable)
  4. Example Detailed Use Cases (Student Registration, Mark Attendance, Pay Fees)

1. High-Level Use Case Diagram (visual)



Below is a visual (Mermaid/graph) view of actors and main system use cases. You can paste this into any Markdown viewer that supports Mermaid to render the diagram.

graph LR
  %% Actors
  Admin[Admin]
  Teacher[Teacher]
  Student[Student]
  Parent[Parent]
  Librarian[Librarian]
  Driver[Driver]

  %% Use Cases
  MU_ManageStudents[(Manage Students)]
  MU_Attendance[(Manage Attendance)]
  MU_Fees[(Manage Fees)]
  MU_Exams[(Manage Exams & Results)]
  MU_Timetable[(Manage Timetable)]
  MU_Library[(Manage Library)]
  MU_Transport[(Manage Transport)]
  MU_Communication[(Communication & Notifications)]
  MU_HR[(HR & Payroll)]
  MU_Reports[(Reports & Analytics)]

  %% Connections
  Admin -- manages --> MU_ManageStudents
  Admin -- configures --> MU_Fees
  Admin -- configures --> MU_Timetable
  Admin -- manages --> MU_HR
  Admin -- views --> MU_Reports

  Teacher -- uses --> MU_Attendance
  Teacher -- uses --> MU_Exams
  Teacher -- uses --> MU_Communication

  Student -- uses --> MU_Timetable
  Student -- uses --> MU_Exams
  Student -- uses --> MU_Communication

  Parent -- uses --> MU_Fees
  Parent -- uses --> MU_Communication
  Parent -- uses --> MU_Transport

  Librarian -- uses --> MU_Library
  Driver -- uses --> MU_Transport

  MU_ManageStudents --- MU_Reports
  MU_Attendance --- MU_Reports
  MU_Fees --- MU_Reports
  MU_Exams --- MU_Reports

2. Module-level Use Case Diagrams (visual)

Fee Management (Actors: Admin, Parent)

graph LR
  Admin[Admin]
  Parent[Parent]
  UC_GenerateInvoice[(Generate Invoice)]
  UC_PayFees[(Pay Fees)]
  UC_TrackPending[(Track Pending Payments)]
  UC_SendReminder[(Send Payment Reminder)]

  Admin -- performs --> UC_GenerateInvoice
  Parent -- performs --> UC_PayFees
  Admin -- performs --> UC_TrackPending
  Admin -- performs --> UC_SendReminder
  UC_PayFees --> UC_TrackPending

Attendance Management (Actors: Teacher, Admin, Student)

graph LR
  Teacher[Teacher]
  Admin[Admin]
  Student[Student]
  UC_MarkAttendance[(Mark Attendance)]
  UC_ViewHistory[(View Attendance History)]
  UC_GenerateReport[(Generate Attendance Report)]

  Teacher -- performs --> UC_MarkAttendance
  Student -- performs --> UC_ViewHistory
  Admin -- performs --> UC_GenerateReport
  UC_MarkAttendance --> UC_GenerateReport

Transport Management (Actors: Admin, Parent, Driver)

graph LR
  Admin[Admin]
  Parent[Parent]
  Driver[Driver]
  UC_AssignRoute[(Assign Bus Route)]
  UC_TrackBus[(Track Bus - GPS)]
  UC_ViewRoute[(View Route Details)]

  Admin -- performs --> UC_AssignRoute
  Parent -- performs --> UC_TrackBus
  Driver -- performs --> UC_ViewRoute

3. Detailed Use Case Template (Reusable)

Business Rules / Constraints:

Special Requirements (Security, Performance):

Acceptance Criteria:

Notes / Comments:

4. Example Detailed Use Cases

Use Case: Student Registration

Use Case ID: UC-001 Name: Student Registration Primary Actor: Admin Secondary Actors: Student (or parent, for self-registration)

Description: Admin registers a new student into the SMS with personal, academic, and contact details. System generates a unique student ID and stores documents.

Preconditions: Admin is authenticated and authorized. Required student data and documents are available.

Postconditions: Student profile is created and visible in the system. Student ID assigned.

Main Flow:

  1. Admin navigates to "Student Registration" page.
  2. Admin fills personal, academic, contact details and uploads mandatory documents.
  3. Admin submits the form.
  4. System validates inputs and creates student record.
  5. System generates unique Student ID and notifies Admin.

Alternate Flows / Exceptions:

  • If mandatory fields are missing, system shows validation errors and prevents submission.
  • If document upload fails, system retries and notifies the admin.

Business Rules / Constraints:

  • National ID must match chosen format (if collected).
  • Duplicate check based on name + DOB + parent contact.

Special Requirements:

  • All uploaded documents must be scanned and stored in encrypted form.

Acceptance Criteria:

  • Admin can create student with all required fields.
  • Student ID is unique.
  • Student profile is searchable in the system.

Use Case: Mark Attendance

Use Case ID: UC-002 Name: Mark Attendance Primary Actor: Teacher Secondary Actors: Admin (for reports)

Description: Teacher marks attendance for a class session. Attendance can be recorded per period or for the whole day.

Preconditions: Teacher is logged in and class list is available for the selected date/period.

Postconditions: Attendance records are saved and count toward reports.

Main Flow:

  1. Teacher selects class and date/period.
  2. System displays student list.
  3. Teacher marks present/absent/late for each student.
  4. Teacher submits attendance.
  5. System saves attendance entries and updates attendance summary.

Exceptions:

  • Network error while saving — system queues the data for retry and informs teacher.

Business Rules / Constraints:

  • Only teachers assigned to the class can mark attendance.

Acceptance Criteria:

  • Attendance can be marked and viewed by students/parents.
  • Monthly attendance report reflects the data.

Use Case: Pay School Fees Online

Use Case ID: UC-003 Name: Pay School Fees Online Primary Actor: Parent Secondary Actors: Admin, Payment Gateway

Description: Parent views outstanding invoices and makes payment through integrated payment gateway. Receipt is generated on success.

Preconditions: Invoice generated and parent account is active.

Postconditions: Payment status is updated to "Paid" and receipt stored in transaction history.

Main Flow:

  1. Parent logs in and navigates to "Fees" section.
  2. Parent selects outstanding invoice and clicks "Pay".
  3. System redirects to payment gateway with invoice details.
  4. Parent completes payment on gateway.
  5. Gateway returns success response to SMS.
  6. System updates invoice status and generates receipt.

Alternate Flows / Exceptions:

  • Payment fails — system marks as "Failed" and allows retry.
  • Gateway timeout — system shows error and logs for manual follow-up.

Security & Compliance:

  • Payment data must follow applicable PCI-DSS guidelines.

Acceptance Criteria:

  • Parent can complete payment and receive receipt.
  • Admin dashboard reflects paid status immediately.
Tags:
Previous Post Next Post