Case nhỏ nhưng test rất rõ tư duy phân tích hệ thống của BA
“Quên mật khẩu” nghe có vẻ là một chức năng rất nhỏ.
User bấm Forgot Password → nhập email → nhận OTP/link → đặt lại mật khẩu mới.
Nhìn qua thì đơn giản.
Nhưng nếu phân tích kỹ, đây là một case cực hay để test tư duy BA, vì nó chạm vào nhiều phần quan trọng:
Actor
Pre-condition
Post-condition
Main Flow
Exception Flow
Business Rule
NFR về bảo mật, timeout, audit log
Nói cách khác:
“Quên mật khẩu” không chỉ là một màn hình.
Nó là một flow xác thực danh tính người dùng.
1️⃣ Actor – Ai tham gia use case này?
Actor chính:
User: người quên mật khẩu và muốn lấy lại quyền truy cập tài khoản
Actor phụ / hệ thống liên quan:
Authentication System: xác thực user
OTP Service / Email Service / SMS Gateway: gửi OTP hoặc reset link
Audit Log System: ghi nhận hành vi bảo mật
BA cần làm rõ từ đầu:
User reset bằng email hay số điện thoại?
Có hỗ trợ cả OTP và reset link không?
OTP gửi qua SMS, email hay app notification?
Nếu không rõ actor và hệ thống liên quan, flow rất dễ bị thiếu.
2️⃣ Pre-condition – Điều kiện trước khi bắt đầu
Một use case tốt không bắt đầu bằng “user bấm nút”.
Nó cần có điều kiện trước đó.
Ví dụ pre-condition:
User đã có tài khoản trong hệ thống.
Tài khoản chưa bị khóa vĩnh viễn.
Email hoặc số điện thoại đã được verify trước đó.
User đang ở màn hình đăng nhập.
Dịch vụ gửi OTP/email đang khả dụng.
Nếu thiếu pre-condition, Dev và QA sẽ hỏi:
“Nếu tài khoản chưa verify email thì có reset được không?”
“Nếu account bị khóa thì xử lý thế nào?”
3️⃣ Main Flow – Luồng chính
Một main flow cơ bản có thể viết như sau:
User chọn Forgot Password trên màn hình đăng nhập.
System hiển thị form nhập email hoặc số điện thoại.
User nhập email/số điện thoại đã đăng ký.
System kiểm tra thông tin có tồn tại trong hệ thống.
System gửi OTP hoặc reset link cho user.
User nhập OTP hoặc mở reset link.
System xác thực OTP/link còn hiệu lực.
User nhập mật khẩu mới.
System kiểm tra password theo rule.
System cập nhật mật khẩu mới.
System hiển thị thông báo reset password thành công.
User có thể đăng nhập bằng mật khẩu mới.
Flow này nhìn đơn giản, nhưng BA cần viết đủ để team hiểu:
Verify user ở bước nào?
OTP/link có được dùng một lần không?
Sau khi đổi mật khẩu có auto login không hay quay về màn login?
4️⃣ Post-condition – Sau khi use case kết thúc thì hệ thống ở trạng thái nào?
Post-condition giúp định nghĩa “xong” là xong đến đâu.
Ví dụ:
Trường hợp thành công
Mật khẩu mới được lưu thành công.
OTP/reset link bị vô hiệu hóa sau khi dùng.
User có thể đăng nhập bằng mật khẩu mới.
System ghi audit log cho hành động reset password.
Các session cũ có thể bị logout tùy policy bảo mật.
Trường hợp thất bại
Mật khẩu không bị thay đổi.
OTP/link không hợp lệ hoặc hết hạn.
Hệ thống ghi nhận số lần thử sai.
User nhận thông báo phù hợp.
Nếu không có post-condition, QA sẽ rất khó biết use case kết thúc đúng hay chưa.
5️⃣ Exception Flow – Nơi BA thể hiện tư duy thật
Happy flow thì ai cũng viết được.
Nhưng “Forgot Password” dễ bug ở exception.
Một số exception bắt buộc phải nghĩ tới:
Exception 1: Email/số điện thoại không tồn tại
User nhập email không có trong hệ thống.
System hiển thị thông báo phù hợp.
Lưu ý bảo mật:
Không nên trả message quá rõ kiểu:
“Email này chưa được đăng ký.”
Vì có thể bị lợi dụng để dò tài khoản.
Có thể dùng message trung tính:
“Nếu thông tin tồn tại trong hệ thống, hướng dẫn đặt lại mật khẩu sẽ được gửi.”
Exception 2: OTP sai
User nhập OTP không đúng.
System hiển thị lỗi.
Số lần nhập sai tăng lên.
BA cần làm rõ:
Sai mấy lần thì khóa?
Khóa flow reset hay khóa tài khoản?
Sau bao lâu được thử lại?
Exception 3: OTP hết hạn
User nhập OTP sau thời gian hiệu lực.
System từ chối xác thực.
User được phép yêu cầu gửi lại OTP.
Cần ghi rõ:
OTP hết hạn sau bao lâu?
Resend OTP có tạo OTP mới và vô hiệu OTP cũ không?
Exception 4: Nhập sai quá số lần
Ví dụ:
User nhập sai OTP 5 lần.
System tạm khóa chức năng reset password trong 15 phút.
System ghi audit log.
User nhận message rõ ràng.
Đây là điểm liên quan mạnh đến security.
Exception 5: Mật khẩu mới không hợp lệ
Ví dụ:
Quá ngắn
Không có ký tự đặc biệt
Trùng mật khẩu cũ
Nằm trong danh sách mật khẩu yếu
System phải hiển thị rule rõ để user sửa.
6️⃣ Business Rule – Luật nghiệp vụ cần tách riêng
Đừng chôn rule vào flow.
Hãy tách thành một mục riêng.
Ví dụ:
BR-01: OTP có hiệu lực trong 5 phút kể từ thời điểm phát sinh.
BR-02: Mỗi OTP chỉ được sử dụng một lần.
BR-03: Resend OTP chỉ được phép sau 60 giây.
BR-04: User được nhập sai OTP tối đa 5 lần.
BR-05: Sau 5 lần sai OTP, chức năng reset password bị khóa trong 15 phút.
BR-06: Mật khẩu mới phải có tối thiểu 8 ký tự, gồm chữ hoa, chữ thường, số và ký tự đặc biệt.
BR-07: Mật khẩu mới không được trùng với 3 mật khẩu gần nhất.
BR-08: Reset link chỉ có hiệu lực một lần và hết hạn sau X phút.
Business Rule càng rõ, Dev càng ít phải đoán, QA càng dễ viết test case.
7️⃣ NFR – Phần Fresher rất hay quên
Forgot Password không chỉ cần “chạy được”.
Nó còn phải an toàn, ổn định và có log.
Security
OTP/reset link không được lưu plain text.
Không expose thông tin user tồn tại hay không tồn tại.
Password phải được hash trước khi lưu.
Reset token phải random, khó đoán, có expiry.
Timeout
OTP/link phải có thời gian hết hạn.
Session reset password có timeout nếu user không thao tác.
Availability
Nếu SMS Gateway hoặc Email Service lỗi, hệ thống phải có message phù hợp.
Có retry hoặc fallback tùy thiết kế.
Audit Log
System cần log:
Thời điểm user yêu cầu reset
Kênh reset: email/SMS
Số lần nhập OTP sai
Thời điểm reset thành công/thất bại
IP/device nếu có yêu cầu bảo mật
Audit log rất quan trọng khi có nghi ngờ tài khoản bị tấn công.
8️⃣ Mẫu Use Case ngắn gọn
Use Case: Reset Password
Actor: User
Pre-condition:
User có tài khoản hợp lệ trong hệ thống.
Email/số điện thoại đã được xác thực.
User đang ở màn hình đăng nhập.
Main Flow:
User chọn Forgot Password.
User nhập email/số điện thoại.
System kiểm tra thông tin.
System gửi OTP/reset link.
User nhập OTP hoặc mở reset link.
System xác thực OTP/link.
User nhập mật khẩu mới.
System validate password rule.
System cập nhật mật khẩu.
System thông báo thành công.
Post-condition:
Password được cập nhật.
OTP/reset link bị vô hiệu hóa.
Audit log được ghi nhận.
Exception Flow:
Email/số điện thoại không tồn tại.
OTP sai.
OTP hết hạn.
Nhập sai OTP quá số lần.
Password không đạt rule.
Email/SMS service lỗi.
Business Rules:
OTP hết hạn sau 5 phút.
Resend OTP sau 60 giây.
Sai OTP quá 5 lần thì khóa reset trong 15 phút.
Password phải đạt rule bảo mật.
Reset token chỉ dùng một lần.
NFR:
Không expose thông tin tài khoản tồn tại hay không.
Password phải được hash.
Reset action phải có audit log.
OTP service có timeout và error handling rõ ràng.
Kết cục:
Use Case “Quên mật khẩu” nhỏ, nhưng không hề đơn giản.
Nó test BA ở rất nhiều góc:
Có biết xác định actor không?
Có biết viết pre-condition/post-condition không?
Có nghĩ tới exception không?
Có tách Business Rule khỏi Flow không?
Có nhớ NFR về security, timeout, audit log không?
Một BA mới có thể viết:
“User nhập email và đặt lại mật khẩu.”
Nhưng một BA tốt sẽ phân tích được:
“Flow này là một cơ chế xác thực danh tính, có rule, exception, security và audit rõ ràng.”
Case nhỏ, nhưng bài học rất lớn.
Học đầy đủ kiến thức để trở thành ITBA cho người mới bắt đầu -> Hướng dẫn áp dụng thực hành dự án để ghi vào CV (Quà tặng hơn 30 khóa ở đây):
=> https://www.facebook.com/groups/3514587515337829/posts/3618897148240198/
Đã có kiến thức BA cơ bản thì học các Khóa học chuyên sâu về các domain cùng case study thực tế: Bảo hiểm - ERP - Banking - E-commerce - Chính Phủ (GOV) - Logistis, tìm hiểu tại đây:
https://www.facebook.com/groups/3514587515337829/posts/3714548542008391
