软件工程 |良好 SRS 的质量特征

相关文章：为您的项目编写好的 SRS

以下是一份好的 SRS 文档的特征：

1. 正确性：
   用户审查用于确保 SRS 中所述要求的正确性。如果 SRS 涵盖了系统实际预期的所有要求，则认为 SRS 是正确的。

2. 完整性：
   SRS的完整性表示每一个完成感，包括所有页面的编号，尽可能多地解决待确定的部分，以及正确覆盖所有功能和非功能需求。

3. 一致性：
   如果任何一组需求之间没有冲突，则称 SRS 中的需求是一致的。冲突的例子包括在不同地方使用的术语的差异，逻辑冲突，如报告生成的时间段等。

4. 明确性：
   如果陈述的所有要求只有一种解释，则称 SRS 是明确的。防止歧义的一些方法包括使用建模技术，如 ER 图、适当的审查和伙伴检查等。

5. 重要性和稳定性排名：
   应该有一个标准来将需求分类为较不重要或更重要或更具体地为可取或必要。识别标记可与每项要求一起使用，以表明其等级或稳定性。

6. 可修改性：
   SRS 应该尽可能地可修改，并且应该能够在某种程度上轻松地接受系统的更改。修改应正确索引和交叉引用。

7. 可验证性：
   如果存在一种特定技术来量化测量系统满足每个要求的程度，则 SRS 是可验证的。例如，系统必须对用户友好的要求是不可验证的，因此应避免列出此类要求。

8. 可追溯性：
   应该能够跟踪设计组件的需求，然后跟踪程序中的代码段。同样，应该能够将需求跟踪到相应的测试用例。

9. 设计独立性：
   应该有一个选项可以从最终系统的多种设计方案中进行选择。更具体地说，SRS 不应包含任何实现细节。

10. 可测试性：
    SRS 的编写方式应易于从文档中生成测试用例和测试计划。

11. 客户可以理解：
    最终用户可能是他/她特定领域的专家，但可能不是计算机科学专家。因此，应尽可能避免使用正式的符号和符号。语言应保持简单明了。

12. 正确的抽象级别：
    如果 SRS 是为需求阶段编写的，则应明确说明细节。然而，对于可行性研究，可以使用的细节较少。因此，抽象级别根据 SRS 的目的而有所不同。