Câu hỏi: SWR302 - Phần 5: Ca sử dụng, câu chuyện người dùng và quy tắc nghiệp vụ

Các mối quan hệ giữa Use Case được sử dụng để mô tả mối quan hệ giữa các Use Case khác nhau. Một mối quan hệ Include cho thấy một Use Case bao gồm hành vi được mô tả trong một Use Case khác. Một mối quan hệ Extend cho thấy một Use Case có thể mở rộng hành vi được mô tả trong một Use Case khác. Tương tự như quan hệ kế thừa trong lập trình hướng đối tượng, mối quan hệ Generalization giữa Use Case cho thấy Use Case con là một dạng cụ thể hơn của Use Case cha. Use Case con thừa kế tất cả các tính năng và mối quan hệ của Use Case cha và có thể thêm mới các tính năng và mối quan hệ. Do đó, tất cả các câu trả lời trên đều đúng.

Câu hỏi này yêu cầu bạn xác định ví dụ nào không thuộc loại quy tắc kinh doanh Action Enablers. Action Enablers là loại quy tắc kinh doanh giúp kích hoạt hành động cụ thể trong một quy trình. Ví dụ 1 và 2 là các quy tắc kinh doanh Action Enablers vì chúng kích hoạt hành động cụ thể khi một điều kiện nhất định được đáp ứng. Ví dụ 3 cũng là một quy tắc kinh doanh Action Enablers vì nó kích hoạt hành động thông báo khi một điều kiện nhất định được đáp ứng. Tuy nhiên, ví dụ 4 không phải là một quy tắc kinh doanh Action Enablers vì nó không kích hoạt hành động cụ thể mà chỉ là một tuyên bố về một thực tế.

Khái niệm quy tắc kinh doanh được định nghĩa từ góc độ kinh doanh như sau: Quy tắc kinh doanh là một tuyên bố xác định hoặc hạn chế một khía cạnh nào đó của hoạt động kinh doanh. Mục đích của nó là xác định cấu trúc kinh doanh hoặc kiểm soát hoặc ảnh hưởng đến hành vi của doanh nghiệp. Điều này có nghĩa là quy tắc kinh doanh cung cấp hướng dẫn về cách thức hoạt động, hành vi và quy trình kinh doanh. Nó giúp đảm bảo rằng các hoạt động kinh doanh được thực hiện một cách nhất quán và tuân thủ các quy định, quy tắc và chính sách đã được thiết lập. Từ đó, giúp doanh nghiệp đạt được mục tiêu và tăng cường hiệu suất kinh doanh.

Các Use Case mô tả các tương tác giữa hệ thống và các thực thể bên ngoài. Điều này có nghĩa là chúng mô tả các hành động mà người dùng thực hiện với hệ thống và hệ thống phản hồi lại như thế nào. Điều này giúp cho các nhà phát triển hiểu rõ hơn về yêu cầu của người dùng và có thể xây dựng được hệ thống đáp ứng được nhu cầu của họ. Ngoài ra, các Use Case cũng giúp cho việc xác định các yêu cầu chức năng của hệ thống trở nên dễ dàng hơn. Vì vậy, các Use Case là công cụ quan trọng trong việc thu thập và xác định các yêu cầu của hệ thống.

Sự khác biệt giữa Use Cases và User Stories là gì? Use Cases là một tài liệu kinh doanh xác định yêu cầu phần mềm hoặc tính năng ứng dụng. Trong khi đó, User Stories là một tài liệu kiểm thử xác định các bước để xác minh và xác thực rằng yêu cầu phần mềm hoặc tính năng ứng dụng tồn tại. Use Cases thường được sử dụng để mô tả các yêu cầu kinh doanh và chức năng của ứng dụng, trong khi User Stories được sử dụng để mô tả các yêu cầu kiểm thử và xác thực. Ví dụ, một Use Case có thể mô tả cách một người dùng có thể tạo một tài khoản mới, trong khi một User Story có thể mô tả các bước để kiểm thử tính năng tạo tài khoản mới.

