读《软件需求最佳实践》YOUGAN

这几天在看《软件需求最佳实践》作者徐锋老师的软件需求培训，三天的课程，虽然原来对需求也关注了很多，自己也做过需求分析和开发的工作，但是这次培训感觉收获还是很多。三天的培训先做个记录，后续多个点还可以逐个展开，不断的总结。

需求实践所面临的问题

需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。

需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。

需求无法实现也可能不是架构问题，而是需求本身不切实际。

用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。

需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量)

沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。

需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。

变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。

非功能性需求为有效的识别，仅仅是定性，而没有通过定性->场景->定量的路线。

需求分析的核心线索

在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。

• 业务需求 = 目标 + 范围
• 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-》影响谁-》后果是什么-》解决方案优点是什么？
• 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。

需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。

需求捕获

需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。

未知问题->已知问题

相对重要->相当次要(创造一种比较的环境给用户)

关注点的转换->(沟通也要洞察心理学)

隐喻(将了一个用汉字的赢字来表达项目管理核心)

探求本源(问题背后的问题，引入了《你的灯亮着吗》，讲到了没有荒唐需求，只有荒唐的解决方案)
需求访谈是捕获中的一个重要内容，这里做一个概括总结：

首先要搞清楚你访问的用户本身的角色和特点，前期要收集足够的资料，然后制定针对性问题。

应该是先访谈有了初步的聚焦后，再进行调查。

访谈的用户分类包括(用户特点，功能/流程，数据，非功能性和接口)