需求评审基本方法.doc

_基本评审方法作者：俎涛, .nc授人以鱼，不如授人以渔！ 交给知识不如交给学习的方法。基本评审方法路线首先进行内容评审l 用4W+H评审l 用目标评审l 关联评审l 乐观评审l 悲观评审然后才是形式评审l 目标评审l 关联评审l 乐观评审l 悲观评审情绪：乐观，悲观焦点：目标，关联方向：内容，形式行动路线：4W+H4W+H评审方法4W+H = Who How do What When Why 4W+H就是：什么人，什么时候，做什么，怎么做，为什么可以用于很多分析，例如需求分析，软件分析、设计，也可以用于评审1. Who 应该谁（系统单元）负责？2. What 应该作什么？3. How 应该如何做？4. When 应该什么时候做？5. Why 为什么？举例：Who ：Ping 应该谁负责？PingsWhat：应该做什么？协议数据报，通信How：应该如何做？处理流程When：启动定时，10000msWhy：要判断IP地址的连接情况目标评审方法要求是什么？符合要求么？应该如何改进？业务是什么？目标实现了吗？应该如何改进？可读性好么？应该如何改进？存在规范么？遵循规范了吗？应该如何改进？关联评审影响的因素都有哪些？都有哪些影响？有哪些相关的因素？乐观式评审这样的好处是？这样可以解决什么问题？这样可以得到什么？这样可以避免什么？悲观式评审还有什么不足么？还漏掉了什么吗？这样真的可以么？不会有什么错误吧？还有更好方法吗？这样足够好了吗？内容评审确定内容的范围评审内容范围内容实现了预期目标吗？内容是可行的吗？内容是正确的吗？内容是一致的么？形式评审形式符合标准么形式是否可读性好形式是否结构合理形式是否简洁通过需求评审验证需求确定需求检查点：1. 内容检查点2. 格式检查点根据检查点对需求进行检查记录评审评审结果分析需求评价需求文档相关因素详细设计文档设计者需求人员程序员QA项目经理项目开发计划Code规程UnitTest需求文档Tester客户/用户评审需求文档的不同目的1. 项目经理：是否按照符合项目的整体目标2. 设计者：是否为设计提供了必要的支持和约束3. 客户：是否支持关键的产品特性，保证产品的市场定位4. 用户：是否具有良好的操作性和可用性5. 测试人员：是否能够为测试计划和设计提供必要的支持和约束6. QA:工作是否按照软件质量规程进行评审方式1. 阅读理解式2. 场景验证：于关注的需求，选择一个具体的应用场景，采用CRC结合场景检查详细需求的质量3. CheckList：根据经验，采用提问的方式，把检查点设置为相关的问题，4. 评标式：由编写人讲解，评审者评议评审焦点 需求的质量4 正确性4 完整性4 一致性4 可行性 文档本身的质量4 结构清晰4 可读性好4 无二义性评审的形式 同行评审 下家评审 上家评审 领导评审 客户评审评审参与的人员客户，用户代表设计人员开发人员项目经理测试人员质量人员评审的时机需求完成后，保证质量设计和编码开始前，确认需求系统测试计划和测试设计前，了解需求如果做好评审 首先应该明确评审的目的 其次要明确评审的关注点 确定评审的标准 采用和评审目标、环境适应的评审方式 做好评审的记录 及时根据评审情