《软件需求最佳实践.docxVIP

软件需求最佳实践?2009-04-03 作者：人月神话 来源：人月神话的BLOG ?需求实践所面临的问题需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。 需求无法实现也可能不是架构问题，而是需求本身不切实际。 用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。 需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量) 沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。 需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。 变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。 非功能性需求为有效的识别，仅仅是定性，而没有通过定性-场景-定量的路线。 需求分析的核心线索在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。业务需求=目标+范围 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-》影响谁-》后果是什么-》解决方案优点是什么？ 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。 需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。需求捕获需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。未知问题-已知问题 相对重要-相当次要(创造一种比较的环境给用户) 关注点的转换-(沟通也要洞察心理学) 隐喻(将了一个用汉字的赢字来表达项目管理核心) 探求本源(问题背后的问题，引入了《你的灯亮着吗》，讲到了没有荒唐需求，只有荒唐的解决方案)需求访谈是捕获中的一个重要内容，这里做一个概括总结：首先要搞清楚你访问的用户本身的角色和特点，前期要收集足够的资料，然后制定针对性问题。 应该是先访谈有了初步的聚焦后，再进行调查。 访谈的用户分类包括(用户特点，功能/流程，数据，非功能性和接口) 调查问卷设计诸多讲究，如避免简单的排序题，调查问卷中的C现象和D现象等，不展开。 需求规格说明书业界关注需求有很多标准，如GB2006等，但是关于功能性需求方面都不能再细化展开，因此标准仅仅是一个展开。各个行业或组织还需要根据自身软件项目特点对模板进行补充和完善。需求分析过程应该是一个业务流程驱动的至上而下的过程。开始不应该一下转入到一个具体的功能细节，而是应该先规划目录和打提纲，然后以流程为主线逐层分解和展开。在需求描述上可以是文字，也可以是图形化的，也可以是一种形式化规格表达。需求规格说明书模板的内容也可以逆向思维，如设计需求我们提供什么样的需求对他们才是最有参考意义的。我们的需求调研不应该是通过模板格式来决定内容，再决定沟通。而是应该根据需要的沟通来决定内容，根据内容来决定我们需要什么样的需求模板和格式。 需求验证是一种质量活动，在这里要注意验证和确认的区别，一般验证活动主要方式就是Reivew，而Reivew根据正式程度又包括了审查，多人复审，单人复审等多种方式。需求验证的五大要素包括： 思想：找到尽可能多的错误 方法：从非正式的开始，并逐渐形成文化 语言：从评价者转化为建议者，强调协作者进来减少用你哪里错了，而多用我建议如何 人员：平等而且合适，减少不相关人员的参与 内容：不是全部而是最合适 需求管理的三大内容是基线，变更和状态跟踪。其实基线和变更都属于配置