软件需求最佳实践

纯阳书评（公众号:纯阳书评／微信号:chimbusco88）信息系统项目中的坑有很多，但最要命的恐怕还是来自需求的坑，这里的坑即使不致满盘皆输，也会让项目各方伤痕累累，有惊亦有险，所以一套好的需求开发与管理方法框架对于项目成败至关重要。本书就提供了一套叫做SERU的好方法，有理论，有实践，作者自称最佳实践，似有口气过大之嫌，但读过之后，颇以为然，不但在好多点上解决了我的困惑，而且让我颇有换了一个高度看需求之感，所以我认为此书既使不是需求工程领域最好之读物，恐怕必是之一了。 第一看点就是SERU过程框架方法论。SERU是作者广收RUP、面向对象分析和结构化分析等诸方法之所长，结合自己实际应用心得的汇聚之作，强调三阶段完成需求开发。第一阶段着眼宏观，立足问题/机会，将系统划分为主题域（Subject），梳理域中事件（Event）和报表（Report）。第二阶段着眼中观，立足业务脉络，由E、流程和R导出用例（UserCase）、类图。第三阶段着眼微观，立足业务细节，完成用例与领域模型的细节填充。 整个SERU涵盖了需求定义，需求捕获，需求分析与建摸和需求验证各个阶段，囊括了需求基线，需求变更和需求追溯各个环节，结构清晰，自成体系，考虑周全，读后令人耳目一新。 第二看点是书中案例设计精当，安排颇为合理，置于紧要观点处，有极好的说明效果，常有看理论时颇无感，读罢案例，方觉观点之妙。 第三看点是作者的语言造诣。作者具有很强的概念抽象和语言组织能力，每每在大段方法阐述后会将核心意思总结为一句诫语，为观点赋上了很强的冲击力。 个人认为这是一本无论在甲方还是乙方从事信息化工作都必读的好书，不管能吸收多少，相信都会带來收获感和愉悦感！

关于软件需求设计和管理方面，很好的一本书。推荐

对软件需求工程的各环节如何开展，从方法论的角度、结合例子和亲身经历进行了完整、准确且生动的阐述，读后有拨云见日之感；总结出的SERU框架及其所包含的一系列方法、模版、戒语等，实用性很强，对于软件从业者有很好的指导作用。

涵盖了软件需求工程的各个方面，包括需求管理活动的操作要点，如需求基线、变更管理、需求跟踪等。

对瀑布流的开发更能体现本书的价值，大环境，大企业！ 书中很多东西都可以当工具使用，无妨什么开发流派！ 三人行必有我师，能学到知识，并应用就是最大的收获！ 这谢谢！

1、前面几章差点睡着了感觉内容看不懂在讲什么...中间几章内容集中强度大...然后几章轻松...最后1章总结。建议先看最后一章吧，马上就能知道讲的是什么，更容易构建大局观和整体观。 2、感觉偏传统的软件需求分析的场景，但目前是移动互联网和saas的时代，有些东西需要去思考。但是对于B端产品经理来讲还是值得钻研的，C端产品经理基本不需要看。 3、对于日常不怎么使用uml图，或者未接触过相对复杂业务的人员读起来比较费劲。 4、同现代sprint思想、lean精益思想实际上是有一点冲突的，传统软件开发周期长、任务多，而近几年sprint的思想被越来越多公司采用。 5、如何落地实践是值得考虑的一个问题，书中最后一章也提供了一个思路。 6、核心内容： SERU: subject area,event,report,use case; 主体域+事件+报表+用例； 3阶段： 明确目标和范围（开天辟地）=> 理清框架和脉络（泾渭分明）=> 填充需求细节（天圆地方）； 每个阶段的内容：包括主要任务、产物等 【1、明确目标和范围】 1.1核心工作： 划分主题域（若需要）=>用上下文图确定主题域范围=>列出主题域下的业务事件、报表类型列表 1.2主要产物： 构件图（表示主题域关系，1张）=>上下文关系图（表示主题域范围，张数与主域个数相等）=>业务事件列表、报表类型列表 1.3主要访谈对象： 中高层用户代表 1.4重要信息： 组织结构图、分管领导=>有助于划分主题域；部门职责说明=>有利于主题域间服务接口的标识 1.5其他提示： 这阶段时间相对简短，不强求标识全部业务事件和报表类型；重点在于从宏观层面理解业务，标示出最主要的业务事件和报表 【2、理清框架和脉络】 2.1核心工作： 针对业务事件进行流程、业务实体、使用场景分析； 针对每类报表进行业务实体、使用场景分析； 将前面标识出来的所有场景（用例）进行抽象、得到用例模型； 将前面业务实体分析获得的领域模型片段进行合并和抽象； 对设计约束、质量属性进行分析； 2.2主要产物： 活动图（表示业务流程）； 领域类图片段（表示每个业务流程、报表类型涉及的业务实体） 用例模型片段（表示每个业务流程中的业务活动、具体报表项） 领域模型（按主题域对领域类图片段进行合并和抽象） 用例模型（按主题域对用例模型片段进行合并和抽象） 部署图（用来描述软硬件环境方面的设计约束） 2.3主要对象： 中层用户代表 2.4重要信息： 业务事件、报表类型列表作为访谈计划的线索； 业务事件、报表类型列表作为需求组织的二级目录 2.5其他提示： 此阶段主要是搭建框架，不要设计太深的内容；目标不在于标识所有用例、所有领域类，而是标志出最重要的部分，此外，在本阶段完成后将对需求进行基线划分。 【3、填充需求细节阶段】 3.1核心工作 针对每个用例（B类、R类、I类）进行捕获、分析； 对流程图上标志的相关文档进行分析，完成领域类的细节填充； 在架构师的支持下，完成技术类用例的描述； 3.2主要产物 业务类用例描述：包括事件流、相关需求、UI原型、规则约束； 报表类用例描述：包括报表概述、报表内容、输入/输出格式; 接口类用例描述：包括使用者概述、内容与格式、实现约束； 领域类描述：包括数据窗口分析、组成与格式、计算规则； 3.3主要访谈对象 操作层（及小部分中层）用户代表 3.4重要信息： 根据上阶段得出的用例模型，按基线安排调研与细化； 根据用例所关联的领域类，安排领域类的分析和细化；

