2.1 Giới thiệu

Phân tích hệ thống là giai đoạn quan trọng giúp hiểu đúng và đầy đủ các yêu cầu từ người dùng cuối (end-user), từ đó chuyển hóa thành tài liệu đặc tả phục vụ cho các bước thiết kế và phát triển phần mềm.

Mục tiêu của chương này:

• Hướng dẫn sinh viên cách thu thập và xử lý yêu cầu dự án.
• Học cách sử dụng MoSCoW để phân loại yêu cầu.
• Mô hình hóa Use Case Diagram cho hệ thống.
• Viết tài liệu đặc tả (Software Requirement Specification – SRS).

2.2 Các bước phân tích hệ thống

2.2.1 Khảo sát yêu cầu

Khảo sát bao gồm:

• Phỏng vấn người dùng cuối, khách hàng (client).
• Quan sát quy trình vận hành thực tế.
• Xem xét tài liệu, hệ thống cũ nếu có.

Ví dụ: Dự án “Quản lý lớp học tại trung tâm tiếng Anh”:

• Phỏng vấn quản lý trung tâm → yêu cầu chức năng quản lý học viên, khoá học.
• Quan sát quy trình đăng ký tại quầy → bổ sung chức năng import danh sách từ Excel.

2.2.2 Định nghĩa yêu cầu hệ thống

Yêu cầu chức năng (Functional Requirements):

• Cho phép học viên đăng ký tài khoản, chọn khoá học.
• Cho phép admin thêm/sửa/xoá khoá học.
• Hệ thống gửi email xác nhận khi đăng ký thành công.

Yêu cầu phi chức năng (Non-Functional Requirements):

• Hệ thống phải hoạt động 24/7.
• Phản hồi trong vòng < 3 giây.
• Giao diện hỗ trợ di động.

2.2.3 Ưu tiên yêu cầu bằng MoSCoW

• Must have: Đăng ký tài khoản, phân quyền người dùng.
• Should have: Thống kê số lượng học viên theo khoá.
• Could have: Tự động nhắc lịch qua email.
• Won’t have (hiện tại): Kết nối trực tiếp với Zalo hoặc Facebook Messenger.

2.3 Đặc tả hệ thống bằng Use Case

2.3.1 Use Case Diagram

Sử dụng UML để biểu diễn tương tác giữa người dùng và hệ thống.

Các Actor phổ biến:

• Admin
• Học viên
• Giáo viên

Use Cases mẫu:

• Đăng ký tài khoản
• Đăng nhập
• Quản lý khoá học
• Gửi thông báo
• Đăng ký học

2.3.2 Mô tả chi tiết Use Case

Mẫu mô tả:

• Tên Use Case: Đăng ký khoá học
• Actor: Học viên
• Mô tả: Học viên chọn khoá học và xác nhận đăng ký
• Điều kiện tiên quyết: Đăng nhập thành công
• Kết quả mong đợi: Ghi nhận đăng ký và gửi email

2.4 Tài liệu đặc tả phần mềm (SRS)

Cấu trúc chuẩn của SRS:

1. Mục đích hệ thống
2. Tổng quan chức năng
3. Yêu cầu chi tiết (chia theo module)
4. Giới hạn hệ thống
5. Giả định và phụ thuộc
6. Mô hình Use Case, sơ đồ hoạt động (nếu có)

2.5 Ví dụ thực hành hoàn chỉnh

Tên đề tài: Hệ thống đăng ký khóa học trung tâm tiếng Anh

1. Danh sách yêu cầu chức năng:

• Đăng ký tài khoản
• Đăng nhập hệ thống
• Hiển thị danh sách khoá học
• Đăng ký một khoá học
• Xem lịch sử đăng ký

2. MoSCoW:

Loại	Yêu cầu
Must	Đăng ký tài khoản, đăng nhập, chọn khoá học
Should	Gửi email xác nhận, xem lịch sử đăng ký
Could	Gợi ý khoá học tương tự
Won’t	Tính năng thanh toán online (hiện chưa triển khai)

3. Use Case Diagram: (Chèn sơ đồ minh họa hoặc mô tả dạng văn bản)

• Học viên —> [Đăng nhập], [Xem khoá học], [Đăng ký học]
• Admin —> [Thêm khoá học], [Quản lý người dùng]

4. Mô tả Use Case: Đăng ký học

• Tên: RegisterCourse
• Actor: Học viên
• Input: Mã khoá học, thông tin học viên
• Output: Ghi nhận vào DB, hiển thị thông báo + gửi email

5. Trích đoạn SRS:

Hệ thống phải hỗ trợ tối thiểu 1000 lượt đăng ký đồng thời. Toàn bộ thông tin khoá học phải có trường mã khoá, tiêu đề, mô tả, giảng viên phụ trách và học phí. Mỗi học viên chỉ có thể đăng ký một lần cho mỗi khoá.

2.6 Tổng kết chương

• Phân tích đúng là bước nền móng quan trọng nhất cho thiết kế.
• Tài liệu SRS và sơ đồ Use Case là yêu cầu bắt buộc trong báo cáo dự án.
• Sinh viên cần trình bày rõ logic, không copy mẫu nếu không giải thích được.