Nếu bạn đã học User Story, Use Case, SRS rồi nhưng khi bắt tay vào viết tài liệu vẫn bị rối, thì nguyên nhân thường không phải do bạn “chưa học đủ”.
Mà là bạn chưa có quy trình phân tích yêu cầu từ đầu đến cuối.
Nhiều bạn mới học BA hay bị kiểu:
Không biết nên vẽ flow trước hay viết user story trước
Không biết lúc nào viết Use Case
Không biết SRS gồm những gì
Không biết stakeholder nói xong thì mình phải làm bước nào tiếp theo
Thực tế, bạn không nên bắt đầu bằng việc “viết tài liệu”.
Bạn nên bắt đầu bằng việc hiểu yêu cầu trước, rồi mới chọn tài liệu phù hợp để mô tả lại.
Dưới đây là một quy trình đơn giản, dễ áp dụng cho newbie.
1. Bước đầu tiên: Hiểu bối cảnh và mục tiêu
Khi nhận một yêu cầu, đừng vội viết ngay.
Ví dụ stakeholder nói:
“Anh muốn thêm chức năng quên mật khẩu.”
BA mới thường ghi ngay:
Hệ thống cần có chức năng quên mật khẩu.
Nhưng BA nên hỏi trước:
Vì sao cần chức năng này?
Hiện tại user đang gặp vấn đề gì?
Ai là người dùng chính?
Mục tiêu là giảm ticket CS, tăng trải nghiệm, hay tăng bảo mật?
Tính năng này áp dụng cho web, mobile app hay cả hai?
Đây là bước xác định Business Need.
Nếu chưa hiểu “vì sao cần làm”, bạn rất dễ viết tài liệu đúng câu chữ nhưng sai mục tiêu.
2. Bước thứ hai: Xác định phạm vi
Sau khi hiểu mục tiêu, BA cần làm rõ:
Tính năng này làm đến đâu, không làm đến đâu?
Ví dụ với “Quên mật khẩu”, phạm vi có thể là:
Trong scope:
User nhập số điện thoại
Nhận OTP
Xác thực OTP
Tạo mật khẩu mới
Ngoài scope:
Reset bằng email
Reset qua tổng đài
Xác thực bằng eKYC
Bước này rất quan trọng vì nếu không chốt scope sớm, yêu cầu sẽ phình ra liên tục.
Newbie BA nên nhớ:
Scope rõ thì tài liệu phía sau mới rõ.
3. Bước thứ ba: Vẽ flow trước khi viết chữ
Đây là lời khuyên rất thực tế:
Trước khi viết Use Case, User Story hay SRS, hãy vẽ flow trước.
Flow giúp bạn nhìn được:
User bắt đầu từ đâu
Hệ thống xử lý gì
Có bao nhiêu bước
Chỗ nào có điều kiện rẽ nhánh
Chỗ nào có lỗi hoặc exception
Ví dụ flow “Quên mật khẩu”:
User chọn Quên mật khẩu
User nhập số điện thoại
Hệ thống kiểm tra số điện thoại
Hệ thống gửi OTP
User nhập OTP
Hệ thống xác thực OTP
User tạo mật khẩu mới
Hệ thống cập nhật mật khẩu
Khi đã có flow, bạn sẽ đỡ rối hơn rất nhiều.
Vì lúc đó bạn không còn viết theo cảm giác, mà viết theo luồng xử lý.
4. Bước thứ tư: Làm rõ Rule, Data, Exception
Sau khi có flow, BA phải bóc sâu từng bước theo 3 nhóm:
Rule – Quy định nghiệp vụ
Ví dụ:
OTP có hiệu lực bao lâu?
Nhập sai OTP bao nhiêu lần thì khóa?
Mật khẩu mới cần rule gì?
User bị khóa tài khoản có được reset không?
Data – Dữ liệu
Ví dụ:
User nhập số điện thoại hay username?
OTP lưu ở đâu?
Có lưu lịch sử reset mật khẩu không?
Có cần gửi notification sau khi đổi mật khẩu không?
Exception – Trường hợp lỗi
Ví dụ:
Số điện thoại không tồn tại
OTP hết hạn
OTP sai quá số lần
Hệ thống gửi OTP thất bại
User thoát giữa chừng
Đây là bước rất quan trọng.
Vì tài liệu BA không chỉ mô tả lúc mọi thứ chạy đúng, mà còn phải mô tả khi mọi thứ đi sai.
5. Bước thứ năm: Chọn loại tài liệu phù hợp
Sau khi đã hiểu flow, rule, data, exception, lúc này bạn mới chọn viết tài liệu.
Đừng hỏi ngay:
“Em nên viết User Story hay Use Case trước?”
Hãy hỏi:
“Yêu cầu này cần mô tả ở mức nào?”
Nếu dự án Agile, tính năng nhỏ, cần chia backlog:
Bạn có thể viết User Story.
Ví dụ:
As a user, I want to reset my password using OTP so that I can regain access to my account.
Sau đó viết Acceptance Criteria.
Nếu flow phức tạp, nhiều nhánh, nhiều rule:
Bạn nên viết Use Case.
Ví dụ:
Use Case: Reset Password via OTP
Gồm:
Actor
Pre-condition
Main Flow
Alternative Flow
Exception Flow
Post-condition
Business Rules
Nếu dự án cần tài liệu tổng thể, formal, làm outsource hoặc waterfall:
Bạn có thể gom vào SRS.
SRS thường gồm:
Scope
Functional Requirement
Non-functional Requirement
Use Case
Business Rules
Data Requirement
UI/UX reference
Acceptance Criteria
Tóm lại:
User Story, Use Case, SRS không phải thứ để chọn ngẫu nhiên.
Chúng là cách khác nhau để mô tả yêu cầu sau khi bạn đã phân tích đủ.
6. Bước thứ sáu: Viết Acceptance Criteria để chốt đúng/sai
Dù bạn viết User Story hay Use Case, cuối cùng vẫn cần có tiêu chí kiểm tra.
Ví dụ:
Given user nhập số điện thoại đã đăng ký
When user yêu cầu gửi OTP
Then hệ thống gửi OTP thành công trong 60 giây
Hoặc:
Given OTP đã hết hạn
When user nhập OTP đó
Then hệ thống từ chối và hiển thị thông báo “OTP đã hết hạn”
Acceptance Criteria giúp:
Dev hiểu khi nào code xong
QA biết test thế nào
Stakeholder biết hệ thống chạy đúng ra sao
Nếu requirement không có AC, rất dễ rơi vào tình trạng:
“Em tưởng là như vậy.”
7. Bước cuối: Review và xác nhận lại
Sau khi viết xong, BA không nên im lặng gửi tài liệu rồi chờ mọi người tự hiểu.
Bạn nên review với từng nhóm:
Với stakeholder:
Flow này có đúng nghiệp vụ không?
Rule này đã đúng chưa?
Có thiếu exception nào không?
Với Dev:
Có đủ thông tin để estimate chưa?
Có điểm nào chưa rõ về API, data, rule không?
Với QA:
AC đã đủ để viết test case chưa?
Exception flow đã đủ chưa?
Sau đó BA cần chốt lại bằng recap:
“Em xác nhận lại: tính năng này sẽ xử lý theo flow A, rule B, exception C. Các phần X/Y hiện chưa nằm trong scope.”
Đây là cách tránh hiểu nhầm trước khi Dev code.
Quy trình đơn giản để newbie nhớ
Khi nhận một yêu cầu, hãy đi theo thứ tự này:
Hiểu bối cảnh và mục tiêu
Xác định scope
Vẽ flow
Bóc rule, data, exception
Chọn tài liệu phù hợp: User Story / Use Case / SRS
Viết Acceptance Criteria
Review và xác nhận lại
Đừng bắt đầu bằng việc mở template SRS lên và điền.
Hãy bắt đầu bằng việc hiểu bài toán.
Ví dụ dễ nhớ
Stakeholder nói:
“Anh muốn làm chức năng quên mật khẩu.”
BA không nên ghi ngay:
Requirement: Hệ thống cho phép user quên mật khẩu.
BA nên xử lý như sau:
Mục tiêu: giúp user tự lấy lại quyền truy cập
Scope: reset qua OTP SMS
Flow: nhập số điện thoại → nhận OTP → tạo mật khẩu mới
Rule: OTP 60 giây, sai 5 lần thì khóa
Exception: OTP hết hạn, số điện thoại không tồn tại, gửi OTP lỗi
Tài liệu: Use Case + User Story + AC
Review: xác nhận với stakeholder, Dev, QA
Như vậy, từ một câu nói rất ngắn, BA đã biến nó thành requirement rõ ràng, có thể làm và có thể test.
Tóm lại
Newbie BA bị rối không phải vì User Story, Use Case hay SRS quá khó.
Bạn bị rối vì chưa có thứ tự phân tích.
Hãy nhớ:
Flow trước.
Rule sau.
Exception sau nữa.
Rồi mới viết tài liệu.
BA giỏi không phải người viết nhiều tài liệu nhất.
BA giỏi là người biết biến một yêu cầu mơ hồ thành một mô tả đủ rõ để:
Business xác nhận được
Dev làm được
QA test được
User dùng được
