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

请参考:[IE830]



Rational Unified Process   2003.06.15