Kỹ thuật thu thập yêu cầu là nền tảng cho mọi dự án phần mềm thành công. Trong số các kỹ thuật sẵn có, mô tả Trường hợp Sử dụng vẫn là một trong những phương pháp hiệu quả nhất để thu thập các yêu cầu chức năng từ góc nhìn người dùng. Một mô tả Trường hợp Sử dụng được viết tốt sẽ nối liền khoảng cách giữa nhu cầu kinh doanh và triển khai kỹ thuật, đảm bảo tất cả các bên liên quan đều có cùng một hiểu biết thống nhất về hành vi của hệ thống.
Tuy nhiên, sự mơ hồ trong các mô tả này thường dẫn đến lỗi phát triển, mở rộng phạm vi không kiểm soát được và thất bại trong kiểm thử. Hướng dẫn này cung cấp một cách tiếp cận có cấu trúc để xây dựng các mô tả Trường hợp Sử dụng chính xác và có thể hành động, sử dụng các tiêu chuẩn Modeling Ngôn ngữ Tổng hợp (UML). Bằng cách tuân theo các mẫu đã được thiết lập, các đội ngũ có thể tạo ra tài liệu vừa đóng vai trò là bản vẽ thiết kế, vừa là danh sách kiểm tra xác minh.
🔍 Hiểu rõ Các Thành phần Chính
Trước khi viết văn bản mô tả, điều quan trọng là phải xác định các thành phần cấu trúc tạo nên một Trường hợp Sử dụng hoàn chỉnh. Những thành phần này đảm bảo tình huống được giới hạn và có thể đo lường được.
1. Người Thực hiện 🧍
Một người thực hiện đại diện cho một vai trò do một thực thể thực hiện khi tương tác với hệ thống. Người thực hiện nằm ngoài ranh giới hệ thống. Họ có thể là:
- Người thực hiện con người:Những con người thực sự, chẳng hạn như khách hàng, quản trị viên hoặc kỹ thuật viên.
- Hệ thống bên ngoài:Các giao diện phần mềm hoặc phần cứng khác, kích hoạt hoặc nhận dữ liệu.
- Người thực hiện dựa trên thời gian:Các sự kiện được kích hoạt bởi đồng hồ hoặc bộ đếm thời gian, chẳng hạn như quy trình sao lưu theo lịch trình.
Khi xác định người thực hiện, hãy gán một vai trò cụ thể thay vì một chức danh cụ thể. Ví dụ, hãy dùng “Người dùng đã đăng ký” thay vì “John Doe”. Điều này đảm bảo yêu cầu vẫn hợp lệ ngay cả khi nhân sự thay đổi.
2. Ranh giới Hệ thống ⬜
Ranh giới hệ thống xác định phần nào nằm trong phần mềm và phần nào nằm ngoài. Nó làm rõ trách nhiệm. Tất cả những gì nằm trong khung là hệ thống; tất cả những gì nằm ngoài là môi trường. Sự phân biệt này rất quan trọng để xác định ai chịu trách nhiệm cho một lỗi hoặc hành động cụ thể.
3. Mục tiêu 🎯
Mỗi Trường hợp Sử dụng đại diện cho một mục tiêu duy nhất mà người thực hiện mong muốn đạt được. Nếu một mô tả chứa nhiều mục tiêu không liên quan, nó nên được chia thành các Trường hợp Sử dụng riêng biệt. Một mục tiêu duy nhất đảm bảo Trường hợp Sử dụng vẫn có thể kiểm thử và quản lý được.
📋 Giải phẫu của Một Mô tả Trường hợp Sử dụng
Một mô tả toàn diện vượt xa sơ đồ đơn giản. Nó yêu cầu một bản mô tả văn bản chi tiết về luồng tương tác. Dưới đây là cấu trúc chuẩn được sử dụng trong tài liệu yêu cầu chuyên nghiệp.
Dữ liệu mô tả và Nhận diện
- ID Trường hợp Sử dụng:Một định danh duy nhất (ví dụ: UC-001) để theo dõi.
- Tên Trường hợp Sử dụng:Một cụm từ động từ-danh từ mô tả hành động (ví dụ: “Gửi đơn hàng”).
- Người thực hiện Chính:Người dùng chính khởi xướng hành động.
- Người thực hiện Phụ:Bất kỳ hệ thống hoặc người dùng hỗ trợ nào.
- Ưu tiên: Quan trọng, Cao, Trung bình hoặc Thấp.
Điều kiện tiên quyết
Điều kiện tiên quyết xác định trạng thái của hệ thống trước khi kịch bản sử dụng bắt đầu. Nếu các điều kiện này không được đáp ứng, kịch bản sử dụng không thể khởi động. Điều này giúp người kiểm thử hiểu được cấu hình cần thiết.
- Người dùng phải đăng nhập vào hệ thống.
- Giỏ hàng phải chứa ít nhất một mặt hàng.
- Cổng thanh toán phải hoạt động.
Điều kiện hậu tố
Điều kiện hậu tố mô tả trạng thái của hệ thống sau khi kịch bản sử dụng hoàn thành thành công. Chúng đóng vai trò là tiêu chí chấp nhận cho tính năng.
- Một bản ghi đơn hàng mới được tạo trong cơ sở dữ liệu.
- Một email xác nhận được gửi đến người dùng.
- Mức tồn kho được cập nhật.
Luồng sự kiện
Đây là phần cốt lõi của mô tả. Nó nêu rõ trình tự các bước thực hiện bởi người dùng và hệ thống. Thường được chia thành Trường hợp thành công chính và Các phần mở rộng.
🚀 Trường hợp thành công chính (Đường đi hạnh phúc)
Trường hợp thành công chính mô tả con đường lý tưởng nơi mọi thứ diễn ra suôn sẻ. Không có lỗi, gián đoạn hay quyết định thay thế. Mỗi bước phải là nguyên tử, nghĩa là một hành động duy nhất không thể chia nhỏ hơn mà không làm mất ý nghĩa.
Khi viết các bước này, hãy tuân theo các hướng dẫn sau:
- Đánh số các bước:Sử dụng 1, 2, 3… để chỉ thứ tự.
- Xác định nguồn gốc:Rõ ràng nêu ai khởi tạo bước (Người dùng hoặc Hệ thống).
- Sử dụng động từ hoạt động:Bắt đầu bằng các động từ hành động như “Chọn,” “Nhập,” “Hiển thị,” hoặc “Xác thực.”
- Tránh dùng thuật ngữ kỹ thuật:Mô tả những gì người dùng thấy, chứ không phải truy vấn cơ sở dữ liệu đằng sau nó.
🛑 Luồng thay thế và luồng ngoại lệ
Việc sử dụng thực tế hiếm khi tuân theo con đường hoàn hảo. Các phần mở rộng xử lý những lệch khỏi luồng chính. Đây là yếu tố then chốt cho việc thu thập yêu cầu vững chắc.
Luồng thay thế
Chúng xảy ra khi người dùng đưa ra lựa chọn khác so với đường đi chính. Chúng vẫn dẫn đến cùng một mục tiêu, nhưng theo một con đường khác.
- Ví dụ:Người dùng chọn áp dụng mã giảm giá trong quá trình thanh toán.
Dòng ngoại lệ
Chúng xảy ra khi có điều gì đó không đúng. Hệ thống phải xử lý lỗi một cách trơn tru. Mục tiêu của trường hợp sử dụng có thể thất bại, hoặc có thể được khôi phục.
- Ví dụ: Cổng thanh toán trả về một thông báo lỗi.
- Ví dụ: Người dùng không đủ số dư.
Các phần mở rộng nên tham chiếu đến số bước cụ thể trong Tình huống Thành công Chính nơi xảy ra sự lệch chuẩn.
📝 Ví dụ thực tế: “Xử lý thanh toán”
Để minh họa các khái niệm này, hãy xem xét một tình huống xử lý thanh toán mang tính tổng quát. Ví dụ này minh họa cách chuyển đổi các ý tưởng trừu tượng thành các bước cụ thể.
| Bước | Người thực hiện/Hệ thống | Hành động | Phản hồi |
|---|---|---|---|
| 1 | Người thực hiện | Chọn nút “Thanh toán ngay”. | – |
| 2 | Hệ thống | Hiển thị biểu mẫu thanh toán. | Biểu mẫu xuất hiện với các trường thẻ. |
| 3 | Người thực hiện | Nhập chi tiết thẻ. | – |
| 4 | Hệ thống | Xác minh dữ liệu thẻ. | Kiểm tra định dạng và ngày hết hạn. |
| 5 | Hệ thống | Gửi giao dịch đến cổng thanh toán. | – |
| 6 | Cổng thanh toán | Trả về xác nhận ủy quyền. | Mã thành công hoặc mã lỗi. |
| 7 | Hệ thống | Xác nhận thanh toán. | Hiển thị màn hình thành công. |
Luồng thay thế A (Thẻ không hợp lệ):
- Tại Bước 4, nếu xác thực thất bại, hiển thị thông báo lỗi.
- Cho phép người dùng nhập lại dữ liệu.
Luồng thay thế B (Hết thời gian chờ):
- Tại Bước 5, nếu cổng thanh toán không phản hồi trong vòng 10 giây, hiển thị thông báo hết thời gian chờ.
- Cho phép người dùng thử lại hoặc hủy bỏ.
🛠 Các Thực Tiễn Tốt Nhất Để Đảm Bảo Rõ Ràng và Chính Xác
Viết yêu cầu là một kỹ năng được cải thiện qua thực hành. Tuân thủ các tiêu chuẩn cụ thể giúp giảm thiểu hiểu nhầm giữa các nhà phân tích kinh doanh, nhà phát triển và người kiểm thử.
1. Duy trì độ chi tiết
Không kết hợp nhiều hành động vào một bước. Nếu một bước yêu cầu người dùng nhấp vào nút rồi nhập văn bản, hãy chia thành hai bước. Độ chi tiết đảm bảo rằng các trường hợp kiểm thử có thể được viết cho từng tương tác cụ thể.
2. Tránh đưa ra giả định
Không bao giờ giả định người dùng biết các thuật ngữ kỹ thuật. Tránh dùng các từ như “parse”, “commit” hoặc “cache” trừ khi giao diện hiển thị rõ ràng chúng. Mô tả kết quả, chứ không phải cơ chế hoạt động.
3. Tính nhất quán trong thuật ngữ
Sử dụng từ vựng được kiểm soát. Nếu bạn gọi nó là “Sản phẩm” ở một phần, đừng gọi nó là “Mặt hàng” ở phần khác. Sự không nhất quán sẽ gây nhầm lẫn cho nhà phát triển và dẫn đến lỗi ánh xạ cơ sở dữ liệu.
4. Tập trung vào hành vi, không phải triển khai
Mô tả hệ thống làm gì, chứ không phải cách nó làm. Ví dụ, viết “Hệ thống kiểm tra tồn kho” thay vì “Hệ thống truy vấn bảng tồn kho SQL”. Cách đầu tiên cho phép đội triển khai lựa chọn công nghệ tốt nhất.
⚠️ Những Sai Lầm Thường Gặp Cần Tránh
Ngay cả những người viết có kinh nghiệm cũng mắc sai lầm. Nhận diện những mẫu sai lầm này sớm sẽ giúp tránh công việc phải làm lại trong giai đoạn phát triển sau này.
Sai lầm 1: “Trường hợp sử dụng Thần”
Điều này xảy ra khi một trường hợp sử dụng duy nhất cố gắng làm quá nhiều việc. Nếu một trường hợp sử dụng có 50 bước, thì có khả năng nó đang bao quát nhiều mục tiêu khác nhau. Hãy chia nhỏ nó thành các trường hợp sử dụng nhỏ hơn, tập trung vào một mục tiêu cụ thể.
Tầm nguy 2: Thiếu điều kiện tiên quyết
Bỏ qua điều kiện tiên quyết khiến người kiểm thử phải đoán mò về trạng thái ban đầu. Điều này thường dẫn đến các bài kiểm thử không ổn định, thất bại một cách ngẫu nhiên do môi trường không được thiết lập đúng cách.
Tầm nguy 3: Động từ mơ hồ
Tránh dùng những từ như “quản lý”, “xử lý” hoặc “xử lý”. Những từ này quá chung chung. Thay vào đó, hãy dùng “Cập nhật”, “Xóa”, “Tính toán” hoặc “Gửi”. Độ chính xác sẽ loại bỏ sự mơ hồ.
Tầm nguy 4: Trộn lẫn các mức độ chi tiết
Không trộn lẫn các mục tiêu kinh doanh cấp cao với các thao tác giao diện người dùng cấp thấp. Giữ cho Diễn biến Thành công Chính ở mức độ logic. Chi tiết giao diện người dùng có thể được ghi chép riêng biệt trong các bản phác thảo hoặc tài liệu mô tả giao diện người dùng.
🔗 Tích hợp với các tài liệu mô tả khác
Các trường hợp sử dụng không tồn tại một cách cô lập. Chúng kết nối với các tài liệu khác trong tài liệu yêu cầu.
- Khả năng truy xuất nguồn gốc: Mỗi trường hợp sử dụng nên được liên kết với các câu chuyện người dùng cụ thể hoặc mục tiêu kinh doanh. Điều này đảm bảo mọi tính năng đều phục vụ một mục đích nhất định.
- Các trường hợp kiểm thử: Các bước trong Diễn biến Thành công Chính trực tiếp chuyển thành các trường hợp kiểm thử tích cực. Các phần mở rộng chuyển thành các trường hợp kiểm thử tiêu cực.
- Thiết kế giao diện người dùng: Các tác nhân và các bước sẽ định hướng cấu trúc điều hướng và bố cục màn hình.
- Thiết kế cơ sở dữ liệu: Dữ liệu được nhắc đến trong các bước (ví dụ: “Nhập số thẻ tín dụng”) sẽ định hướng các yêu cầu mô hình dữ liệu.
📊 So sánh: Mô tả hiệu quả so với mô tả kém hiệu quả
Sự khác biệt giữa một yêu cầu tốt và một yêu cầu kém thường nằm ở mức độ chi tiết và độ rõ ràng. Bảng dưới đây nêu bật những khác biệt này.
| Tính năng | ❌ Mô tả kém hiệu quả | ✅ Mô tả hiệu quả |
|---|---|---|
| Tác nhân | “Người dùng” | “Quản trị viên đã đăng ký” |
| Bước | “Xử lý đăng nhập” | “Nhập tên người dùng và mật khẩu” |
| Kết quả | “Hệ thống kiểm tra quyền truy cập” | “Hệ thống xác minh thông tin đăng nhập với cơ sở dữ liệu” |
| Loại trừ | “Nếu thất bại” | “Nếu thông tin đăng nhập sai, hiển thị thông báo lỗi và làm trống trường” |
| Phạm vi | “Quản lý mọi thứ” | “Xem và chỉnh sửa hồ sơ người dùng” |
Lưu ý cách mô tả hiệu quả cung cấp các hành động cụ thể và ranh giới rõ ràng. Điều này giảm tải nhận thức cho nhà phát triển khi triển khai tính năng.
🧩 Xử lý các tình huống phức tạp
Không phải yêu cầu nào cũng phù hợp với luồng tuyến tính đơn giản. Một số tình huống bao gồm các quy trình song song hoặc logic điều kiện.
Mối quan hệ bao gồm và mở rộng
Trong UML, các trường hợp sử dụng có thể liên quan đến nhau. MộtBao gồmmối quan hệ xảy ra khi một trường hợp sử dụng luôn yêu cầu một trường hợp khác để hoạt động. Ví dụ, “Đặt hàng” luôn bao gồm “Xác minh thanh toán”. Điều này giảm sự trùng lặp trong mô tả.
MộtMở rộngmối quan hệ cho phép một trường hợp sử dụng thêm hành vi vào trường hợp khác trong điều kiện cụ thể. Ví dụ, “Áp dụng giảm giá” mở rộng “Đặt hàng” chỉ khi người dùng có mã giảm giá.
Các quy trình đồng thời
Đối với các hệ thống phức tạp, một luồng duy nhất có thể không đủ. Sử dụng các luồng con hoặc sơ đồ riêng để biểu diễn các hoạt động song song. Đảm bảo các điểm tương tác giữa các luồng này được xác định rõ ràng.
🔍 Xem xét và xác nhận
Một khi mô tả được viết xong, nó phải được xác nhận. Một tài liệu không được coi là hoàn chỉnh cho đến khi đã được xem xét bởi các bên liên quan.
- Điểm qua:Thực hiện điểm qua với chủ sở hữu doanh nghiệp. Yêu cầu họ đọc các bước và xác nhận chúng phù hợp với mô hình tư duy của họ.
- Kiểm tra khả thi:Tham khảo ý kiến nhà phát triển chính. Đảm bảo các bước có thể thực hiện được về mặt kỹ thuật trong khuôn khổ dự án.
- Đầy đủ:Kiểm tra các đường dẫn lỗi bị thiếu. Điều gì xảy ra nếu kết nối internet bị ngắt? Điều gì xảy ra nếu cơ sở dữ liệu đầy?
- Tính nhất quán:Đảm bảo các thuật ngữ nhất quán trên toàn bộ tài liệu yêu cầu.
🛠 Công cụ và định dạng
Định dạng của mô tả trường hợp sử dụng có thể thay đổi tùy theo nhu cầu dự án. Các định dạng phổ biến bao gồm:
- Văn bản có cấu trúc: Định dạng danh sách có đánh số phù hợp với Word hoặc Google Docs.
- Định dạng bảng: Bố cục bảng để quét nhanh, thường được sử dụng trong bảng tính.
- Dữ liệu lưu trong cơ sở dữ liệu: Được lưu trong các công cụ quản lý yêu cầu để đảm bảo khả năng truy xuất nguồn gốc.
- Trang Wiki: Các trang hợp tác cho phép lưu lịch sử phiên bản và liên kết.
Dù là phương tiện nào, cấu trúc nội dung vẫn giữ nguyên. Mục tiêu là tính dễ tiếp cận và rõ ràng, chứ không phải định dạng tệp cụ thể.
🔗 Từ yêu cầu đến kiểm thử
Giá trị tối thượng của mô tả trường hợp sử dụng nằm ở tính hữu dụng trong giai đoạn kiểm thử. Người kiểm thử sử dụng Diễn biến Thành công Chính để xác định các bài kiểm thử “Đường đi Hạnh phúc”. Họ sử dụng Mở rộng để xác định các bài kiểm thử “Đường đi Tiêu cực”.
Nếu mô tả trường hợp sử dụng mơ hồ, các bài kiểm thử sẽ không đầy đủ. Điều này dẫn đến khoảng trống trong phạm vi kiểm thử và các lỗi lọt vào môi trường sản xuất. Những mô tả rõ ràng đóng vai trò như một hợp đồng giữa bộ phận kinh doanh và đội ngũ kỹ thuật.
📈 Đo lường chất lượng
Làm sao bạn biết các trường hợp sử dụng của mình có chất lượng tốt? Hãy tìm những dấu hiệu sau:
- Khả năng kiểm thử:Người kiểm thử có thể viết một bài kiểm thử chỉ từ văn bản này không?
- Không mơ hồ:Liệu có chỉ một cách diễn giải duy nhất không?
- Khả năng truy xuất nguồn gốc:Bạn có thể liên kết điều này trở lại mục tiêu kinh doanh không?
- Tính đầy đủ:Tất cả các đường đi chính và ngoại lệ có được bao phủ không?
🏁 Tóm tắt những điểm chính cần ghi nhớ
Việc tạo ra các mô tả trường hợp sử dụng hiệu quả đòi hỏi sự kỷ luật và chú ý đến chi tiết. Điều này không chỉ đơn thuần là ghi chép những gì hệ thống làm, mà còn là xác định ranh giới hành vi của nó. Bằng cách tập trung vào các bước nguyên tử, điều kiện tiên quyết rõ ràng và xử lý ngoại lệ vững chắc, các đội nhóm có thể giảm thiểu sự mơ hồ và nâng cao chất lượng giao hàng.
Những yếu tố chính cần ghi nhớ bao gồm:
- Xác định rõ ràng các tác nhân và ranh giới hệ thống.
- Sử dụng định dạng có cấu trúc với ID, Tên và Luồng.
- Tách biệt Diễn biến Thành công Chính khỏi các luồng Thay thế và Ngoại lệ.
- Sử dụng động từ chủ động và thuật ngữ cụ thể.
- Xác nhận các mô tả với các bên liên quan trước khi bắt đầu phát triển.
Đầu tư thời gian để viết các yêu cầu rõ ràng sẽ mang lại lợi ích trong suốt vòng đời dự án. Điều này giảm thiểu công việc phải làm lại, làm rõ kỳ vọng và đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu thực tế của người dùng.
