核对表:软件需求规范
此核对表有助于确保“软件需求规范”是正确且完整的。
关系
主要描述

请参考:[IE830]



检查项
应指出实施中的功能、外部接口、性能、属性和设计约束
功能:软件要做什么?
 
外部接口:软件如何与人员、系统的硬件、其他硬件和其他软件交互?
 
性能:各种软件功能的速度、可用性、响应时间、恢复时间等性能如何?
 
属性:要考虑可移植性、正确性、可维护性、安全性等方面的哪些事项?
 
对实施的设计约束:有没有必需的有效标准、实施语言、数据库完整性的策略、资源限制、操作环境等等?
有没有指定任何 SRS 范围外的需求
这意味着 SRS:
  • 应该正确地定义所有的软件需求,
  • 不应该描述任何设计或实施细节,
  • 不应该对软件施加更多的约束。
SRS 未指定特定的设计就恰当限定了有效设计的范围吗
SRS 显示出基本特征了吗
正确:SRS 陈述的每个需求都是软件应该满足的吗?无歧义
每个需求有且仅有一种解释吗?使用了客户的语言吗?用图来补充自然语言的说明吗?
完整
SRS 包含了所有重要需求(不管是与功能、性能设计约束、属性还是外部接口相关)吗?已经确定并指出了所有可能场景中的输入值的预期范围吗?有效和无效输入值都包含了响应吗? 所有的数字、表和图都包含了所有术语和计量单位的完整标签、引用和定义吗?已经解决或指出了所有待定项吗?
一致
该 SRS 与“远景”文档、用例模型和补充规范一致吗?它与任何其他较高级别的规范一致吗?它是内部一致的吗?其中描述的单个需求的子集都不冲突吗?
划分需求等级的能力
每个需求都用标识进行标记以指明该特定需求的重要性或稳定性吗?已经确定了用于正确确定优先级的其他重要属性吗?
可验证
SRS 中陈述的每个需求都可以验证吗?是否存在有限的成本有效的流程,人员或机器可以用它检查软件产品是否满足需求?
可修改
SRS 的结构和样式是不是能够简单、完整并一致地对需求作出变更,同时保持结构和样式不变?是否已经确定了冗余、将其减到最少并进行了交叉引用?
可跟踪
每个需求都有明确的标识吗?每个需求的来源清楚吗?向后可跟踪性是通过显式地引用较早的工件来维护的吗?对 SRS 派生的工件维护了合理量的向前可跟踪性吗?