Bước đầu tiên trong việc xác định một sản phẩm, dịch vụ, quy trình hoặc hệ thống mới là xác định các yêu cầu, tức là các yêu cầu chức năng hoặc phi chức năng cụ thể.
- Yêu cầu chức năng mô tả cách sản phẩm hoặc dịch vụ đáp ứng nhu cầu của khách hàng. Điều này bao gồm các tính năng và chức năng trong các trường hợp sử dụng ghi lại cách người dùng sẽ tương tác với sản phẩm hoặc dịch vụ.
- Yêu cầu phi chức năng là các thuộc tính hoạt động và sản phẩm mà đôi khi không rõ ràng với người dùng, bao gồm hiệu suất, khả năng sử dụng, độ bền, bảo mật và tài chính (giá cả và chi phí).
Chỉnh sửa minh họa này – yêu cầu chức năng so với yêu cầu phi chức năng
Yêu cầu chức năng có thể được coi là những gì sản phẩm cần làm cho khách hàng, trong khi yêu cầu phi chức năng có thể được coi là các ràng buộc mà sản phẩm hoặc dịch vụ cần được thiết kế để đáp ứng.
Yêu cầu chức năng nắm bắt hành vi dự kiến của hệ thống. Hành vi này có thể được diễn đạt dưới dạng dịch vụ, nhiệm vụ hoặc chức năng mà hệ thống cần thực hiện. Trong ngành phát triển phần mềm, phương pháp trường hợp sử dụng đã nhanh chóng trở thành một thực tiễn phổ biến để nắm bắt yêu cầu chức năng. Điều này đặc biệt đúng trong cộng đồng lập trình hướng đối tượng và UML nơi chúng xuất phát, nhưng tính ứng dụng của chúng không chỉ giới hạn ở các hệ thống hướng đối tượng.
Các kỹ thuật nào để nắm bắt yêu cầu chức năng?
Yêu cầu chức năng thường được nắm bắt dưới dạng các trường hợp sử dụng hoặc kịch bản người dùng. Những thuật ngữ này đôi khi được sử dụng thay thế cho nhau, nhưng thực tế chúng có nghĩa hơi khác nhau.
- Các trường hợp sử dụng tập trung nhiều hơn vào hệ thống và những gì nó phải làm để đáp ứng nhu cầu của người dùng.
- Câu chuyện người dùng, ngược lại, cho thấy chức năng sản phẩm từ góc độ của người dùng, xác định vai trò người dùng và các mục tiêu cụ thể mà họ muốn đạt được.
Nắm bắt yêu cầu chức năng bằng cách sử dụng câu chuyện người dùng
Câu chuyện người dùng là một phương pháp nhẹ nhàng để nhanh chóng nắm bắt “ai”, “cái gì” và “tại sao” của các yêu cầu sản phẩm. Nói một cách đơn giản, câu chuyện người dùng là những ý tưởng thể hiện nhu cầu mà người dùng muốn. Câu chuyện người dùng ngắn gọn, và mỗi phần thường chứa ít hơn 10 hoặc 15 từ. Câu chuyện người dùng là danh sách “cần làm” giúp bạn xác định các bước dọc theo con đường dự án. Chúng giúp đảm bảo rằng quy trình của bạn, và sản phẩm cuối cùng, đáp ứng yêu cầu của bạn.
Mẫu câu chuyện người dùng
Câu chuyện người dùng chỉ nắm bắt các yếu tố thiết yếu của một yêu cầu:
- Ai là người sử dụng?
- Nó mong đợi điều gì từ hệ thống?
- Tại sao nó quan trọng (tùy chọn?)?
Dưới đây là một định dạng đơn giản của câu chuyện người dùng được 70% người thực hành sử dụng:
Vai trò – Người dùng nên là một con người thực sự tương tác với hệ thống.
- Càng cụ thể càng tốt
- Nhóm phát triển KHÔNG phải là người dùng
Hành động – Hành vi của hệ thống nên được viết dưới dạng một hành động.
- Thường thì độc nhất cho mỗi Câu chuyện người dùng
- “Hệ thống” được ngụ ý và không được viết trong câu chuyện
- Giọng chủ động, không phải giọng bị động (“Tôi có thể được thông báo”)
Lợi ích – Lợi ích nên là một kết quả thực tế không phải chức năng hoặc bên ngoài hệ thống.
- Nhiều câu chuyện có thể chia sẻ cùng một tuyên bố lợi ích.
- Lợi ích có thể dành cho những người dùng hoặc khách hàng khác, không chỉ dành cho người dùng trong câu chuyện.
Làm thế nào để xác định yêu cầu chức năng với trường hợp sử dụng?
Để hiểu đầy đủ các yêu cầu chức năng của hệ thống, bạn phải biết hệ thống dành cho ai, tức là Ai sẽ sử dụng hệ thống?
Câu trả lời cho câu hỏi này là: nhân vật trong phân tích trường hợp sử dụng
Các trường hợp sử dụng hoặc câu chuyện người dùng nắm bắt yêu cầu chức năng mà hành vi có thể được diễn đạt dưới dạng dịch vụ, nhiệm vụ hoặc chức năng mà hệ thống cần thực hiện. Các trường hợp sử dụng xác định sự tương tác giữa người dùng và dịch vụ hệ thống, điều này có thể giúp xác định các yêu cầu chức năng của hệ thống đang được phát triển. Hay nói cách khác, sản phẩm hoặc dịch vụ cần làm gì để đáp ứng nhu cầu và mong muốn của khách hàng.
Một trường hợp sử dụng bắt đầu với một “nhân vật” hoặc “ai”, một người dùng cụ thể của sản phẩm hoặc dịch vụ.
Một nhân vật là một người hoặc một hệ thống bên ngoài đóng vai trò trong việc tương tác với hệ thống. Các trường hợp của nhân vật có thể là cá nhân hoặc hệ thống bên ngoài; tuy nhiên, mỗi nhân vật cung cấp một góc nhìn độc đáo và quan trọng về hệ thống, một góc nhìn mà là chung cho mỗi trường hợp (người thực / người dùng) của nhân vật.
Người dùng thực vs Nhân vật trường hợp sử dụng
Để hiểu đầy đủ mục đích của hệ thống, bạn phải biết hệ thống dành cho ai, tức là ai sẽ sử dụng nó. Các loại người dùng khác nhau được đại diện dưới dạng Nhân vật (vai trò).
Sự khác biệt giữa một vai trò và một người dùng cá nhân là vai trò đại diện cho một lớp người dùng cụ thể, thay vì một người dùng thực tế. Những người dùng khác nhau có thể đóng cùng một vai trò, trong trường hợp đó mỗi người dùng cấu thành một trường hợp của một nhân vật.
Sự phân biệt này giữa các nhân vật và các trường hợp của nhân vật được minh họa trong phần sau:
Hình dưới đây cho thấy một trường hợp mà Mary và John là khách hàng của một máy bán hàng tự động. Khi họ sử dụng máy bán hàng tự động, mỗi người được đại diện bởi một trường hợp của một nhân vật gọi là khách hàng mà mong đợi có quyền truy cập vào một số chức năng nhất định của hệ thống (trong trường hợp này là in hóa đơn mua thực phẩm).
Chỉnh sửa minh họa máy bán hàng tự động này
Ngược lại, cùng một người dùng có thể đóng nhiều vai trò (tức là, cùng một người có thể đóng các vai trò khác nhau).
Ví dụ, Dr. Gates, người là thành viên của Ủy ban Xã hội Máy tính. Ông chịu trách nhiệm quản lý hệ thống quản lý thành viên, chẳng hạn như thêm và xóa tài khoản người dùng. Khi ông làm điều này, ông đóng vai trò là Quản trị viên (Nhân vật). Tuy nhiên, cùng một Dr. Gates cũng có thể là một thành viên của Xã hội Máy tính. Trong trường hợp này, ông cũng sẽ đóng vai trò là “Thành viên” (Nhân vật)
Làm thế nào để lấy các yêu cầu chức năng bằng cách xác định các trường hợp sử dụng của hệ thống
Một trường hợp sử dụng có thể được xác định bằng cách hỏi các bên liên quan các loại câu hỏi sau (mà họ phải trả lời từ góc độ của các nhân vật):
- Người dùng trong vai trò này đang cố gắng đạt được điều gì?
- Để thực hiện vai trò này, người dùng cần có khả năng làm gì?
- Các nhiệm vụ chính của người dùng trong vai trò này là gì?
- Người dùng trong vai trò này cần xem, tạo hoặc thay đổi thông tin gì?
- Người dùng trong vai trò này cần được hệ thống thông báo điều gì?
- Người dùng trong vai trò này cần thông báo cho hệ thống điều gì?
Lưu ý rằng:
Các trường hợp sử dụng thường được sử dụng như một phương tiện để khám phá và đại diện cho các yêu cầu chức năng và hệ thống, vì một trường hợp sử dụng xác định các tương tác và nhiệm vụ cần thực hiện để đạt được một mục tiêu kinh doanh cụ thể. Tuy nhiên, chúng thường không phải là cách tốt để xác định các yêu cầu phi chức năng, chẳng hạn như hiệu suất và chất lượng hệ thống.
Tài liệu tham khảo
- Câu chuyện người dùng vs Trường hợp sử dụng cho phát triển phần mềm Agile
- Câu chuyện người dùng là gì?
- Lập bản đồ câu chuyện người dùng là gì?
- Xác định yêu cầu người dùng với các sơ đồ trường hợp sử dụng
- Làm thế nào để sử dụng khung dây với các câu chuyện người dùng?
- Phương pháp dựa trên trường hợp sử dụng cho phát triển Agile
- Thông số trường hợp sử dụng là gì?
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.