软件需求最佳实践.doc

软件需求最佳实践 这几天在听《软件需求最佳实践》作者徐锋老师的软件需求培训，三天的课程，虽然原来对需求也关注了很多，自己也做过需求分析和开发的工作，但是这次培训感觉收获还是很多。三天的培训先做个记录，后续多个点还可以逐个展开，不断的总结。 需求实践所面临的问题 需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了 需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。 需求无法实现也可能不是架构问题，而是需求本身不切实际。 用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。 需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法 (离主营业务的远近，发生的频率两个方面来度量 ) 沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通 失真。 需求捕获和调研常见问题 -用户告诉你的是他转化后的解决方案，而不是最原始的需求。 变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。 非功能性需求为有效的识别，仅仅是定性，而没有通过定性->场景 ->定量的路线。 需求分析的核心线索 在原有的需求分析方法中，我们往往过多的关注 How，而没有关注 What，或者关注了 What 而没有关注 What背后的需求场景和背后的问题 Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个 层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。 业务需求 =目标 +范围 目标的表达必须包括目标 +优势 +度量 +合理 +可行，或者说SMART 原则。同时在目标表达上可以考虑场景法，即问题是什么 -》影响谁 -》后果是什么 -》解决方案优点是什么？范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。 需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作