2

I've just finished the implementation of my software system and now I have to document whether it has satisfied its requirements. What sort of information should I include and how should I lay it out?

My initial functional and non-functional requirements was in a two-column table and looked something like this:

  • FN-01 The system should allow users to send private messages to each other.
  • NFN-03 The setup/configuration form should contain sensible default values for most fields.
4

6 回答 6

1

我会使用已经存在的需求编号方案，而不是创建一个新方案。我将为每个要求记录以下项目：

  1. 需求状态：这可以用许多不同的方式表达，但是如果需求已按所列完成、以所列内容的修改变体完成或根本无法完成，您会很想交流。
  2. 需求注释：描述之前列出的需求状态。这就是“为什么”，将解释那些不能完全满足要求的项目。
  3. 完成日期：这主要用于未来的产品规划，也可作为历史参考服务器。

还有几点要记住：

  1. 需求可能会被客户审查，尤其是当客户是需求的来源时。因此，该文件需要尽可能准确和信息丰富。（这也是您不更改需求编号方案的另一个原因，除非您必须这样做。）
  2. 您的测试部门（假设您有一个）应该使用这些文档进行测试计划，他们需要知道满足了哪些要求，哪些没有满足，最重要的是哪些更改以及如何更改。

最后，除非您要为某人展示狗和小马表演，否则您不需要将屏幕截图作为需求文档的一部分。您也不需要提供完成的“证明”。测试部门会为你做这件事。

于 2009-06-03T03:49:41.413 回答
1

有一些技术可以将您的需求转换为测试用例。但这些取决于您的要求是如何记录的。如果您已经进行了基于场景的需求分析，那么这将非常容易：只需为场景的每个路径创建一个序列图，编写/执行测试 -> 完成。除了以这种方式创建的文档外，还应该给您的讲师留下深刻印象。

如果你没有场景，你应该从你的用例中创建一些。

这里的缺点是它的工作量很大，并且只应在证明其使用合理性的情况下使用（例如论文；））

于 2009-11-09T17:38:20.553 回答
0

验证需求的正式方法是测试——通常是验收测试。

这个想法是：对于每个需求，都应该有一个或多个测试来验证需求。在正式的开发情况下，客户将在他们签署需求的同时签署验收测试。

然后，当产品完成后，您将展示验收测试的结果，客户在接受最终产品之前对其进行审核。

如果您有无法测试的需求，那么它们可能写得不好。

例如，不要说“加载文件应该很快”，说“在 Z 的硬件上加载大小为 X 的文件不超过 Y 毫秒”或类似的东西。

于 2009-06-03T23:02:54.983 回答
0

我们通常会制定一个测试计划，如果满意，可以在其中勾选每个项目。该计划将基于原始需求（功能性或非功能性），例如：

要求：使用错误密码尝试登录 3 次后，用户帐户应被锁定。

测试：尝试使用错误密码登录 3 次以上。用户帐户现在是否被锁定？

我们将针对每个需求执行此操作，并为每个候选发布者重新运行计划。一些测试是自动化的，但我们确实有一个豪华的测试团队来执行手动测试！

根据运行这些测试计划和用户验收测试的结果，我们将签署 RC 为正确且适合发布。

请注意，有时即使测试计划中的某些项目没有通过，我们也会签收发布，这完全取决于项目的性质！

于 2009-06-03T18:20:24.443 回答
0

逐一列出带有需求行的需求编号，然后是证明它这样做的文本和/或屏幕截图。

将左侧的需求编号以粗体显示，然后将需求文本标记为斜体。将证明文本/屏幕截图与要求文本对齐，将左列留空，仅显示要求编号。例如：

REQ-1      italicized requirement text

           text discussing how the software has
           fulfilled the requirements, possibly
           with a picture:

           -----------------------
           |                     |
           |                     |
           |                     |
           |                     |
           |                     |
           -----------------------

REQ-2      italicized requirement text

           etc...

您应该根据逻辑程序区域分组为章节或章节，并以关于整个程序区域如何满足要求的简介开始章节或章节（一般

于 2009-06-01T02:43:11.083 回答
0

我会保持简单并添加以下列：

  • 交付满足要求 - 带有包含是、否、打开的下拉列表
  • 评论 - 关于传递的任何评论，例如“需要定义消息大小”、“不完全满足消息的布局，但被客户接受”等。
  • 完成日期 - 交付更改的时间
  • 满意日期 - 接受更改的时间

通过使用需求 ID，我假设它们指向包含更详细信息的文档，包括布局、屏幕截图等。

于 2009-06-02T15:31:30.753 回答