业务用例模型与用例模型之间有什么区别?我应该为一个网站制作两个,但我无法理解有什么不同......帮助?
答案 0 :(得分:1)
也许另一种描述会有所帮助。
'业务'和'系统'用例的范围不同。前者包含客户和供应商为完成目标必须做的所有事情。其中一些可能涉及系统交互 - 但有些可能不会。例如,在线购买一本书。某些方面将涉及在线完成(例如浏览可用书籍,下订单)。但有些不是:挑选库存,包装,运输,签收包裹。
商业用例是整个互动的“黑匣子”描述(“购买书”)。完成任务意味着遵循业务流程。该过程中的一些步骤将涉及用户 - 系统交互,有些则不会。如果某个步骤涉及用户和系统(“浏览可用书籍”),则该步骤是系统用例。通常,对于给定的业务用例,会有许多系统用例。
那么你需要两者吗?这取决于具体情况。
如果您(a)负责完整的业务范围,并且(b)想要将业务功能记录为用例,那么业务UCD和支持UC定义是有用的。 UC描述中的步骤将代表业务流程。
如果其他人负责业务级别的定义,那么您可能不需要。
最后一件事:有时两者是巧合的。例如:购买电子书。业务需求是让客户能够获得他们的书。整个过程可以通过单一系统交互(选择书籍,付费,接收下载)进行交付 - 因此可以由单个系统用例覆盖。因此,业务和系统用例是等效的。
第h
答案 1 :(得分:0)
这样想:
商家UC (用例)绝对没有技术细节。您需要退一步看看业务需求。因此,业务UC可能类似于:
请注意,这一切都没有说明如何完成任务。在这一点上,它几乎是一个列入行动 - 主题 - 限定符格式的所需功能的列表。
您可以将它们与演员一起放入用例模型中,并且您拥有一组非常有用的高级业务UC。完成对具有前后条件的UCs进行规范,以及对低级业务UC进行规划。但在这种情况下,路径的细节尚不清楚。
系统UC 包含对这些业务UC的系统级视角。因此,虽然管理在线照片可能会描述上传照片并将其分组到相册的需要,但系统UC实际上可能变成:
我们已经了解了技术细节。企业可能会考虑存储和交换照片,但您知道系统如何感知和处理照片和位图图像几乎没有什么区别。您已经开始考虑上传图片所涉及的内容以及用户可能需要处理的图片。
我希望这会有所帮助。