Mô hình sai nhiều bạn mang vào MIS201: đây là môn vẽ sơ đồ, cứ vẽ use case diagram cho đúng ký hiệu là qua. Hoặc ngược lại, đọc case xong nhảy ngay tới giải pháp "công ty nên làm một cái app". Cả hai đều bỏ qua phần mà môn này thật sự chấm: bạn có hiểu vấn đề kinh doanh và nhu cầu của từng stakeholder trước khi đề xuất gì hay không. Sơ đồ chỉ là cách trình bày sự hiểu đó.
Bài này đi qua ba case study report của MIS201 tại Deakin, mỗi bài một kỹ thuật cụ thể kèm công thức câu tiếng Anh để bạn áp vào case của mình. Nhiều bạn vẫn gọi môn này theo tên cũ là Business Requirements Analysis; tên chính thức trên Handbook 2026 là Digital Business Analysis.
Lưu ý, cập nhật 30/09/2026: cấu trúc dưới đây lấy từ trang unit MIS201 trên Deakin Handbook 2026 (unit mở ở Trimester 2 và Trimester 3). Handbook không nêu loại sơ đồ UML cụ thể; case, template và rubric nằm trên CloudDeakin. Tuần nộp có thể đổi, kiểm tra unit guide kỳ của bạn.
Tổng quan ba bài
| Bài | Hình thức | Trọng số | Độ dài | Hạn (theo Handbook 2026) |
|---|---|---|---|---|
| A1 | Case study cá nhân: report giải quyết vấn đề và mô hình hóa | 30% | 1.500 từ | Tuần 4 |
| A2 | Case study nhóm 4 người: report giải quyết vấn đề và mô hình hóa | 30% | 2.000 từ | Tuần 8 |
| A3 | Case study cá nhân: report giải quyết vấn đề và mô hình hóa | 40% | 1.500 từ | Tuần 11 |
Ba learning outcome của unit đi theo đúng thứ tự của một business analyst: phân tích bối cảnh và quy trình, phân tích nhu cầu stakeholder để ra requirement, rồi trình bày và biện minh khuyến nghị bằng chữ, hình và lời nói. Ba bài cũng leo dần theo thứ tự đó.
1. A1: viết problem statement tách nguyên nhân khỏi triệu chứng
A1 nộp tuần 4, khi bạn mới học được vài tuần. Người chấm chưa kỳ vọng giải pháp hoàn hảo; họ kỳ vọng bạn định nghĩa đúng vấn đề. Lỗi phổ biến nhất là lấy triệu chứng làm vấn đề: "khách phàn nàn nhiều" là triệu chứng, "quy trình đặt lịch dựa vào email thủ công nên trùng lịch" mới là nguyên nhân.
Currently, [stakeholder] [current process], which results in [measurable impact]. The underlying cause is [root cause], rather than [visible symptom].
Ví dụ: Currently, clinic receptionists record appointments in a shared spreadsheet and confirm them by email, which results in around ten double bookings per week. The underlying cause is the lack of a single real time booking record, rather than staff carelessness.
Sau câu này, mô hình hóa quy trình hiện tại (as-is) trước khi vẽ quy trình tương lai (to-be). Một activity diagram hay sơ đồ quy trình của as-is giúp người chấm thấy chính xác điểm gãy nằm ở bước nào. Tiêu chí bài này ăn điểm là phân tích bối cảnh, quy trình và cấu trúc của doanh nghiệp. Nếu cần luyện thêm phần định nghĩa vấn đề, đọc hướng dẫn problem discovery report.
2. Viết requirement đo được, gắn với stakeholder
Requirement mơ hồ là lỗi mất điểm nhiều nhất ở cả ba bài. "The system should be easy to use" không kiểm chứng được. Dùng hai khuôn: user story cho góc nhìn người dùng, và câu "shall" cho requirement có tiêu chí đo.
As a [stakeholder role], I need to [capability] so that [business outcome].
The system shall [function] [measurable condition], as needed by [stakeholder] (see [diagram element]).
Ví dụ: As a receptionist, I need to see all available time slots on one screen so that I can confirm a booking during the phone call. The system shall show slot availability updated within five seconds of any change, as needed by reception staff (see use case "Book Appointment").
Tách rõ functional requirement (hệ thống làm gì) và non-functional requirement (làm tốt tới mức nào: tốc độ, bảo mật, khả dụng). Khi stakeholder có nhu cầu mâu thuẫn, ví dụ bác sĩ muốn khung giờ linh hoạt còn quản lý muốn lịch kín, đừng giấu mâu thuẫn đi. Nêu nó ra và đề xuất cách ưu tiên. Tiêu chí ăn điểm là phân tích nhu cầu stakeholder để phát triển giải pháp phù hợp.
3. A2 nhóm: truy vết mọi requirement về stakeholder và sơ đồ
Bài nhóm 2.000 từ hay vỡ vì bốn người viết bốn phần, mỗi phần một cách đặt tên. Phần stakeholder gọi "customer", sơ đồ gọi "patient", requirement gọi "user". Người chấm đọc thấy ngay đây là bốn bài dán lại.
Cách khắc phục: phân một người giữ bảng thuật ngữ và bảng truy vết (traceability) từ tuần đầu. Mỗi requirement có mã (R1, R2...), mỗi mã chỉ về một stakeholder và một phần tử trên sơ đồ.
Requirement [ID] addresses [stakeholder]'s need to [need], and is modelled in [diagram name] as [element].
Ví dụ: Requirement R4 addresses the practice manager's need to monitor no-show rates, and is modelled in the use case diagram as "Generate Attendance Report".
Chia việc sớm và ghi lại ai làm gì để tránh cảnh chạy nước rút tuần 8; xem thêm cách chia việc nhóm và xử lý free rider.
4. A3: so sánh phương án rồi mới khuyến nghị
A3 nặng nhất (40%) và chạm vào learning outcome thứ ba: trình bày và biện minh khuyến nghị. Một khuyến nghị không có phương án so sánh chỉ là ý kiến. Đưa ít nhất hai phương án khả thi, đánh giá theo cùng một bộ tiêu chí (requirement đáp ứng được, chi phí, rủi ro, thời gian triển khai), rồi chọn.
Option [A] is recommended over [B] because it satisfies [requirement IDs] at [relative cost or effort], whereas [B] does not meet [requirement] and introduces [risk].
Ví dụ: Option A, an off the shelf booking platform, is recommended over a custom build because it satisfies R1 to R5 within six weeks, whereas the custom build does not meet the launch deadline and introduces maintenance risk for a clinic with no IT staff.
Mỗi sơ đồ trong report cần một câu dẫn giải thích phạm vi và điểm chính: "Figure 2 models the to-be booking process; the key change is that confirmation happens inside the system instead of by email." Sơ đồ không có câu dẫn thì người chấm phải tự đoán ý bạn. Tham khảo thêm cách trình bày report thiết kế giải pháp số ở hướng dẫn Digital Business Design report.
Trước và sau
Trước: The new system should be fast, user-friendly and secure so that everyone is happy.
Sau: Customers shall be able to complete a booking in no more than three screens (R2, usability), search results shall load within two seconds for 95% of requests (R3, performance), and only authorised staff shall view patient contact details (R6, security).
Bản "trước" không kiểm chứng được và không gắn với ai. Bản "sau" có mã, có số đo, có loại requirement, nên người chấm và cả người phát triển hệ thống đều biết khi nào nó đạt.
Lỗi hay gặp
- Nhảy thẳng tới giải pháp công nghệ mà không có problem statement và mô hình as-is.
- Vẽ sơ đồ đúng ký hiệu nhưng không có câu dẫn, không liên hệ với requirement nào.
- Liệt kê stakeholder thành danh sách tên mà không nêu nhu cầu và mức ảnh hưởng của họ.
- Requirement dùng từ cảm tính: fast, easy, modern.
- Bài nhóm mỗi phần một thuật ngữ, một kiểu sơ đồ.
- Dùng công cụ tạo sinh để sinh sơ đồ hoặc requirement mà không đọc quy định trong unit guide về mức được phép và cách ghi nhận.
Checklist
- Đã đọc case, template và rubric trên CloudDeakin, xác nhận loại sơ đồ được yêu cầu và tuần nộp.
- Có một problem statement tách nguyên nhân gốc khỏi triệu chứng.
- Có mô hình as-is trước mô hình to-be.
- Mỗi stakeholder có nhu cầu cụ thể; mâu thuẫn giữa họ được nêu và xử lý.
- Mọi requirement có mã, đo được, và truy về stakeholder cùng phần tử sơ đồ.
- Khuyến nghị so sánh ít nhất hai phương án theo cùng bộ tiêu chí.
- Mỗi sơ đồ có câu dẫn; trích dẫn theo kiểu unit yêu cầu, xem hướng dẫn APA 7 nếu unit dùng APA.
Chị khóa trên dặn một câu thôi: ở môn này, người hỏi đúng câu được điểm hơn người vẽ đẹp sơ đồ.
Đừng hỏi "mình nên vẽ sơ đồ gì". Hãy hỏi "stakeholder nào đang gặp vấn đề gì, và sơ đồ này chứng minh mình hiểu vấn đề đó ra sao".
Cần hỗ trợ assignment / luận văn? Nhắn Facebook của 7
Cần hỗ trợ 1-1 cho môn này? Xem bảng giá và quy trình nhận hỗ trợ của 7 Writing Service.