软件需求规范 (SRS) 文档清单

SRS 文档由测试人员或一组人员使用任何验证方法（如同行评审、演练、检查等）进行评审。由于检查的有效性和产生良好结果的能力，我们可能会使用检查。我们可能会进行两次甚至更频繁的审核。每次审查都会提高文档的质量，但可能会消耗资源并增加软件开发的成本。清单是一种流行的验证工具，由可交付成果应包含的关键信息内容列表组成。检查表还可以查找重复信息、缺失信息、不清楚的信息、错误信息等。检查表在审查过程中使用，可以使审查更有条理和更有效。

SRS 文件清单应解决以下问题：

1. 正确性：
   在 SRS 文档中，每个 文档中陈述的要求应该正确地代表对提议软件的期望。必须确定所有适用的安全和安保要求。此外，每个需求的所有输入和输出对于指定的处理都是必需的并且是足够的。例如，如果客户要求软件在 2 秒内响应所有按钮按下，但 SRS 声明“软件应在 20 秒内响应所有按钮按下”，那么这将在文档。
   
2. 歧义：
   SRS 文档可能在软件要求中包含一些含糊不清的地方。例如，如果一个需求传达了一个事物的多个含义，那么这将是一个严重的问题，因此，为了避免这种歧义，每个需求都必须只有一个含义。因此，软件需求陈述应该简短、正确、准确和清晰。 SRS 文档清单必须关注模棱两可的词以避免模棱两可。
   
3. 完整性：
   SRS 文档应该在各个方面都完整，例如它必须具有所有重要的功能要求（如硬件故障、I/O 错误、计算错误、处理过载、缓冲区溢出、事件未能发生等）和所需的非功能要求对于软件，必须通过检查表彻底检查 SRS 文档的完整性。
   
4. 一致性 ：
   在 SRS 文档中，如果所有陈述的要求与其他陈述的要求没有差异，则可以保持文件的一致性。每个对象都有一个唯一的名称，并由一组互不冲突的特征定义。此外，如果数学方程、首字母缩略词和缩略语的定义和使用一致，那么文档将是一致的。清单必须突出与不一致相关的问题，并且应该旨在发现不一致。
   
5. 可验证性：
   在 SRS 文档中，当且仅当文档中陈述的每个要求都是可验证的时，才说它是可验证的。不可验证的要求包括“良好的接口”、“出色的响应时间”、“通常”、“良好”等陈述，不应使用。应使用“shall”、“will”、“may”等需求术语。在文档中，我们应该只使用可衡量的术语，并且必须避免所有不定术语。
   
6. 可追溯性：
   如果每个需求的来源都被正确定义，那么 SRS 文档是可追溯的，因为它可能有助于未来的开发。可追溯性可能有助于构建文档，并且应该在清单的设计中占有一席之地。
   
7. 可行性：
   在 SRS 文件中，由于技术原因或缺乏资源，某些要求可能无法实施，因此，应确定这些要求并相应地从 SRS 文件中删除。文档清单还可以帮助我们在软件中找到其他一些不可行的要求。例如，来自外部源的预期数据必须存在于定义的源中，或者发送到外部目的地的数据预期在这些目的地，否则，要求可能无法实现。