需求验证 需求评审.pptVIP

* 5. 需求审查清单 为了使审查员警惕他们所审查的产品中的习惯性错误，对你的公司所创建的每一类型的需求文档建立一份清单。这些清单可以提醒审查员以前经常发生的需求问题。 研究结果表明： 赋予审查员特定的查错责任，向他们提供结构化思维过程或情节以帮助他们寻找特定类型的错误，这比仅仅向审查员发放一份清单所产生的效果要好得多。 * 软件需求规格说明的审查清单 组织和完整性： ? 所有对其它需求的内部交叉引用是否正确？ ? 所有需求的编写在细节上是否都一致或者合适？ ? 需求是否能为设计提供足够的基础？ ? 是否包括了每个需求的实现优先级？ ? 是否定义了所有外部硬件、软件和通信接口？ ? 是否定义了功能需求内在的算法？ ? 软件需求规格说明中是否包括了所有客户代表或系统的需求？ ? 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。 ? 是否记录了所有可能的错误条件所产生的系统行为？ * 正确性 ? 是否有需求与其它需求相冲突或重复？ ? 是否简明、简洁、无二义性地表达每个需求的？ ? 是否每个需求都能通过测试、演示、审查得以验证或分析？ ? 是否每个需求都在项目的范围内？ ? 是否每个需求都没有内容上和语法上的错误？ ? 在现有的资源限制内，是否能实现所有的需求？ ? 是否任一个特定的错误信息都具有唯一性和明确的意义？ * 可行性： 需求定义是否使软件的设计、实现、操作和维护都可行？ 所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？ 是否能够达到关于质量的要求？ * 易修改性： 对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？ 是否有冗余的信息？是否一个需求被定义多次？ * 健壮性： 是否有容错的需求？ * 易理解性： 是否每一个需求都只有一种解释？ 功能性需求是不是以模块方式描述的，是否明确地标识出其功能？ 是否使用了形式化或半形式化的语言？ 语言是否有歧义性？ 需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？ 需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？ 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来? * 易测试性和可验证性： 需求是否可以验证？ 是否对每一个需求都指定了验证过程？ 数学函数的定义是否使用了精确定义的语法和语法符号？ * 兼容性： 界面需求是否使软硬件系统具有兼容性？ * 完备性： 需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？ 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？ 功能性需求是否覆盖了所有非正常情况的处理？ 是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？ 是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？ 是否识别定义了在将来可能会变化的需求？ 是否定义了系统的所有输入？ 是否标识清楚了系统输入的来源？ 是否识别了系统的输出？ 是否说明了系统输入、输出的类型？ 是否说明了系统输入、输出的值域、单位、格式等？ 是否说明了如何进行系统输入的合法性检查？ 是否定义了系统输入、输出的精度？ 在不同负载情况下，系统的生产率如何？ 在不同的情况下，系统的响应时间如何？ 系统对软件、硬件或电源故障必须作什么样的反应？ 是否充分定义了关于人机界面的需求？ * 一致性： 各个需求之间是否一致？是否有冲突和矛盾 所规定的模型、算法和数值方法是否相容？ 是否使用了标准术语和定义形式？ 需求是否与其软硬件操作环境相容？ 是否说明了软件对其系统和环境的影响？ 是否说明了环境对软件的影响？ * 质量属性 ? 是否合理地确定了性能目标？ ? 是否合理地确定了安全与保密方面的考虑？ ? 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？ * 可跟踪性 ? 是否每个需求都具有唯一性并且可以正确地识别它？ ? 是否可以根据高层需求（如系统需求或使用实例）跟踪到软件功能需求？ * 特殊的问题 ? 是否所有的需求都是名副其实的需求而不是设计或实现方案？ ? 是否确定了对时间要求很高的功能并且定义了它们的时间标准？ ? 是否已经明确地阐述了国际化问题？ * 使用实例文档审查清单 ? 使用实例是否是独立的分散任务？ ? 使用实例的目标或价值度量是否明确？ ? 使用实例给操作者带来的益处是否明确？ ? 使用实例是否处于抽象级别上，而不具有详细的情节？ ? 使用实例中是否不包含设计和实现的细节？ ? 是否记录了所有可能的可选过程？ ? 是否记录了所有可能的例外条件？ ? 是否存在一些普通的动作序列可