documentation - 用例文档的详细程度

Question

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

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

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

score 3 · Accepted Answer

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

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

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

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

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

score 3 · Accepted Answer

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

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

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

score 2 · Accepted Answer

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

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

您不可能预先知道所有内容，但一定要记录您所知道的。

score 0 · Accepted Answer

用例描述应介于：

score 0 · Accepted Answer

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

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

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

有关详细信息...请参阅“应用 UML 和模式：Craig Larman 的面向对象分析与设计和迭代开发简介”

5 回答 5