软件需求最佳实践SERU过程框架总结.docx

SERU过程框架总结这是参加徐锋的软件需求最佳实践课程培训后的再一次总结，笔者在提出SERU过程框架的时候常说到一个观点，就是我们并不缺乏软件工程，需求工程的理论，技术，缺乏的是将这些理论和技术有效的应用到实践。而作者的SERU过程框架正好是将软件工程理论和具体的需求实践工作真正的结合起来了，个人认为最核心的不是提出了很多重要的需求诫语，更重要的是可以通过SERU框架系统来梳理和回顾我们的需求开发和需求管理活动。首先对SERU模型的四个字母再做一个说明S:Subject Area，表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。E:Event，表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。R:Report，表示报表，统一处理查询，分析和统计类需求。U:Use Case，表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。SERU过程框架模型将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。第一阶段-需求定义阶段需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。同时也提出了类似任务卡片等很好的现场需求捕获工具。为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。主题域划分+上下文图，是需求定义阶段的重要输出。主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。主题域划分清楚了下一步重点就是要确定主题域的范围，自然引入了上下文关系图，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互。通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。在这里我觉得重点要借鉴的就是从顶向下的系统思维和分而治之，这是解决问题很重要方法。同时刚开始一定不要跳过这个阶段而落入需求细节。主题域和业务事件是两个重要概念，而这两个概念核心又是业务场景。第二阶段-需求分析阶段在第二个阶段重点就是粒度的细化，从主题域我需要细化一层到识别了关键业务对象的领域视图，从业务事件进行流程分析我们需要讲业务事件细化一层到具体的业务活动，而业务活动正式我们在识别用例的时候的重要参考。所以在这里我们基本清楚了第二阶段刚开始是通过业务事件进行业务流程分析，业务实体分析，业务场景分析，识别领域类和用例。需求分析就是先分解，在提炼，然后在这个过程中消除矛盾。不管是采用结构化的方法还是面向对象的方法，分解是人类控制复杂性，认知复杂事物的最佳实践。现代工程理论更建议采用业务导向的分解而非系统导向的分解。在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-主题域-业务事件；到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-业务流程和业务活动-领域类图和用例。业务流程是对信息系统进行庖丁解牛的核心线索，每个业务事件都是一个业务流程的触发，因此针对每个业务事件都应继续做业务流程分析。对于业务流程是企业核心业务的重要载体，业务流程本身就是结构化的，而且是分级的，通过分析业务流程就能够识别企业核心业务活动，为需求建模做好准备工作。在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例，在RUP核心三要素中专门强调了用例驱动，足见用例建模的重要性，但是我们要注意到第二阶段的重点仍然是搭框架结构，因此并没有要求要识别所有的领域类和用例。第三阶段-需求细化需求细化是什么？在第二阶段我已经通过分解和细化到达了具体的用例，而第三阶段的重点就是单个用例以及该用例可能涉及到的界面部分建模。书中将用例分为三类是有一定道理的，即业务用例，报表用例和接口用例。对于业务用例的重点是基本流，扩展流和业务规则。对于报表类的用例重点则是报表的输入，输出内容，输出格式。在这里有个情况不得不提出的就是，一些报表类用例脱离了只要不是项目历史开发人员很难看懂，原因即是关键的报表的数据来源在哪里没有说清楚，这点也是报表类用例必须关注的要点。如果将用例分为两个层次，第一重点就是关注业务活动流和规则的细化，另外一个就是涉及到交互和界面的建模和细化。这两个层次仍然有一定的关系，重点仍然是要先考虑业务流和规则，再来考虑交互和界面。如果先陷入到了界面建模再考虑业务流和规则，则又是顺序错误的开发人员思维，即违背了用例是业务活动驱动的初衷。这里多说一句即是功能点估算在什么时候用，在第一阶段用是毫无意义的，最佳的使用点就是在需求细化后，具体的业务流和规则，需要的数据输入和输出都基本清楚后，最适合进行功能点估算。因此我们也建议一种方法，即第一阶段先进行专家法估算，到了第三阶段通过功能点估算对专家法估算内容进行验证。这几天在听软件需求最佳实践作者徐锋老师的软件需求培训，三天的课程，虽然原来对需求也关注了很多，自己也做过需求分析和开发的工作，但是这次培训感觉收获还是很多。三天的培训先做个记录，后续多个点还可以逐个展开，不断的总结。需求实践所面临的问题 需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。 需求无法实现也可能不是架构问题，而是需求本身不切实际。 用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。 需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量) 沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。 需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。 变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。 非功能性需求为有效的识别，仅仅是定性，而没有通过定性-场景-定量的路线。需求分析的核心线索在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。 业务需求 = 目标 + 范围 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-影响谁-后果是什么-解决方案优点是什么？ 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。需求捕获需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。 未知问题-已知问题 相对重要-相当次要(创造一种比较的环境给用户) 关注点的转换-(沟通也要洞察心理学) 隐喻(将了一个用汉字的赢字来表达项目管理核心)探求本源(问题背后的问题，引入了你的灯亮着吗，讲到了没有荒唐需求，只有荒唐的解决方案)需求访谈是捕获中的一个重要内容，这里做一个概括总结： 首先要搞清楚你访问的用户本身的角色和特点，前期要收集足够的资料，然后制定针对性问题。 应该是先访谈有了初步的聚焦后，再进行调查。 访谈的用户分类包括(用户特点，功能/流程，数据，非功能性和接口) 调查问卷设计诸多讲究，如避免简单的排序题，调查问卷中的C现象和D现象等，不展开。需求规格说明书业界关注需求有很多标准，如GB2006等，但是关于功能性需求方面都不能再细化展开，因此标准仅仅是一个展开。各个行业或组织还需要根据自身软件项目特点对模板进行补充和完善。需求分析过程应该是一个业务流程驱动的至上而下的过程。开始不应该一下转入到一个具体的功能细节，而是应该先规划目录和打提纲，然后以流程为主线逐层分解和展开。在需求描述上可以是文字，也可以是图形化的，也可以是一种形式化规格表达。需求规格说明书模板的内容也可以逆向思维，如设计需求我们提供什么样的需求对他们才是最有参考意义的。我们的需求调研不应该是通过模板格式来决定内容，再决定沟通。而是应该根据需要的沟通来决定内容，根据内容来决定我们需要什么样的需求模板和格式。需求实践所面临的问题 需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。 需求无法实现也可能不是架构问题，而是需求本身不切实际。 用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。 需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量) 沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。 需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。 变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。 非功能性需求为有效的识别，仅仅是定性，而没有通过定性-场景-定量的路线。需求分析的核心线索在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。 业务需求 = 目标 + 范围 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-影响谁-后果是什么-解决方案优点是什么？ 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。需求捕获需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。 未知问题-已知问题 相对重要-相当次要(创造一种比较的环境给用户) 关注点的转换-(沟通也要洞察心理学) 隐喻(将了一个用汉字的赢字来表达项目管理核心)探求本源(问题背后的问题，引入了你的灯亮着吗，讲到了没有荒唐需求，只有荒唐的解决方案)需求访谈是捕获中的一个重要内容，这里做一个概括总结： 首先要搞清楚你访问的用户本身的角色和特点，前期要收集足够的资料，然后制定针对性问题。 应该是先访谈有了初步的聚焦后，再进行调查。 访谈的用户分类包括(用户特点，功能/流程，数据，非功能性和接口) 调查问卷设计诸多讲究，如避免简单的排序题，调查问卷中的C现象和D现象等，不展开。需求规格说明书业界关注需求有很多标准，如GB2006等，但是关于功能性需求方面都不能再细化展开，因此标准仅仅是一个展开。各个行业或组织还需要根据自身软件项目特点对模板进行补充和完善。需求分析过程应该是一个业务流程驱动的至上而下的过程。开始不应该一下转入到一个具体的功能细节，而是应该先规划目录和打提纲，然后以流程为主线逐层分解和展开。在需求描述上可以是文字，也可以是图形化的，也可以是一种形式化规格表达。需求规格说明书模板的内容也可以逆向思维，如设计需求我们提供什么样的需求对他们才是最有参考意义的。我们的需求调研不应该是通过模板格式来决定内容，再决定沟通。而是应该根据需要的沟通来决定内容，根据内容来决定我们需要什么样的需求模板和格式。需求验证是一种质量活动，在这里要注意验证和确认的区别，一般验证活动主要方式就是Reivew，而Reivew根据正式程度又包括了审查，多人复审，单人复审等多种方式。需求验证的五大要素包括：思想：找到尽可能多的错误方法：从非正式的开始，并逐渐形成文化语言：从评价者转化为建议者，强调协作者进来减少用你哪里错了，而多用我建议如何人员：平等而且合适，减少不相关人员的参与内容：不是全部而是最合适需求管理的三大内容是基线，变更和状态跟踪。其实基线和变更都属于配置管理的需求跟踪。需求跟踪又包括了对需求-设计-测试整个需求链的跟踪，同时也包括了对需求实现状态的跟踪。在这个过程中基线是迭代开发的基础，但是迭代开发往往又是最难去规划和打基线的。在这里的原因是我们是以整个文档作为基线的对象，而不是以文档中的条目化需求作为基线的对象。另外对于变更管理其核心作用是通过变更管理减少变更对目标的影响。迭代开发和分阶段开发 迭代开发是以时间(迭代周期)来划分，而分阶段开发是以任务完成来划分。 迭代周期一般比较短而分阶段开发的每个阶段会比较长。 迭代不响应变更，需要变更会转入下次迭代；分阶段开发响应变更导致混乱和计划失效。在RUP的三要素中最后一个就是增量迭代，但是要注意到迭代是手段，增量是目标。而且每一个迭代其本身就是一个微型的瀑布。迭代使目标更加容易分解和明确。估算是在项目管理中做项目计划的基础，不能因为估算不准确而不去做估算和计划，坚持估算和检查估算历史数据的收集就不断的纠正估算的经验数据，而使估算准确性得到提高。同时，估算的本质是计算单元和复杂因子，首先要选择好相应的估算方法，如在需求早期往往并不适合用功能点法进行估算；其次就是要识别计算单元，然后再确定具体的复杂度。 估算是手段，估算需要在执行过程中多次调整。 估算应该是基于权重的，比如我们用的根据规模到工作量的方法，比如要考虑人员效率的影响。 在估算后可以根据关键用例来确定第一个迭代周期的长度。需求变更是无法避免的，但是我们要尽量减少和控制变更带来的影响。需求变更是需求管理的一个核心内容，有了需求变更自然会涉及到需求基线和配置管理的内容。例如我们可以讲对于已经基线的配置项要修改都必须要走变更流程等。对于需求变更主要有以下重点： 是控制变更而不是避免变更。 控制变更的目的是减少变更的影响，客户要意识到变更是有成本的。 需求团队的贡献在于尽早标识变更。 需要建立统一的平台来捕获，管理和控制变更。目标的寻找方法可以用GPOA方法：GOAL-Problem-Option-Answer。在确定项目目标和范围的时候，我们往往容易提出类似要建立一个先进的信息系统一类的不清晰的目标。而如何破解不清晰的目标？可以从两个方面来考虑:内部溯源(项目的原始发起人，沟通)；外部寻因(受到外部刺激)RUP中的问题分析五步法: 在问题的定义上达成共识，问题定义清楚往往问题就解决了一半。 要多为问题背后的问题，探求问题的本质和根源。(如鱼骨图+帕累托图)。 确定Stakeholders和用户，高层，中层和操作层各自的价值和关注点是什么？ 定义解决方案系统的范围-黑盒思维-主题域划分-主题域内的流程和请求 确定解决方案的约束对于访谈这块的案例和实战都很好，暂时不展开了，感觉还是有很多原来在访谈中没有注意的内容，特别是开门点和访谈策略两个方面。具体综述下高层访谈主要关注点:开门点：易于回答而且激发其兴趣 访谈策略：Review验证最后结果，问题不要太大，连续，挖掘不够有时候只听到一个问题 问题类型和挖掘：上下文，问题暴露后的分解，发展机会，约束 其它策略：还应该找哪些人做进一步的交流用例是一种纪录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。用例之道： 不是系统完成的动作行为，而应该是有价值的业务活动的分解。 用例是需求分析的新视角-业务视角。用例也可以是需求管理的基本单元。 用例价值的测试包括两方面，一是业务活动的原子性，一是Boss测试。 用例的粒度可能会取决于企业内业务的分工。 对于用例的CRUD原则，更加重点的标准是是否是一系列随机操作，是否由一个Actor完成。 用例需要避免功能分解，而应该是用户业务场景驱动。在用例中常用的关系是扩展(Extend)，包含(Include)和泛化。对于扩展和包含区别如下： 扩展：在某种条件是会被执行，也可能不执行。所以它有可能是一种可以划到下个迭代的。 包含：包含的是子事件流，必然会调用到，而且是调用完后还会会到基用例。对于获取用例的方法主要有两种，一种是自顶向下的流程派生法，跨职能流程图和泳道就是参与者，其中的业务活动就是用例；另外一种就是自底向上的合并法，比如可以从条目化的用户需求进行合并。在第一种方法中派生用例的时候需要注意： 去除掉非EndUser的泳道。 对泳道进行角色化的抽象。 判断活动与系统是否有关系。对于用例分析重点是事件和业务流程，而对于数据分析则重点是在业务数据上面。用例分析代替不了数据分析。数据分析常用的就是业务实体分析，通过数据分析可以建立系统的领域模型。数据分析的目标就是理解业务领域中的业务术语和实体，包括语义关系，数量关系和主要内容。数据分析的要点就是要识别出具体的业务实体，以及这些业务实体间的关系。在FDD中的领域建模是基于数据和行为的综合分析，包括Together之父PeterCoad发明的菜色建模法。他将数据类分为了行为，参与角色，人事物，通用描述四个方面的内容。在用例模板中有几个关键点，包括前置条件应该是系统必须能够检测和验证的。在用例描述中应该拒绝太多的实现细节；用例本身无法展示很多界面交互，因此需求建模还应该包括界面和交互建模的内容。而对于报表等需求往往并不太适合用例的表达方式，可以根据企业情况来确定具体的报表类需求的描述方法。在用例模板中还有干系人利益的内容，在这里特别说明的是分析干系人利益可以帮助我们挖掘潜在的需求。虽然关系人不是Action事件的之间操作者，但是干系人的利益往往会影响到用例本身的需求。