1、意义

  • 对软件需求进行正确性的检查。
  • 保证软件需求的可测试性。
  • 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家认识一致，避免在后期产生不同的理解，引起争吵。
  • 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求
  • 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更， 但可以得到有效的控制，这样可降低测试的风险。

  • 评审是否完成是以需求文档获得多方”邮件确认”或”签字”通过为标志的。这不 应该只体现在”签字”形式上，更重要的是达到下面的结果。

    • 所有参与方达成一致。
    • 已发现的问题被阐述清楚、被修正。

      2、需求评审的质量要求

  • 正确性

  • 完备性
  • 易理解性
  • 一致性
  • 可行性
  • 易修改性
  • 可测试性

  • 可追溯性

    3、需求评审的参加人员

  • 用户代表

  • 需求人员
  • 产品经理
  • 项目经理
  • 开发人员
  • 开发经理
  • 测试人员
  • 测试经理
  • 市场经理

  • 质量保证人员

    4、测试人员参与评审时的注意事项

  • 明确自己的角色和责任。

  • 熟悉评审内容，为评审做好准备，做细做到位。
  • 在评审会上，针对问题阐述观点，而不是针对个人。
  • 可以分别讨论主要的问题和次要的问题。
  • 在会议前或会议后可以就存在的问题提出自己建设性的意见。
  • 提高自己的沟通能力，采取适当的、灵活的表述方式。
  • 对发现的问题跟踪下去。
  • 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。
  • 测试人员要善于提问，多思考
    • 这些需求都是用户提出来的吗？
    • 有没有画蛇添足的需求？没有漏掉什么需求吗？
    • 和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
    • 是否正确地描述了每个需求？这条描述是否存在二义性的问题？
    • 我的理解和文档作者的理解一致吗？

问题：

需求评审的时候，评审哪些内容

  • 1、找出需求中描述不清楚的地方？
  • 2、分析需求的可行性
    • 是否涉及法律、安全等问题
    • 现有技术是否能实现
    • 考虑系统的可测性
  • 3、分析需求中是否有漏洞
    • 功能、操作缺失
    • 流程是否完整
    • 考虑需求实现是否合理