Visual Paradigm Desktop | 
Visual Paradigm Online
Là một Người sở hữu sản phẩm, bạn đứng ở giao điểm giữa chiến lược kinh doanh và thực thi kỹ thuật. Bạn chuyển đổi tầm nhìn thành các yêu cầu khả thi, đảm bảo đội ngũ xây dựng giá trị một cách hiệu quả. Một trong những công cụ mạnh mẽ nhất trong kho vũ khí của bạn để trực quan hóa hành vi hệ thống là sơ đồ Trường hợp sử dụng. Mặc dù thường được liên kết với các kỹ sư phần mềm, những sơ đồ này rất quan trọng để làm rõ phạm vi, xác định các bên liên quan và ngăn chặn hiện tượng mở rộng phạm vi không kiểm soát.
Nhiều đội nhóm coi những sơ đồ này là gánh nặng tài liệu nặng nề. Đây là một sai lầm. Khi tiếp cận đúng cách, sơ đồ Trường hợp sử dụng hoạt động như nguồn thông tin duy nhất về chức năng. Nó cầu nối khoảng cách giữa nhu cầu người dùng trừu tượng và các hành động cụ thể của hệ thống. Hướng dẫn này nêu ra một cách tiếp cận thực tế, đơn giản để tạo ra những sơ đồ này mà không bị lạc trong những phức tạp lý thuyết.
Người sở hữu sản phẩm quản lý một luồng yêu cầu liên tục. Không có biểu diễn trực quan rõ ràng, các yêu cầu có thể trở nên rời rạc. Sơ đồ Trường hợp sử dụng cung cấp bản đồ cấp cao của hệ thống. Nó trả lời những câu hỏi then chốt ngay từ đầu vòng đời:
Bằng cách thiết lập những giới hạn này, bạn ngăn đội ngũ xây dựng các tính năng nằm ngoài phạm vi dự kiến. Nó đóng vai trò như một hợp đồng giữa bộ phận kinh doanh và đội phát triển. Khi xảy ra bất đồng về chức năng, sơ đồ cung cấp một điểm tham chiếu khách quan.
Hơn nữa, việc trực quan hóa này hỗ trợ giao tiếp với các bên liên quan. Các nhà điều hành và khách hàng thường gặp khó khăn trong việc hiểu các thuật ngữ kỹ thuật. Một sơ đồ đơn giản hóa câu chuyện. Nó thể hiện luồng tương tác mà không cần hiểu sâu về kiến trúc mã nguồn. Sự rõ ràng này thúc đẩy quá trình ra quyết định và giảm thời gian dành cho các cuộc họp giải thích lặp lại.
Để xây dựng một sơ đồ hiệu quả, bạn phải hiểu các thành phần cơ bản của nó. Hãy nghĩ về chúng như những khối xây dựng của bản mô tả yêu cầu trực quan của bạn. Có bốn thành phần chính mà bạn sẽ gặp lặp lại nhiều lần.
Một Người tham gia đại diện cho một vai trò do người dùng hoặc một hệ thống bên ngoài thực hiện, tương tác với hệ thống chính. Điều quan trọng cần nhớ là một Người tham gia không phải là một người cụ thể; đó là một vai trò. Ví dụ, “Khách hàng” là một Người tham gia, chứ không phải “John Smith”.
Một Trường hợp sử dụng đại diện cho một chức năng hoặc mục tiêu cụ thể mà hệ thống thực hiện cho một Người tham gia. Nó mô tả điều gìhệ thống làm, chứ không phải cách thứcnó làm điều đó. Mỗi trường hợp sử dụng nên là một đơn vị chức năng riêng biệt và có giá trị.
Biên giới hệ thống là một hộp xác định phạm vi của phần mềm. Tất cả những gì bên trong hộp đều thuộc về hệ thống. Tất cả những gì bên ngoài là bên ngoài. Đây có thể là yếu tố quan trọng nhất đối với người sở hữu sản phẩm.
Các đường nối kết nối các tác nhân với các trường hợp sử dụng và các trường hợp sử dụng với nhau. Những đường này xác định cách các thành phần tương tác với nhau. Có ba loại mối quan hệ chính mà bạn cần quản lý.
Việc tạo sơ đồ từ đầu có thể khiến bạn cảm thấy choáng ngợp. Để tối ưu hóa quá trình này, hãy tuân theo một quy trình có cấu trúc. Phương pháp này đảm bảo bạn thu thập được tất cả các yêu cầu cần thiết mà không bị mắc kẹt vào chi tiết.
Bắt đầu bằng cách vẽ một hộp đơn giản. Đặt nhãn cho nó bằng tên của ứng dụng hoặc mô-đun mà bạn đang xác định. Hộp này đại diện choBiên giới hệ thống. Viết ra mục đích cốt lõi của hệ thống bên cạnh nó. Điều này giúp cố định sơ đồ và giữ cho đội nhóm tập trung.
Thu thập các bên liên quan. Hỏi họ ai là người sử dụng hệ thống. Phân loại họ thành các tác nhân chính và phụ. Tránh liệt kê các chức danh cụ thể nếu có thể; hãy tập trung vào vai trò họ đóng trong bối cảnh phần mềm.
Với mỗi Người tham gia, hãy đặt câu hỏi họ muốn đạt được điều gì. Những mục tiêu này sẽ trở thành các Trường hợp sử dụng của bạn. Đảm bảo rằng mỗi trường hợp sử dụng được xác định đều mang lại lợi ích rõ ràng cho Người tham gia. Nếu một Trường hợp sử dụng không mang lại giá trị cho bất kỳ ai, nó cần được loại bỏ.
Vẽ các đường nối giữa Người tham gia và các Trường hợp sử dụng tương ứng của họ. Đảm bảo mỗi Người tham gia đều có ít nhất một kết nối. Nếu một Người tham gia không có trường hợp sử dụng nào, họ có thể không cần thiết cho phiên bản hệ thống cụ thể này.
Xem xét các Trường hợp sử dụng để tìm ra những điểm chung. Nếu nhiều trường hợp sử dụng yêu cầu cùng một quy trình con (như “Xác thực”), hãy tách phần đó ra thành một Trường hợp sử dụng riêng và liên kết nó bằng mối quan hệ “Bao gồm mối quan hệ. Nếu một trường hợp sử dụng có các bước tùy chọn (như “Áp dụng mã giảm giá”), hãy liên kết nó bằng mối quan hệ “Mở rộng mối quan hệ.
Sơ đồ mang tính trực quan, nhưng bảng tính lại rất tốt cho việc kiểm tra. Ma trận giúp đảm bảo rằng bạn đã xem xét mọi tổ hợp giữa Người tham gia và Trường hợp sử dụng. Điều này đặc biệt hữu ích trong quá trình tinh chỉnh danh sách công việc.
Dưới đây là một cấu trúc ví dụ mà bạn có thể sử dụng để xác minh yêu cầu của mình trước khi vẽ các đường nối trên sơ đồ.
| Người tham gia | Trường hợp sử dụng 1 | Trường hợp sử dụng 2 | Trường hợp sử dụng 3 | Ghi chú |
|---|---|---|---|---|
| Người dùng khách | Xem danh mục | Tìm kiếm sản phẩm | – | Không thể thanh toán mà không có tài khoản |
| Người dùng đã đăng ký | Xem danh mục | Tìm kiếm sản phẩm | Đặt hàng | Có phương thức thanh toán đã lưu |
| Quản trị viên | Quản lý người dùng | Cập nhật tồn kho | Xem báo cáo | Yêu cầu quyền hạn nâng cao |
| Cổng thanh toán | Xử lý giao dịch | – | – | Hệ thống bên ngoài |
Sử dụng bảng giúp bạn phát hiện các khoảng trống một cách nhanh chóng. Nếu một hàng trống, có thể người tham gia đó không thực hiện bất kỳ hành động nào trong khu vực đó. Nếu một cột trống, có thể trường hợp sử dụng đó không thể truy cập bởi bất kỳ ai. Bước xác minh này giúp tiết kiệm hàng giờ công sức sửa chữa sau này.
Trong khi sơ đồ trường hợp sử dụng cung cấp cái nhìn tổng thể, các câu chuyện người dùng cung cấp cái nhìn chi tiết. Chúng là các công cụ bổ trợ cho nhau. Một trường hợp sử dụng đơn lẻ thường bao gồm nhiều câu chuyện người dùng.
Khi phân tích một trường hợp sử dụng thành các câu chuyện, hãy tuân theo các hướng dẫn sau:
Ví dụ, nếu trường hợp sử dụng là “Đặt hàng,” các câu chuyện người dùng có thể là:
Sự liên kết này đảm bảo công việc chi tiết phù hợp với kế hoạch trực quan cấp cao. Nó ngăn đội ngũ đi lệch sang các tính năng không hỗ trợ các yêu cầu biểu đồ cốt lõi.
Ngay cả những chuyên gia có kinh nghiệm cũng mắc sai lầm khi tạo các sơ đồ này. Việc nhận thức được những lỗi phổ biến sẽ giúp bạn duy trì sự rõ ràng và hiệu quả.
Một sơ đồ với hàng trăm đường kẻ là vô dụng. Nếu sơ đồ của bạn trông giống như một mạng lưới rối ren, thì nó quá chi tiết cho một cái nhìn tổng quan cấp cao. Bạn nên hướng đến mức độ tóm tắt. Nếu một quy trình quá phức tạp, hãy tạo một sơ đồ tuần tự chi tiết riêng biệt cho trường hợp sử dụng cụ thể đó.
Không vẽ các hộp cho cơ sở dữ liệu hoặc bảng dữ liệu bên trong ranh giới hệ thống. Các trường hợp sử dụng là hành động, không phải cấu trúc dữ liệu. Hệ thống có thể truy cập dữ liệu, nhưng sơ đồ tập trung vào điều hệ thống làm cho người dùng.
Sử dụng tên như “Người dùng” là quá chung chung. Phân biệt giữa “Khách truy cập ẩn danh”, “Thành viên đã đăng ký”, và “Quản trị viên”. Mỗi người có quyền hạn và tương tác khác nhau. Tính cụ thể giúp giảm sự mơ hồ trong quá trình phát triển.
Phần mềm hiện đại hiếm khi tồn tại trong trạng thái tách biệt. Bạn phải biểu diễn các API bên ngoài, dịch vụ bên thứ ba hoặc thiết bị phần cứng như các Người dùng phụ. Nếu một giao dịch thanh toán thất bại do ngân hàng bên ngoài bị lỗi, đó là một tương tác hệ thống cần được hiển thị rõ ràng.
Sơ đồ không phải là tài liệu cố định. Yêu cầu thay đổi theo thời gian. Bạn phải sẵn sàng cập nhật sơ đồ khi sản phẩm phát triển. Xem nó như một tài liệu sống động, chứ không phải là một sản phẩm giao nộp một lần.
Việc tạo sơ đồ chỉ là một nửa cuộc chiến. Bạn phải đảm bảo rằng nó được hiểu và chấp nhận bởi cả đội.
Khi các bên liên quan xem xét sơ đồ, họ thường nhìn thấy bức tranh tổng thể. Đây là lúc để xác nhận rằng các mục tiêu kinh doanh đã được đáp ứng. Nếu một bên liên quan yêu cầu một tính năng nằm ngoài ranh giới, bạn có thể chỉ vào sơ đồ và giải thích lý do tại sao nó nằm ngoài phạm vi cho lần phát hành này.
Làm sao bạn biết sơ đồ trường hợp sử dụng của mình có hiệu quả không? Hãy tìm những dấu hiệu sau:
Phần mềm là động. Khi bạn phát hành cập nhật, sơ đồ phải thay đổi theo. Đừng coi sơ đồ như một tài liệu yêu cầu tĩnh.
Tính nhất quán là chìa khóa. Nếu bạn cập nhật sơ đồ, hãy đảm bảo các User Stories và Tiêu chí chấp nhận cũng được cập nhật đồng thời. Điều này giúp toàn bộ tài liệu luôn được đồng bộ.
Để kết thúc hướng dẫn này, đây là danh sách kiểm tra nhanh cho buổi họp tiếp theo của bạn.
Bằng cách tuân theo những nguyên tắc này, bạn có thể tạo ra các sơ đồ đóng vai trò là nền tảng vững chắc cho phát triển sản phẩm. Bạn không cần phải có nhiều năm kinh nghiệm để làm điều đó. Bạn cần một cách tiếp cận có cấu trúc và tập trung vào sự rõ ràng. Với thực hành, bạn sẽ có thể hình dung nhanh chóng và hiệu quả các yêu cầu hệ thống, giúp đội nhóm của bạn tập trung vào việc tạo ra giá trị.
Hãy nhớ, mục tiêu không phải là tạo ra một tác phẩm nghệ thuật hoàn hảo. Mục tiêu là tạo ra một công cụ giúp giảm rủi ro và cải thiện giao tiếp. Bắt đầu nhỏ, lặp lại thường xuyên, và để sơ đồ dẫn dắt tầm nhìn sản phẩm của bạn.