1.需求的定义～理论。 2.需求的铺货～访谈用户：分类访谈，访谈事项，访谈细节，访谈总结～一定要和用户确认是否是这样。 需求分析～业务分析，不仅仅分析逻辑更要注意业务中是否存在问题，发现问题才是分析的本质。 3.需求描述～需求文档，需求建模～需求文档要针对阅读对象，使用对象分类业务描述，需求建模设计不要复杂，建模是为了更好的与用户，与开发沟通，所以实用，易懂，很重要。 4.需求评审～有效，不要形式化的评审需求，评审和分析一样，都要重在把业务中问题找出，而不是评审通不通过。评审前注意会议安排(必要人员参加，会前一定要把需求提前发给参会人员，评审时间把握在40分钟次，评审可以分多次但不能形式) 5.需求变更～变更分析，分析变更影响范围。 6.需求管理～易追踪，易维护，易查阅

我们并不缺乏软件工程，需求工程的理论，技术，缺乏的是将这些理论和技术有效的应用到实践。 作者的SERU过程框架正好是将软件工程理论和具体的需求实践工作真正的结合起来了。 最核心的不是提出了很多重要的需求诫语，重要的是可以通过SERU框架系统来梳理和回顾我们的需求开发和需求管理活动。 SERU模型 S:Subject Area，表示子问题域 其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。 E:Event，表示业务事件 通过业务事件能够找到流程，通过流程能够找到不同场景和用例。 R:Report，表示报表 统一处理查询，分析和统计类需求。 U:Use Case表示用例 需求组织的最小单位，到了需求分析阶段的重要活动和产出。 SERU过程框架模型将需求过程分解为了三个阶段， 第一个阶段是需求定义，重点是主题域划分和业务事件识别。 第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。 到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。 第一阶段-需求定义阶段 需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。 当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。 同时也提出了类似任务卡片等很好的现场需求捕获工具。为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。 主题域划分+上下文图，是需求定义阶段的重要输出。 主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。 主题域划分清楚了下一步重点就是要确定主题域的范围，自然引入了上下文关系图，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互。通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。 在这里我觉得重点要借鉴的就是从顶向下的系统思维和分而治之，这是解决问题很重要方法。 同时刚开始一定不要跳过这个阶段而落入需求细节。 主题域和业务事件是两个重要概念，而这两个概念核心又是业务场景。 第二阶段-需求分析阶段 在第二个阶段重点就是粒度的细化，从主题域我需要细化一层到识别了关键业务对象的领域视图，从业务事件进行流程分析我们需要讲业务事件细化一层到具体的业务活动，而业务活动正式我们在识别用例的时候的重要参考。所以在这里我们基本清楚了第二阶段刚开始是通过业务事件进行业务流程分析，业务实体分析，业务场景分析，识别领域类和用例。 需求分析就是先分解，在提炼，然后在这个过程中消除矛盾。 不管是采用结构化的方法还是面向对象的方法，分解是人类控制复杂性，认知复杂事物的最佳实践。 现代工程理论更建议采用业务导向的分解而非系统导向的分解。 在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-》主题域-》业务事件；到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-》业务流程和业务活动-》领域类图和用例。 业务流程是对信息系统进行庖丁解牛的核心线索，每个业务事件都是一个业务流程的触发，因此针对每个业务事件都应继续做业务流程分析。 对于业务流程是企业核心业务的重要载体，业务流程本身就是结构化的，而且是分级的，通过分析业务流程就能够识别企业核心业务活动，为需求建模做好准备工作。 在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例，在RUP核心三要素中专门强调了用例驱动，足见用例建模的重要性，但是我们要注意到第二阶段的重点仍然是搭框架结构，因此并没有要求要识别所有的领域类和用例。 第三阶段-需求细化 需求细化是什么？在第二阶段我已经通过分解和细化到达了具体的用例，而第三阶段的重点就是单个用例以及该用例可能涉及到的界面部分建模。 书中将用例分为三类是有一定道理的，即业务用例，报表用例和接口用例。 对于业务用例的重点是基本流，扩展流和业务规则。 对于报表类的用例重点则是报表的输入，输出内容，输出格式。 在这里有个情况不得不提出的就是，一些报表类用例脱离了只要不是项目历史开发人员很难看懂，原因即是关键的报表的数据来源在哪里没有说清楚，这点也是报表类用例必须关注的要点。 如果将用例分为两个层次，第一重点就是关注业务活动流和规则的细化，另外一个就是涉及到交互和界面的建模和细化。 这两个层次仍然有一定的关系，重点仍然是要先考虑业务流和规则，再来考虑交互和界面。如果先陷入到了界面建模再考虑业务流和规则，则又是顺序错误的开发人员思维，即违背了用例是业务活动驱动的初衷。 这里多说一句即是功能点估算在什么时候用，在第一阶段用是毫无意义的，最佳的使用点就是在需求细化后，具体的业务流和规则，需要的数据输入和输出都基本清楚后，最适合进行功能点估算。 因此我们也建议一种方法，即第一阶段先进行专家法估算，到了第三阶段通过功能点估算对专家法估算内容进行验证。

