软件需求讲义-第四部分讲述.ppt

评审流程 评审流程是一个重复进行的循环过程：评审员提出问题—〉讨论问题—〉对问题进行确认 —〉确定缺陷（确定需要解决的地方），直到没有确定的问题时再继续下一步 。 RUP强调确保质量的主要因素：同事检查。 需求评审中常见的问题 需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚。 没有作好前期准备工作，需求评审的效率很低。 需求评审的节奏无法控制。 找不到合格的评审员，与会的评审员无法提出深入的问题。 需求评审技术细节上的常见错误 根本不进行需求评审，而是让程序员随心所欲地写程序 。 用例不能符合所需的系统行为 。 不使用任何GUI原型来帮助验证系统行为 。 用例高度抽象，让不懂技术的客户如坠迷雾中。 概念模型不能准确地反映真实世界的概念性对象 。 用例建模没有参考概念模型 。 对不包含任何分支流程的用例不提出疑义 。 分层次评审 用户需求分为： 目标性需求，系统目标 功能性需求，系统任务 操作性需求，人机交互 正式结合非正式评审 分阶段评审 充分利用需求评审检查单，如下表软件质量因素。 如何做好需求评审 软件需求 太原理工大学软件学院 2015? 对需求定义进行静态测试的对照条例 兼容性： 界面需求是否使软硬件系统具有兼容性？ 完备性： 需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？ 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？ 功能性需求是否覆盖了所有非正常情况的处理？ 是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？ 是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？ 是否识别定义了在将来可能会变化的需求？ 是否定义了系统的所有输入？ 是否标识清楚了系统输入的来源？ 是否识别了系统的输出？ 是否说明了系统输入、输出的类型？ 是否说明了系统输入、输出的值域、单位、格式等？ 是否说明了如何进行系统输入的合法性检查？ 是否定义了系统输入、输出的精度？ 在不同负载情况下，系统的生产率如何？ 在不同的情况下，系统的响应时间如何？ 系统对软件、硬件或电源故障必须作什么样的反应？ 是否充分定义了关于人机界面的需求？ 一致性： 各个需求之间是否一致？是否有冲突和矛盾？ 所规定的模型、算法和数值方法是否相容？ 是否使用了标准术语和定义形式？ 需求是否与其软硬件操作环境相容？ 是否说明了软件对其系统和环境的影响？ 是否说明了环境对软件的影响？ 正确性： 需求定义是否满足标准的要求？ 算法和规则是否有科技文献或其它文献作为基础？ 有哪些证据说明用户提供的规则或规定是正确的？ 是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？ 是否参照了有关标准？ 是否对每个需求都给出了理由？理由是否充分？ 对设计和实现的限制是否都有论证？ 可行性： 需求定义是否使软件的设计、实现、操作和维护都可行？ 所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？ 是否能够达到关于质量的要求？ 易修改性： 对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？ 是否有冗余的信息？是否一个需求被定义多次？ 健壮性： 是否有容错的需求？ 易理解性： 是否每一个需求都只有一种解释？ 功能性需求是不是以模块方式描述的，是否明确地标识出其功能？ 是否使用了形式化或半形式化的语言？ 语言是否有歧义性？ 需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？ 需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？ 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来? 易测试性和可验证性： 需求是否可以验证？ 是否对每一个需求都指定了验证过程？ 数学函数的定义是否使用了精确定义的语法和语法符号？ 评审速度与发现的错误数量之间的关系 需求评审的困难 评审一份几百页的软件需求规格说明会使人产生厌烦情绪 庞大的评审小组将导致难于安排会议，并且在评审会上经常引发题外话，在许多问题上也难于达成一致意见 评审员可能分布在不同的地域上 测试需求 以功能需求为基础或者从用例派生出来的测试用例可以使项目参与者更清楚地了解系统的行为 。 在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。 在开发过程的早期阶段，可以从用例中获得概念上的功能测试用例。然后，你就可以利用测试用例来验证需求规格说明和分析模型并评价原型。这些基于模仿使用的测试用例可以作为客户验收测试的基础。在正式的系统测试中，可以把它们详