用例文档的详细程度[关闭]答案

【问题标题】：Detail Level of Use Case Documentation [closed]用例文档的详细程度[关闭]
【发布时间】：2008-10-23 19:31:25
【问题描述】：

我正在努力规范我的项目并在一开始就创建一个愿景/范围文档。其中包括用例图。仅仅列出用例确实帮助我全面了解客户要求的所有需求，并且打开了对话。

我想知道用例应该有多详细。如果我正在制作一个 Web 应用程序并且用户将登录以查看报告，我是否会在用例描述中列出报告中的所有列？

如果不是，那我什么时候记录这些细节？

【问题讨论】：

【解决方案1】：

用例图的优势在于它们很简单，最终用户可以阅读和理解它们

报告中的列是设计或需求规范的一部分（敏捷术语中的功能细节），不属于用例图

任何使用例图混乱的东西都属于其他地方

在哪里？没关系，只要它是一个一致的地方并且你知道在哪里可以找到它;-)

提醒人们用例图是什么样的 - 以及为什么没有虚假细节的空间 -
_{（来源：agilemodeling.com）}

【讨论】：

【解决方案2】：

我工作的用例是从用户的角度对应用程序的描述。在那个层面上，它是非常详细的。因此，在您的报告示例中，用例将描述报告的布局、显示的数据、显示的顺序等。用例并没有告诉您这些数据是如何获取的，或者来自哪里。

另一种看待它的方式是考虑将用例交给测试人员。他们可以测试文档中的任何内容（黑盒测试）并将其注册为缺陷。因此，如果某些数据应该在某些条件下显示，则应在您的用例中指定该案例，以便对其进行测试。

您可能想要创建以完成图片的其他文档是我们所说的 SAD（软件架构文档）和 NFR（非功能性要求）。 SAD 将从软件设计的角度描述您将如何对解决方案进行编程、您将使用哪些技术以及需要哪些算法。 NFR 将包括从软件或硬件中断中恢复、响应时间等内容。

【讨论】：

【解决方案3】：

如果您知道应该包含哪些列，那么可以，将它们放入文档中。如果您必须先考虑一下，然后这样做并记录下来。这将节省程序员以后思考或询问的时间，从而使整个过程更加高效。

但是，如果您真的不知道应该包含哪些列，因为您对开发开始后整个系统将如何发挥作用还不够了解，那么请不要不用担心，只需说“特定列待定”。

您无法预先知道所有内容，但一定要记录下您所知道的。

【讨论】：

你见过用例图吗？这种细节没有空间，它违背了目的......agilemodeling.com/images/models/useCaseDiagram.jpg
用例是一个文档。用例图是一幅漂亮的图画。如果您正在谈论记录要求，那么您真的需要两者。
是的，我看过用例图，但我也看过用例文档，其中包含对流程的文本描述，其中包括目标、参与者、前提条件、成功条件等部分。我的回答更相关对那些人来说，因为将它放在图表中显然没有意义。
图表是帮助解释文本的工具。我见过没有图表的用例文档。例如登录系统的用例可能是： 1. 用户输入用户 ID 和密码（如果字段为空白，则返回错误 123） 2. 验证用户（如果失败则返回错误 456） 3. 导航到主页
抱歉，我从敏捷的角度回答，用例图是讨论特性的起点，永远没有用例、需求或任何其他“文档”可以杀死树并过时;-) [加上问题是专门关于用例图的]

【解决方案4】：

用例描述应介于：

【讨论】：

【解决方案5】：

使用 UML 符号构建用例图有助于我们快速理解和指定需求，通常可以在软件工程师团队面前绘制用例图以快速了解情况。

实际上，用例应该是书面格式。它具有三种格式。

如果是报告，报告格式和规格应附在SRS文件中，以便进行相应的测试。

详情... 请参阅“应用 UML 和模式：Craig Larman 的面向对象分析、设计和迭代开发简介”

【讨论】：