Trong câu hỏi này, chúng ta đang được hỏi về loại quy tắc kinh doanh được thể hiện trong một tuyên bố cụ thể. Tuyên bố này cho rằng nếu một khách hàng tiềm năng không phản hồi lại sau 30 ngày kể từ khi liên hệ lần đầu tiên, thì đó phải là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó. Loại quy tắc kinh doanh được thể hiện ở đây là quy tắc suy luận (inference). Quy tắc suy luận là quy tắc kinh doanh cho phép hệ thống đưa ra kết luận hoặc quyết định dựa trên dữ liệu và thông tin đã có. Trong trường hợp này, hệ thống sẽ suy luận rằng khách hàng tiềm năng không phản hồi lại sau 30 ngày là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó.

Đáp án đúng: "exceptions". Trong đặc tả use case (ca sử dụng), luồng chính mô tả con đường thành công thường gặp nhất; exceptions (ngoại lệ) là các điều kiện có thể ngăn ca sử dụng hoàn thành thành công, chẳng hạn mất kết nối hay thẻ thanh toán bị từ chối, kèm cách hệ thống phản ứng như báo lỗi, khôi phục hoặc kết thúc. Phương án "alternative flows" sai vì luồng thay thế là các biến thể vẫn dẫn tới mục tiêu thành công, chỉ đi đường khác so với luồng chính. Phương án "secondary scenarios" là cách gọi chung các kịch bản khác ngoài kịch bản chính, có thể gồm cả luồng thay thế lẫn ngoại lệ, nên không chỉ đích danh các điều kiện gây thất bại. Phương án "backup flows" không phải thuật ngữ chuẩn trong mô tả use case.

Đáp án đúng gồm ba ý: "“Common knowledge” from the organization, often collected from individuals who have worked with the business for a long time and know the details of how it operates.", "Legacy systems that embed business rules in their requirements and code." và "Analysis of existing documentation, including requirements specifications from earlier projects, regulations, industry standards, corporate policy documents, contracts, and business plans.". Business rule (quy tắc nghiệp vụ) là chính sách, quy định, tiêu chuẩn chi phối hoạt động của tổ chức, thường tồn tại độc lập với phần mềm. Người phân tích tìm chúng qua phỏng vấn những người làm lâu năm nắm kiến thức ngầm, qua việc phân tích hệ thống cũ nơi quy tắc đã được nhúng vào yêu cầu và mã, và qua đọc tài liệu sẵn có như đặc tả cũ, quy định, tiêu chuẩn ngành, chính sách công ty, hợp đồng. Phương án "Business laws" chỉ là một nhãn mơ hồ, không phải một nơi hay một cách tìm cụ thể; các quy định pháp luật liên quan đã nằm trong việc phân tích tài liệu sẵn có.

Đáp án đúng: "primary". Trong sơ đồ use case, đường liên kết có mũi tên đi từ tác nhân (actor) tới use case cho biết tác nhân đó khởi động use case, tức là tác nhân chính (primary actor), người có mục tiêu mà use case phục vụ. Ví dụ nhân viên phòng thí nghiệm khởi động use case đặt mua hoá chất. "secondary" sai vì tác nhân phụ chỉ tham gia hỗ trợ để use case hoàn tất, như một hệ thống kho bên ngoài được gọi tới, và mũi tên khi có thường đi từ use case hướng ra tác nhân đó. "main" nghe gần nghĩa trong cách nói thông thường nhưng không phải thuật ngữ chuẩn dùng để phân loại tác nhân trong mô hình use case. "side" hoàn toàn không phải một loại tác nhân trong UML hay trong kỹ nghệ yêu cầu.

Đáp án đúng gồm hai ý: "Actors" và "Name". Một đặc tả ca sử dụng tối thiểu phải có định danh, tên ca sử dụng, thường là động từ cộng danh từ nói lên mục tiêu, và tác nhân (actor) khởi động hoặc tham gia tương tác; thiếu tên thì không gọi được, thiếu tác nhân thì không biết ai hưởng lợi, nên ca sử dụng không còn ý nghĩa. "Pre-condition" là chỗ hay gây tranh cãi: có người cho rằng tiền điều kiện cũng bắt buộc vì mẫu đặc tả nào cũng có ô này, nhưng thực ra nó nên có chứ không bắt buộc; nhiều ca sử dụng không cần điều kiện gì trước khi bắt đầu và ô đó được để trống, nên nó không thuộc phần bắt buộc. "Post-condition" tương tự, hậu điều kiện mô tả trạng thái hệ thống sau khi ca sử dụng hoàn tất, rất hữu ích cho kiểm thử và nên được viết, nhưng có thể bỏ trống khi chưa đủ thông tin mà ca sử dụng vẫn hợp lệ, nên cũng không bắt buộc.

