详细程度的用例文档

Question

我正在努力管理我的项目并在一开始就创建一个愿景/范围文档。其中包括用例图。只列出用例确实帮助我完全看到了客户要求的所有要求，并且已经打开了对话框。

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

如果没有，那么我何时会记录这些细节？

Answer 1

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

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

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

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

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

Answer 2

我工作的用例是从用户角度对应用程序的描述。在那个级别，它非常详细。因此，在您的报告示例中，用例将描述报告的布局，显示的数据，按什么顺序等等。用例没有告诉你的是如何获取数据，或者它来自何处。

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

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

Answer 3

如果你知道应该包含哪些列，那么是，将它们放在文档中。如果你必须先考虑它，那么这样做并记录下来。它将节省程序员以后不得不思考或询问它，这使整个过程更有效。

但是，如果你真的不知道还应该包含哪些列，因为你不了解整个系统在开发过程中将如何发挥作用，那么就不要担心它，只是说“特定列TBD。”

您无法预先知道所有，但绝对记录您所知道的内容。

Answer 4

用例描述应介于：

之间

• 低细节：这样的用户 了解它，并认为：“如何 这很容易“
• 高细节：没有开放的可能性（详细描述什么 在每个步骤后发生）

Answer 5

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

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

1. 的简
2. 的休闲
3. 完全穿着

如果是报告，报告格式＆amp;规范应附有SRS文件，以便相应地进行测试。

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