业务用例和用例

Question

业务用例模型和用例模型之间有什么区别？我应该为一个网站做这两件事，但我不明白有什么区别.帮助?

Answer 1

或许另一种描述会有所帮助。

“业务”和“系统”用例的范围不同。前者包括客户和供应商为完成目标所必须做的一切。其中有些可能涉及系统交互，但有些则可能不涉及。举个例子，在网上买一本书。某些方面将涉及在线完成(例如浏览现有书籍，下单)。但有些不是:挑选库存、包装、发货、签收包裹。

业务用例是对整个交互的“黑匣子”描述(“Book")。完成任务意味着遵循业务流程。该过程中的一些步骤将涉及用户-系统交互，而有些则不会。如果步骤涉及用户和系统(“浏览可用书籍”)，则该步骤是系统用例。通常，对于给定的业务用例，会有许多系统用例。

所以你两者都需要吗？这取决于环境。

如果您(a)负责整个业务范围，(b)希望将业务功能文档化为用例，那么business和支持UC定义是有用的。UC描述中的步骤表示业务流程。

如果其他人负责业务级别的定义，那么您可能不需要负责。

最后一件事:有时两者是一致的。例如:购买一台eBook。企业需要的是客户能够获得他们的书。整个事件可以在一个单一的系统交互中交付(选择图书、付费、接收下载)--因此可以由一个系统用例来覆盖。因此，业务和系统用例是等价的。

hth。

Answer 2

你可以这样想：

业务UC (用例)绝对不包含任何技术细节。你需要后退一步，看看企业的需求。因此，商业UCs可能是这样的：

• 管理照片在线
• 创建个人日志与其他用户在线
• 与其他用户共享照片

请注意，所有这些都不能说明它将如何完成。在这一点上，它很大程度上是一个所需的功能清单，投入到行动-主题-限定符格式。

您可以将它们与参与者放在一个用例模型中，并且您有一组非常有用的高级业务UC。完成对低级别业务UCs的前后条件等方面的说明.但是在这个时候，路径的细节还不清楚。

一个系统UC包含了这些业务UC的系统级透视图。因此，虽然在线管理照片可能会描述上传照片并将其分组为相册的需要，但系统UCs实际上可能会变成：

deleting)

• Manage

• 上传图像(带有上传、命名、裁剪和相册的路径(有创建、添加图像和删除图像的路径)

这里我们讨论了技术细节。企业可能在考虑如何存储和交换照片，但您知道，系统将如何感知和处理照片和位图图像并没有什么不同。您已经开始思考上传图像所涉及的内容以及用户可能需要对这些图像做些什么。

希望这能帮上忙。