Trong mô hình Use Case, Pre-Condition (hay còn gọi là Điều kiện tiền đề) là một điều kiện hoặc trạng thái mà hệ thống phải đáp ứng trước khi một Use Case có thể bắt đầu. Điều này có nghĩa là hệ thống phải ở trong một trạng thái nhất định hoặc phải thỏa mãn một số điều kiện nhất định trước khi nó có thể thực hiện một Use Case. Ví dụ, trước khi một người có thể đăng ký một tài khoản trên một trang web, hệ thống phải có sẵn một form đăng ký và người dùng phải có một địa chỉ email hợp lệ. Nếu hệ thống không đáp ứng được những điều kiện này, thì Use Case đó sẽ không thể bắt đầu. Pre-Condition giúp đảm bảo rằng hệ thống luôn ở trong một trạng thái nhất định và có thể thực hiện các Use Case một cách hiệu quả.

Tên các trường hợp sử dụng nên được viết theo cách mô tả. Ví dụ, nếu trường hợp sử dụng liên quan đến việc đăng ký tài khoản, tên trường hợp sử dụng có thể là 'Đăng ký tài khoản mới'. Điều này giúp cho các nhà phát triển và người dùng dễ dàng hiểu được mục đích và chức năng của trường hợp sử dụng. Tên trường hợp sử dụng nên được viết một cách rõ ràng, ngắn gọn và dễ hiểu, giúp cho việc giao tiếp và hợp tác giữa các thành viên trong nhóm được hiệu quả hơn.

Đáp án đúng: "Use Cases describe the interactions between the system and external entities.". Use case (ca sử dụng) mô tả một chuỗi tương tác giữa tác nhân (actor) bên ngoài, có thể là người dùng hay hệ thống khác, với hệ thống để đạt được một mục tiêu có giá trị cho tác nhân. Đây là kỹ thuật thu nhận yêu cầu người dùng (user requirements), dùng trong khơi gợi và phân tích. "Use Cases are static and do not evolve throughout the software development process." sai vì ca sử dụng được tinh chỉnh dần: ban đầu chỉ có tên và mô tả ngắn, sau đó thêm luồng chính, luồng thay thế, ngoại lệ và có thể đổi khi hiểu biết thay đổi. "Use case diagrams are the primary tool to document requirements" sai vì sơ đồ ca sử dụng chỉ là bức tranh tổng quan về phạm vi và các tác nhân; giá trị nằm ở phần đặc tả bằng văn bản, và yêu cầu chức năng chi tiết vẫn phải ghi trong SRS. "Use Cases are not useful in capturing user requirements." sai vì thu nhận yêu cầu người dùng chính là công dụng chủ yếu của ca sử dụng, giúp tập trung vào việc người dùng cần làm thay vì vào tính năng rời rạc.

Một quy tắc kinh doanh là một tuyên bố xác định hoặc hạn chế một khía cạnh nào đó của kinh doanh để kiểm soát hoặc ảnh hưởng đến hành vi của nó. Điều này có nghĩa là quy tắc kinh doanh xác định các điều kiện hoặc hạn chế nào cần được tuân thủ để đảm bảo hoạt động kinh doanh được thực hiện một cách hiệu quả và chính xác. Ví dụ, một quy tắc kinh doanh có thể xác định rằng một khách hàng phải là người lớn mới có thể thực hiện một giao dịch mua hàng trực tuyến. Việc xác định và áp dụng các quy tắc kinh doanh giúp đảm bảo rằng hoạt động kinh doanh được thực hiện một cách nhất quán và chính xác. Ngoài ra, việc phân loại các quy tắc kinh doanh giúp hiểu rõ cách chúng có thể được áp dụng trong một ứng dụng phần mềm, chẳng hạn như sử dụng hạn chế để thực hiện các điều kiện nhất định.

