简介
精彩点评
-
张波推荐
全面，细致，系统化，很好的一本书，悔前几年没有看。书中的举例(信息系统)，相比现在的互联网显得有些过时了，方法还是很好的
-
嘟噜嘟噜推荐
对瀑布流的开发更能体现本书的价值，大环境，大企业！ 书中很多东西都可以当工具使用，无妨什么开发流派！ 三人行必有我师，能学到知识，并应用就是最大的收获！ 这谢谢！
-
李宏伟推荐
对软件需求工程的各环节如何开展，从方法论的角度、结合例子和亲身经历进行了完整、准确且生动的阐述，读后有拨云见日之感；总结出的SERU框架及其所包含的一系列方法、模版、戒语等，实用性很强，对于软件从业者有很好的指导作用。
-
杨斯斧推荐
虽然是老书，但作为基础知识去了解还是很有用的。书中有好多地方看的出作者本人的理解，是亮点，而不是一味的讲概念，可读性更强了
-
凡风推荐
前4章和最后小结可读，整本书就是讲SERU框架的，在实际应用中确实能提供指导。其他章节没啥用，变更那一张可以略读。框架打5星，整体4星。
-
CHL推荐
建立了全面的框架，并且填充有丰富的细节，是本很好的实践指南。
-
谢明明推荐
相较于大学教材不同的是，作者提出了一个新的SERU框架，对于软件的需求实践确实提供了一个新的视角，其中的一些办法确实为现如今存在的问题提供了很好的解决方法。
-
bobo推荐
本书结构清晰，按照需求定义；需求捕获；需求分析与建模；编写规约；需求验证，其中加入了大量的详实案例，便于理解。收获还是蛮多的。 在现代软件工程方法论分为重方法论和敏捷方法，重方法论强调前期设计，为未来设计。而敏捷方法论则更加强调为现在设计，未来重构它，就是这个最本质的区别。个人认为先用流程武装自己，然后在适度敏捷。不是整天满嘴敏捷。 总体上主要讲了如下内容： 1需求定义需求分层： 业务需求：建设目标，解决问题；抓住外部环境变化机会 用户需求：用户使用软件完成某项任务，怎么完成的需求。 特点零散-用户提出不通过角度、不同层面、不同粒度的需求。 存在矛盾-用户处于不同企业组织的不同层面，因此出现盲人摸象的现象，从而导致片面。 行为需求/软件需求（功能需求；非功能需求；设计约束）。 2需求获取（需求调研）； 1）捕获范围不足-除了用户想要的功能还要考虑业务知识。 2）缺乏计划性：定向，聚焦，宏观和微观混在一起 3）捕获对象不明确： 4）捕获手段不足 3需求分析； （1）需求分析是什么？需求分析是向下分解+向上提炼外加一些规格化 需求分析是业务分析--对问题进行研究 需求分析是一种分解活动：分解不同的主题域，分解成该主题域的业务流程和业务步骤 需求分析是一种提炼与整合活动：需要将用户的需求合并到业务活动中去，将各个业务流程合成到全局业务流程中、 需求分析是一种规格化活动柜：要找到冲突、矛盾、并且解决。 （2）内容与形式：分析是任务，建模是手段 （3）何时开始、何时结束 （4）需求分析人员技能：倾听、交谈、和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。 概括为：业务知识，技术知识，沟通能力。 4需求验证 （1）需求验证的关键是评审，注意分层次分内容验证 5需求管理及跟踪 统一明确的需求项划分标准及优先级，明确变更管理流程 其中变更考虑三方面： 1）业务影响分析：合理性，优先级以及对原有需求的影响 2）技术影响分析：影响范围，工作量，分析后决定是否拒绝，还是本次迭代 3）项目影响分析：对整个项目时间、进度、成本的影响程度。 最终完成以上工作还是要看需求分析员的能力水平，需求分析师在于尽早识别变更，架构师和设计员在于以弹性的架构减少变更的影响。所以一位优秀的需求分析员工对于项目产品的成败特别重要。
-
SoooŎoophia推荐
书中提到了很多工作中曾经遇到过的坑，也提出了应对措施。举例大多有趣且便于理解，但是总体上读起来还是有点费劲的，也许二刷会加深理解。
-
王逸少推荐
SERU过程框架覆盖了需求获取、需求分析、需求管理中的主要活动（其中需求定义、需求分析与建模、需求描述均属于需求分析阶段；它们和需求获取统称为需求开发），明确地定义了工作任务、介绍了工作方法、指出了工作产物、说明了产物之间的联接方法，可以帮助软件开发团队快速应用到工作中，有效提高需求工程的质量。
-
毛斐推荐
书很棒，非常经典。但是我更喜欢同作者的另一本《有效需求分析》，出版的更晚，内容更易懂。我觉得这两本读《有效需求分析》即可。
-
（morris)吴猛推荐
读了这本书让我从理论上到实践上对需求的各个角度都有了很深入的了解，重点部分看了两遍。之前看的书或者单讲UML，或者单讲OOD、OOA，或者就是讲软件工程，这些主题之间相互怎么连接就看个人经验和造化，将需求、OOD、UML融为一体这是第一本。我认为最精彩的是第二部分的第六章，把主题域到er&u的过程详细描述，有讲解有例子，作者把业务这个主线一直牢牢抓住，给读者讲解也是围绕读者的业务--应用来安排。
-
William推荐
翻了一下书，太困了。需求分析的确挺复杂的，现在搞Scrum之后要求得就简单多。但整体上一个阶段内要做什么，是需要设计下的，这时候需要作者说的需求分析。但为什么这么专业的岗位，没看到有多少地方在招聘。
-
Contemplator推荐
一般吧，看了许多软件需求相关的书籍，感觉大家都是根据PMP来的，大同小异。
-
foward推荐
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重要信息： 根据上阶段得出的用例模型，按基线安排调研与细化； 根据用例所关联的领域类，安排领域类的分析和细化；