需求问题曾经是软件开发领域最困难、影响面最广的环节之一；而且在未来很长的一段时间里，还将可能成为最困难的环节之一。这或许是因为产业环境不够健全，或许是用户成熟度不高，或许是产业太过年轻。 毕竟需求问题不仅仅涉及IT技术方面，还涉及业务知识、心理学、公司政治、流程管理、沟通交流等多个领域。 需求分析要有广度，深度。

本书结构清晰，按照需求定义；需求捕获；需求分析与建模；编写规约；需求验证，其中加入了大量的详实案例，便于理解。收获还是蛮多的。 在现代软件工程方法论分为重方法论和敏捷方法，重方法论强调前期设计，为未来设计。而敏捷方法论则更加强调为现在设计，未来重构它，就是这个最本质的区别。个人认为先用流程武装自己，然后在适度敏捷。不是整天满嘴敏捷。 总体上主要讲了如下内容： 1需求定义需求分层： 业务需求：建设目标，解决问题；抓住外部环境变化机会 用户需求：用户使用软件完成某项任务，怎么完成的需求。 特点零散-用户提出不通过角度、不同层面、不同粒度的需求。 存在矛盾-用户处于不同企业组织的不同层面，因此出现盲人摸象的现象，从而导致片面。 行为需求/软件需求（功能需求；非功能需求；设计约束）。 2需求获取（需求调研）； 1）捕获范围不足-除了用户想要的功能还要考虑业务知识。 2）缺乏计划性：定向，聚焦，宏观和微观混在一起 3）捕获对象不明确： 4）捕获手段不足 3需求分析； （1）需求分析是什么？需求分析是向下分解+向上提炼外加一些规格化 需求分析是业务分析--对问题进行研究 需求分析是一种分解活动：分解不同的主题域，分解成该主题域的业务流程和业务步骤 需求分析是一种提炼与整合活动：需要将用户的需求合并到业务活动中去，将各个业务流程合成到全局业务流程中、 需求分析是一种规格化活动柜：要找到冲突、矛盾、并且解决。 （2）内容与形式：分析是任务，建模是手段 （3）何时开始、何时结束 （4）需求分析人员技能：倾听、交谈、和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。 概括为：业务知识，技术知识，沟通能力。 4需求验证 （1）需求验证的关键是评审，注意分层次分内容验证 5需求管理及跟踪 统一明确的需求项划分标准及优先级，明确变更管理流程 其中变更考虑三方面： 1）业务影响分析：合理性，优先级以及对原有需求的影响 2）技术影响分析：影响范围，工作量，分析后决定是否拒绝，还是本次迭代 3）项目影响分析：对整个项目时间、进度、成本的影响程度。 最终完成以上工作还是要看需求分析员的能力水平，需求分析师在于尽早识别变更，架构师和设计员在于以弹性的架构减少变更的影响。所以一位优秀的需求分析员工对于项目产品的成败特别重要。