Sử dụng mô hình hóa quy trình kinh doanh để khám phá các quy tắc kinh doanh có thể giúp xác định các quy tắc ảnh hưởng đến từng bước quy trình, bao gồm cả hạn chế và sự kiện kích hoạt. Điều này có thể giúp các doanh nghiệp hiểu rõ hơn về quy trình kinh doanh của mình và xác định các quy tắc cần thiết để thực hiện chúng. Mô hình hóa quy trình kinh doanh có thể giúp các doanh nghiệp xác định các quy tắc liên quan đến dữ liệu, hạn chế và sự kiện kích hoạt, từ đó giúp họ tạo ra các quy trình kinh doanh hiệu quả hơn và giảm thiểu sai sót. Ngoài ra, mô hình hóa quy trình kinh doanh cũng giúp các doanh nghiệp dễ dàng cập nhật và thay đổi quy trình kinh doanh của mình khi cần thiết.

Dưới đây là giải thích về câu hỏi lựa chọn đúng loại quy tắc kinh doanh theo phân loại. Câu hỏi yêu cầu tìm loại quy tắc không phải là loại quy tắc kinh doanh theo phân loại. Các lựa chọn bao gồm: "Quy tắc thực tế", "Quy tắc kích hoạt hành động", "Quy tắc hạn chế", "Quy tắc hoạt động". Theo phân loại, "Quy tắc thực tế" không phải là loại quy tắc kinh doanh. Quy tắc thực tế liên quan đến dữ liệu và thông tin, trong khi các quy tắc kinh doanh khác liên quan đến hành động, hạn chế và hoạt động của doanh nghiệp.

Sử dụng biểu đồ Use case giúp bạn biểu diễn mối quan hệ giữa cách dữ liệu được lưu trữ. Biểu đồ này mô tả các trường hợp sử dụng của hệ thống và mối quan hệ giữa chúng. Tuy nhiên, biểu đồ Use case không trực tiếp liên quan đến cách dữ liệu được lưu trữ trong cơ sở dữ liệu. Nó tập trung vào việc mô tả các hoạt động và chức năng của hệ thống, chứ không phải là cách dữ liệu được tổ chức và lưu trữ. Vì vậy, câu trả lời đúng là FALSE.

Đáp án đúng: "Because it ensures that use cases capture the correct interaction scenarios by clearly defining the roles (actors) that a user can assume.". Người dùng (user) là con người cụ thể, còn tác nhân (actor) là một vai trò tương tác với hệ thống; một người có thể đóng nhiều vai, và một actor cũng có thể là hệ thống khác hoặc thiết bị. Phân biệt hai khái niệm giúp use case được viết theo vai trò và mục tiêu của vai trò đó, nhờ vậy kịch bản tương tác đúng và không trùng lặp. Phương án "allows designers to ignore interactions with non-human systems" sai vì actor chính là cách đưa hệ thống ngoài vào mô hình, không phải bỏ qua chúng. Phương án "simplifies the use case diagrams by limiting the number of actors" sai vì mục đích là mô tả đúng vai trò, không phải giảm số actor. Phương án "separates the business logic from the technical implementation" sai vì đó là nguyên tắc chung của việc tách yêu cầu khỏi thiết kế, không liên quan tới phân biệt user với actor.

Đáp án đúng: "The "then" clause of an inference simply provides a piece of knowledge, not an action to be taken". Trong phân loại quy tắc nghiệp vụ, inference (quy tắc suy diễn) và action enabler cùng có dạng nếu điều kiện thì kết quả, nhưng vế sau khác bản chất: inference tạo ra một sự thật mới, ví dụ nếu khách hàng chưa thanh toán sau 30 ngày thì tài khoản bị coi là quá hạn, còn action enabler ra lệnh hệ thống làm một việc. Phương án "Inferences trigger a system action, while action enablers provide new knowledge" đảo ngược hai khái niệm. Phương án "Inferences are always quantitative, while action enablers are qualitative" sai vì loại quy tắc mang tính định lượng là computation (quy tắc tính toán), còn inference có thể hoàn toàn định tính. Phương án "Action enablers are atomic, while inferences are composite" sai vì cả hai đều là quy tắc nguyên tử trong phân loại này; quy tắc phức hợp thường được tách thành nhiều quy tắc nguyên tử.