软件需求最佳实践
出版社:电子工业出版社
出版日期:2008
ISBN:9787121073953
作者:徐峰
页数:396页
章节摘录
第1章 需求实践现状分析
在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。 1.1 软件项目失败的根源 “在中国做软件太难了！客户连自己的需求都说不清楚！”，这种抱怨的话总是在笔者耳边响起。实际上，软件项目失败率居高不下、需求问题层出不穷的现象并不仅仅是中国软件业的困扰，在大洋彼岸的美国软件业也未能幸免。 第三方机构Standish Group每隔几年都会对软件项目实践现状进行分析与统计，其显示的“成绩单”（CHAOS Report）十分令人担忧。正所谓“他山之石可以攻玉”，下面我们分别来看看几次报告中显示的数据，分析失败的原因，以便从中获得一些帮助我们改进工作的思路。 1.1.1 CHAOS Report 1994 1994年度发布的报告显示，美国每年的IT应用开发项目大约有175 000个，总投资高达2500亿美元，大型、中型、小型企业的软件开发项目的平均成本分别是232.2万美元、133.I万美元和43.4万美元。 而Standish Group的研究显示：高达31.1％的项目彻底失败，高达52.7％的项目进度超期或成本超支，被认为成功的项目仅有可怜的16.2％。 而导致进度超期、成本超支的项目中，最主要的原因之一是项目的重新启动，而每100个项目中就有94个曾经遇到这个问题，甚至在这94个项目中还有许多项目经历了多次的重新启动。 而不同的项目的进度超期、成本超支情况还是有所不同的，下面我们就通过CHAOS报告中总结的表格来了解一下，如表1.1所示。 在表1—2中可以看出，十大成功保证中有三个是直接与需求相关的（已加粗显示），累计权重达到37.1％；而十大败因中与需求直接相关的更是高达五个，累计权重高达51.6％，可见需求问题对项目影响程度之高。 而对于那些成本超支、进度超期的项目而言，报告也总结出了导致这一结果出现的十大因素：缺乏用户参与（12.8％）、不完整的需求（12.3％）、需求变更频繁（11.8％）、缺乏执行层的支持（7.5％）、技术能力缺乏（7.0％）、资源不足（6.4％）、不切实际的用户期望（5.9％）、没有清晰的愿景和目标（5.3％）、不切实际的时间限制（4.3％）、新技术风险（3.7％）、其他（23.0％）。
前言
写一本书不容易，写一本让自己满意的书更不容易，而写一本让读者喜欢的书则是难上加难。或许这一“冠冕堂皇”的理由可以作为笔者一再错过向关注本书的读者所承诺的上市时间的借口。但是没有任何理由可以让笔者松懈下来，毕竟自己一直在标榜要解决“我们并不缺乏需求的理论，缺少的是真正落地的方法”的问题，为所有读者提供一种切实可行的实践手段，是笔者写作本书的核心目标。 在翻读本书时，或许你会从本书的字里行间读到几分轻松，这是因为书中有不少的文字是笔者在风景秀丽的员当湖畔的咖啡厅里写就的，希望笔者这种轻松的心情能够透过这些文字传递给每位工作在“沉重”的需求分析过程中的所有读者。 在细究本书时，或许你会从本书的文字里头看到几处零乱，这是因为文中有很多的段落是笔者在吚哎学语的一岁小儿的恶作剧边码成的，希望笔者这些零碎的想法能够借助书的脉络传达给每位工作在“繁杂”的需求分析原则下的所有读者。 在将书稿交付编辑之时，我深刻地感到：本书虽然没有Martin七年磨一剑的锋芒，却也有三年憋一本的艰辛。在整个写作过程中，多次经历了自我否定、推倒重来的痛苦，也享受了许多自我升华的乐趣；当然笔者衷心地希望本书能够向大家传递乐趣。
媒体关注与评论
六年前，当我认识徐锋时，他就是软件需求领域的高手。潜心实践、研究，六年磨一剑，如今锋利出鞘。中国的软件产业并不缺乏软件工程理论，而是我们没有很好地运用这些理论。我给软件工程硕士讲授课程，使用过各种版本的教材，这些书籍的通病就是实践性不强。当我读到这本书稿时，倍感亲切，这不是一本软件需求的理论书，而是一本需求实践指导手册。 ——张友生博士（希赛网首席架构师，著名计算机教育专家） 涵盖面广，实用性强，有理有据（例），亦庄亦谐，朴实无华又非常受用，在技术类书籍中当属不可多得的佳作。 ——田俊国（用友大学执行校长，高级企业培训师） （软件需求最佳实践>是一本足以令人拍案叫好的书。它经验密集，直击需求实践中各种问题，给出令人信服的问题解决思路。它实践体系完善，贯穿全书的SERLJ过程框架，详尽地覆盖了需求工作中各个环节的任务、要点及产物，脉络清晰，可操作性极强。最可贵的是，SERU过程框架漂亮地 “打通了”业务工程到传统需求的“鸿沟”，而众多企业需求实践中的最大困惑恰恰常在于此。故此，郑重推荐徐锋的这本佳作！ ——温昱资深咨询顾问．软件架构高级培训讲师）
内容概要
中国系统分析员顾问团(CSAI)软件工程首席顾问，中国软件技术大会杰出贡献专家，资深咨询顾问、培训讲师。主要研究领域为需求工程、系统分析与设计、软件估算，致力于推动软件工程方法论的落地研究。作者具有丰富的软件开发、信息系统运行与管理、市场规划、企业管理等领域的从业经验，善于从业务、技术两个视角审视软件开发工作。
曾在《程序员》等媒体发布了《实战OO》、《项目管理三部曲》、《大话Design》等多个专栏文章，著有《UML面向对象建模基础》等多本书籍，翻译了《UML2.0实战》、《AOSD中文版》、《CLoudto Code 中文版》等多本技术书籍。
书籍目录
第1部分 原理、模型与误区第1章 需求实践现状分析
2在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。1.1 软件项目失败的根源
21.1.1 CHAOS Report 1994
21.1.2 CHAOS Report后续版本
31.1.3 需求相关败因简要分析
41.1.4 一幅漫画带来的思考
81.2 透过表象，分析本质
121.2.1 需求变更频繁
121.2.2 上线阻力大
131.2.3 运行效果差
141.2.4 完全崩溃
151.3 方法论与需求工作
161.3.1 计算模式
161.3.2 软件工程方法论
171.3.3 开发思想
181.4 小结
19第2章 不同软件项目的需求视图
20随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用层面也在逐渐地深入，同时也意味着不同的软件项目具有不同的特点，这也就对需求工作产生了诸多影响。 在本章中，我们就将针对信息系统、嵌入式系统、软件产品等不同角度来说明如何进行相应的需求工作，为需求分析师提供一个切实有效的视图。2.1 信息系统的需求视图
202.1.1 信息系统的本质与分类
202.1.2 联机事务处理系统——流程电子化
222.1.3 管理信息系统——数据信息化
252.1.4 其他信息系统
292.1.5 信息系统的多维视图
312.2 嵌入式系统的需求视图
332.2.1 面向直接用户的嵌入式系统
342.2.2 面向特定设备的嵌入式系统
352.3 软件产品的需求视图
362.4 小结
40第3章 软件需求与需求工程
41笔者在做需求分析师的培训时，经常会问学员这样的一个问题：什么是软件需求？这个看似简单的问题却并不好回答，也许很多人会简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解却并不完整，如果对用户所处的业务场景没有建立正确认识，经常会给工作带来麻烦。因此本章将对一些与需求、需求工程相关的关键概念进行阐释。3.1 什么是软件需求
413.1.1 需求的三个层次
413.1.2 需求的三种类型
433.1.3 优秀需求的标准
463.2 需求工程解析
503.2.1 需求工程的范畴
503.2.2 需求开发工作要点
513.2.3 需求管理工作要点
563.2.4 需求分析人员的技能组成
583.2.5 SERU模型概述
593.3 小结
61第2部分 需求开发第4章 需求定义最佳实践
64需求定义活动准确来说是不属于需求工程范畴的，它实际上是立项管理需要做的工作。但需求定义阶段的产物对于需求捕获、分析与建模活动都有着直接的影响，如果这个阶段的工作做得不理想，就会出现“上梁不正下梁歪”的结果。因此本书还是将这个活动纳入进来，并将给大家提供一个能够与后续活动结合紧密的方法。4.1 需求定义任务概述
644.1.1 需求定义的时机
644.1.2 需求定义的理念与策略
654.2 问题分析的五步法
664.2.1 在问题定义上达成共识
674.2.2 分析问题背后的问题
734.2.3 确定相关人员和用户
774.2.4 定义解决方案的界限
784.2.5 确定加在解决方案上的约束
804.2.6 小结
814.3 需求定义的产物与要素
814.3.1 需求定义的产物
814.3.2 需求定义的要素
824.4 定义需求范围
874.4.1 案例说明
874.4.2 划分主题域
884.4.3 确定主题域范围
974.4.4 标识业务事件与报表
1014.4.5 生成需求大纲
1044.5 小结
108第5章 需求捕获最佳实践
109需求捕获是需求开发中的第一个活动，可以说任何一个需求团队对它都不陌生，但如何提高需求捕获的有效性却一直以来是困扰大家的问题。需求捕获的要点在于计划性和科学性，计划性体现在对捕获对象、问题、时间的计划，科学性则表现在如何有效地选择合适的捕获方法。本章的目的就在于帮助大家更好地达到这两个目标，从而提高需求捕获活动的质量。5.1 需求捕获的策略
1095.1.1 需求捕获应该是主动的
1095.1.2 需求捕获应该是聚焦的
1105.1.3 破解需求的冰山模型
1115.1.4 破解阻碍需求捕获的心理现象
1135.1.5 不要忽视对变更可能的捕获
1175.1.6 需求协商
1185.2 需求捕获的主要方法
1255.2.1 用户访谈
1255.2.2 用户调查
1375.2.3 文档考古
1425.2.4 情节串联板
1445.2.5 现场观摩
1455.2.6 联合开发
1475.3 需求捕获的记录工具
1505.3.1 工具的选择与定义
1505.3.2 任务卡片
1515.3.3 场景说明
1525.3.4 其他工具
1535.4 小结
154第6章 需求分析与建模最佳实践
156需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。但由于分析这个词比较抽象，很多时候让人感到无从入手，甚至导致被轻易地滑过了，直接将需求捕获的结果整理到软件需求规格说明书中。而需求建模也有很多工具，到底怎么有效地应用到需求分析过程中也是令人感到难以掌握的东西。因此本章的目标就是为读者勾勒出需求分析的阶段与任务，指出如何选择适合的建模工具，以及在什么时机、如何应用这些建模工具。6.1 需求分析与建模的要点与误区分析
1566.1.1 需求分析到底做什么
1566.1.2 建模的目标与要点
1596.1.3 选择建模工具的要点
1606.2 周期一：理清框架与脉络
1646.2.1 业务流程分析
1656.2.2 业务实体分析
1916.2.3 角色与使用场景分析
2166.2.4 周期一的产物
2326.3 周期二：确定需求细节
2496.3.1 确定行为需求的细节
2506.3.2 确定结构需求的细节
2706.3.3 周期二的产物
2796.4 其他需求分析
2926.4.1 接口需求
2926.4.2 非功能需求的追踪
2946.4.3 设计约束
2976.5 小结
301第7章 需求描述最佳实践
302需求描述就是将需求捕获、分析的结果进行文档化的过程。在软件开发时，将分析的结果文档化是不可或缺的任务，也称为编写规约活动；而在某个项目中，可能还会由用户代表或需求捕获人员对捕获的内容进行整理，形成用户需求说明书。具体要干什么，想必大家并不陌生，而且在前一章中也看到了一些实例的片段。因此本章将重点从需求描述的风格与格式、写作策略与技巧两个方面做些强调和补充。7.1 需求描述的风格与格式
3027.1.1 常见的描述风格与选用标准
3027.1.2 典型软件需求规格说明书模板解析
3037.1.3 定义模板的技巧
3187.1.4 用户需求说明与软件需求规格说明
3267.2 写作策略与技巧
3287.2.1 文字表达的先天不足
3287.2.2 需求描述的两大原则
3307.2.3 不要忽视陈述需求理由的重要性
3327.2.4 注意措辞
3347.3 小结
335第8章 需求验证最佳实践
336需求验证是需求开发的最后一个环节，它是一个质量关。也就是说，其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是Review（复查，也常译为评审）。但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本章的目标就是帮助大家缓解这个问题。8.1 需求验证的主要手段
3368.1.1 不同正式化程度的评审
3368.1.2 审查过程概述
3388.2 需求验证的主要误区与解决方案
3408.2.1 需求验证的5大要点
3418.2.2 需求验证常见的5大问题
3448.3 小结
346第3部分 需求管理第9章 需求基线操作实务
348需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。但许多相关书籍中对需求基线的介绍相对比较理论化，很少给出具体的操作方法，往往使得许多软件开发团队无从入手。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。9.1 需求基线的理念与策略
3489.1.1 基线思想的起源
3489.1.2 基线的策略
3509.2 基线划定的基础：优先级评价
3519.2.1 组织需求项
3519.2.2 业务优先级评价
3529.2.3 根据技术依赖性和项目风险调整优先级
3569.3 基线划定的要素：工作量估算
3569.3.1 估算的意义与要点
3569.3.2 定义阶段的估算示例
3589.3.3 分析一阶段的估算示例
3619.4 基线划定与管理
3629.4.1 划定基线
3629.4.2 管理基线
3639.5 小结
364第10章 变更管理操作实务
365需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构Standish Group的CHAOS报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在CHAOS报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题，这里面就意味着存在距离，本章的目的就是希望帮助大家找到其中的差距。10.1 变更管理的理念
36510.2 变更管理要点一：统一渠道
36610.2.1 CCB背后的道理
36610.2.2 变更处理过程
36810.3 变更管理要点二：统一平台
37310.3.1 变更管理平台的选择
37310.3.2 变更管理平台的应用要点
37410.4 小结
375第11章 需求跟踪操作实务
376需求跟踪是一个高阶的管理活动，它的目标是为了更好地管理需求的状态、更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。本章我们就对跟踪的一些要点做一简要的说明。11.1 需求跟踪的基本概念
37611.1.1 用户需求到软件需求的跟踪
37711.1.2 软件需求到软件需求的跟踪
37711.1.3 软件需求到下游工作产品的跟踪
37711.2 需求跟踪的操作方法
37811.2.1 表格法
37811.2.2 链表法
37911.3 小结
381第4部分 总结第12章 SERU过程框架总结
384笔者经常说一个观点：“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法”。而贯穿全书的SERU过程框架（也称为SERU模型）正是笔者基于多年不同领域、不同规模的软件项目实践的基础上，通过对许多重型方法的剪裁而得到的一个清晰、实用的软件需求过程框架。12.1 SERU过程框架要点概述
38412.1.1 SERU过程框架的理论基础
38412.1.2 SERU过程框架全景图
38512.1.3 SERU过程框架导入建议
38812.2 需求实作要点概述
38812.3 结语
391参考文献
392SERU诫语目录第1章 需求实践现状分析
2SERU诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。
6SERU诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益SERU诫语1-2：（解决问题、创造机会、提高管控力等）的沟通。
6SERU诫语1-3：缓解沟通失真最有效的方法是及时复述。
9SERU诫语1-4：需求分析的本质在于业务分析，而非技术分析。
11SERU诫语1-5：业务场景是需求之魂。
12SERU诫语1-6：需求分析人员对于技术方法论的评价重在适用性。
16SERU诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。
18第2章 不同软件项目的需求视图
20SERU诫语2-1：流程分析（业务事件）是OLTP系统的关键线索和主要视图。
23SERU诫语2-2：报表分析是MIS系统的关键线索和主要视图。
26SERU诫语2-3：决策场景是DSS系统的关键线索和主要视图。
29SERU诫语2-4：工作场景是专家系统的关键线索和主要视图。
30SERU诫语2-5：并行工作流是OA系统的关键线索和主要视图。
30SERU诫语2-6：高层管理人员的关注点往往在问题和机会。
33SERU诫语2-7：对于面向用户的嵌入式系统，行为分析是要点。
35SERU诫语2-8：面向特定设备的嵌入式系统，外部接口和事件分析是要点。
36SERU诫语2-9：信息系统类软件产品的需求重点在于针对不同目标客户群体的SERU诫语2-9：不同商业模式分离变化点；经常需要减出通用性，再通过插接SERU诫语2-9：解决扩展性。
39SERU诫语2-10：基于使用场景的困难点分析是工具软件的需求要点。
40第3章 软件需求与需求工程
41SERU诫语3-1：业务需求是需求定义的产物，用户需求是需求捕获的产物，SERU诫语2-9：软件需求是需求分析与建模的产物。
43SERU诫语3-2：功能需求的要点在于如何组织。
44SERU诫语3-3：非功能需求的要点在于保证信息的有效传递和注意其局部性。
44SERU诫语3-4：设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的SERU诫语2-9：使用环境三大类型。
45SERU诫语3-5：业务导向的层次结构是保障完整性的关键。
46SERU诫语3-6：需求有时会戴上“高优先级”的面具，实际上就是担心SERU诫语2-9：你不去实现它。
48SERU诫语3-7：满意/不满意度模型是需求必要性评价的有效手段。
49SERU诫语3-8：在需求捕获活动中，化被动为主动是关键。
52SERU诫语3-9：需求分析就是向下分解+向上提炼，外加一些规格化。
53SERU诫语3-10：需求分析是目标，需求建模是手段。
54SERU诫语3-11：在编写需求规格说明书时，应确保一类信息只在一处描述。
55SERU诫语3-12：划分出大小合适、粒度均匀的需求项是需求管理的前提。
57SERU诫语3-13：需求优先级与工作量估算是基线管理的关键。
57SERU诫语3-14：SERU模型是需求分析的工作指南。
60第4章 需求定义最佳实践
64SERU诫语4-1：清晰的项目目标和范围定义，能够引导需求工作顺利进行。
65SERU诫语4-2：对混沌不清的目标，可以通过内部寻根或外部溯源来破解。
65SERU诫语4-3：对问题进行了正确的定义，意味着成功解决了一半。SERU诫语2-9：而在问题定义时应该善于使用转换和本源两个技巧。
68SERU诫语4-4：需求定义阶段要善于将未知解问题转换成已知解问题。
68SERU诫语4-5：在确定某问题的解决方案时，一定要思考是否会引发新问题。
70SERU诫语4-6：直接修改错误，不要用其他方案来弥补错误。
71SERU诫语4-7：鱼骨图为解决问题找到了靶子，帕累托图则标上了环数。
76SERU诫语4-8：范围是涉及的事、物，边界是人与系统的职责边界。
79SERU诫语4-9：用户永远会希望花同样的钱，获得尽可能多的功能。
79SERU诫语4-10：需求阶段描述的是用户的能力特点，旨在提高可用性。
86SERU诫语4-11：你可以不做一件事，但一定不能不知道为什么需要做这件事。
86SERU诫语4-12：在分解系统时，应该按业务的脉络来划分成不同的主题域。
89SERU诫语4-13：各个主题域之间的服务接口是需求变更的防火墙。
91SERU诫语4-14：确保能做的事和知道的事相匹配是职责驱动设计的要点。
93SERU诫语4-15：目标决定范围。
96SERU诫语4-16：绘制上下文关系图，先考虑Customer再考虑Worker是要点。
98SERU诫语4-17：业务事件应该是主动触发的，并且将会产生一系列后续行为。
103SERU诫语4-18：业务事件是直接作用于系统的，也就是将触发系统行为。
103第5章 需求捕获最佳实践
109SERU诫语5-1：需求捕获是撒网打鱼，不是休闲钓鱼。
109SERU诫语5-2：善于聚焦访谈话题是需求捕获人员成功的关键。
111SERU诫语5-3：尝试理解业务场景是合格需求分析人员的良好习惯。
112SERU诫语5-4：善于利用技术为用户创造全新体验是优秀需求人员的特质。
113SERU诫语5-5：通过比较用户代表的表述来识别言过其实，利用差异展现、SERU诫语2-9：瓶颈分析法来缓解影响。
114SERU诫语5-6：针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。
114SERU诫语5-7：离开办公室、对访谈进行计划是避免非正事现象的主要手段。
115SERU诫语5-8：化敌为友是缓解抗拒心态的主要方向。
116SERU诫语5-9：倾听对方的抱怨是化敌为友的有效手段之一。
116SERU诫语5-10：突破推卸责任心理的简单手段是让被访谈者介绍工作场景。
117SERU诫语5-11：需求捕获时不要忽视对变更可能的了解。
117SERU诫语5-12：在需求捕获时要善于使用“？”之箭，找到真正的需求。
120SERU诫语5-13：“拨开立场，寻找利益诉求”是需求协商的要点。
122SERU诫语5-14：不要孤立地看待需求项，应该将所有需求视为一个整体。
123SERU诫语5-15：“环境”将改变结果，切换不同的视角会得到不同的认识。
124SERU诫语5-16：善于打比方是提高跨专业沟通效果的好方法。
125SERU诫语5-17：占用时间长和信息的片面性是用户访谈的两大敌人。
126SERU诫语5-18：访谈的线索是因“人”（用户类型）而异的。
126SERU诫语5-19：尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。
128SERU诫语5-20：在需求捕获时别忘了“一图抵千言”这句经典提示。
132SERU诫语5-21：用户访谈是一个有计划的、科学的过程。
135SERU诫语5-22：用户调查能够有效克服用户访谈中存在的片面性。
137SERU诫语5-23：在需求捕获过程中，先访谈再调查是更合理的方式。
137SERU诫语5-24：大样本用户、跨地域用户的存在就是使用用户调查的时机。
138SERU诫语5-25：分析文档资料时应该思考新流程对其的影响。
143SERU诫语5-26：收集文档时，应该尽可能让用户提供带有真实数据的样本。
143SERU诫语5-27：需求捕获人员要善于根据流程分析的结果主动收集相关文档。
144SERU诫语5-28：情节串联板是消除用户盲区的有效技术。
144SERU诫语5-29：情节串联板应该以业务场景作为展示的主线索。
145SERU诫语5-30：交互才是情节串联板的本质，不要只关注于界面的静态效果。
145SERU诫语5-31：现场观摩技术是消除开发团队认识盲区的有效手段。
146SERU诫语5-32：现场观摩技术能够使开发团队实现对业务场景“感同身受”。
146SERU诫语5-33：联合开发是突破双方需求盲区的有效手段。
147SERU诫语5-34：出现“上面开大会，下面开小会”现象，一半责任在组织者。
148SERU诫语5-35：沟通决定内容，内容决定格式。
150第6章 需求分析与建模最佳实践
156SERU诫语6-1：需求分析就是先分解，再提炼，在这个过程中消除矛盾。
156SERU诫语6-2：需求建模的过程远比建模的结果更重要。
159SERU诫语6-3：模型是用来沟通的，因此仅当需要时才构建它。
160SERU诫语6-4：建模的要点是根据要完成的任务选择合适的建模工具。
161SERU诫语6-5：UML本身不是方法论。
163SERU诫语6-6：业务流程是对信息系统进行“庖丁解牛”的核心线索。
165SERU诫语6-7：流程有组织级、部门级、岗位级三个层次，其中部门级是SERU诫语2-9：需求分析的主线索，岗位级是需求细节填充时的工作内容，SERU诫语2-9：组织级是对部门级流程的抽象概括。
170SERU诫语6-8：应该根据项目的特点和团队的技能情况选择合适的模型。
172SERU诫语6-9：模型最有效的方式是在交流中演化出来的。
176SERU诫语6-10：流程图绘制完成之后，花些时间进行瓶颈和利益分析会有意SERU诫语6-10：想不到的收获。
185SERU诫语6-11：在需求建模时，应该大胆地用中文命名类和类的属性。
194SERU诫语6-12：需求阶段的类建模应该尽可能保持简单，引入过多的辅助建模SERU诫语6-10：元素反而会降低图的可读性。
199SERU诫语6-13：领域模型是自底向上合并出来的。
205SERU诫语6-14：领域模型的要点是拒绝实现、保持简单、忠于问题域。
207SERU诫语6-15：领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、SERU诫语6-10：同类不抽象”的原则。
207SERU诫语6-16：团队的分工不明确往往是导致视图交叠的原因，了解不同视图的SERU诫语6-10：关注点，是理解不同模型的关键。
214SERU诫语6-17：仅在需求规格中出现用例图并不意味着应用了用例技术。
216SERU诫语6-18：千万不要为了使用扩展、包含关系而使用它们。扩展用例SERU诫语6-18：建模的通常是优先级较低的扩展事件流，包含关系建模的SERU诫语6-18：通常是多个用例所包含的公共子事件流。
222SERU诫语6-19：在访谈现场，就流程图讨论出用例图是高效的建模方法。
226SERU诫语6-20：如果说用例有粒度，那么它取决于业务流程和任务分工。
230SERU诫语6-21：系统动作（诸如新增、删除之类）和业务名词在用例名称中SERU诫语6-18：相遇时，就是一个十分危险的信号。
230SERU诫语6-22：对不影响泳道间协作的判断、活动均属于细节信息。
234SERU诫语6-23：对于报表而言，并不一定非得按用例模板来组织需求描述。
238SERU诫语6-24：诸如Rose之类的建模工具，对模型抽象的支撑是最重要的。
249SERU诫语6-25：前、后置条件出现的频度并不高，不要画蛇添足。
254SERU诫语6-26：避免在用例事件流描述中出现实现细节、分支结构、SERU诫语6-18：循环结构；特别是不应该出现多路分支结构，如果出现SERU诫语6-18：要反思用例抽象是否正确。
261SERU诫语6-27：界面原型部分是约束、是建议，目的是支持有效的UI设计。
266SERU诫语6-28：建议使用不同的字体风格约定，以表达出数据的结构特点。
276SERU诫语6-29：历史记录的标准也是数据需求的一部分。
276SERU诫语6-30：哪里有分解，哪里就有接口。
292第7章 需求描述最佳实践
302SERU诫语7-1：需求规格的格式取决于开发团队的特点及所选的开发方法论。
324SERU诫语7-2：用户需求说明书是为生成软件需求规格说明书服务的。
328SERU诫语7-3：文字的歧义可能与其长度成正比。
330SERU诫语7-4：要使需求描述更加清晰，就应该转用“结构化文本”式描述。
332SERU诫语7-5：在你被逼在需求描述中增加How的信息之前，先确认自己已经SERU诫语7-5：尝试过为需求添加了Why。
334SERU诫语7-6：对于非功能需求而言，应该抛弃定性，改用场景化描述；SERU诫语7-5：并通过选取指标、积累经验值的方法过渡到定量描述。
335第8章 需求验证最佳实践
336SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。
341SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，SERU诫语7-5：是创建企业评审文化的有效手段。
342SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。
343SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。
343SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每SERU诫语7-5：小时30～40页的速度来准备，缺陷检查表尽量在9条之内。
344第9章 需求基线操作实务
348SERU诫语9-1：优先级是相对的，要在同一级中进行比较。
355SERU诫语9-2：评价具体功能点的优先级时，应将其放到业务场景甚至是业务SERU诫语7-5：流程环境中考虑。
356SERU诫语9-3：软件估算是随着工作任务的细化不断提高精确度的。
357SERU诫语9-4：不同阶段进行软件估算时，应该采用不同的计数单元。
357SERU诫语9-5：悲观估计、乐观估计应和“风险”理由对应起来。
362第10章 变更管理操作实务
365SERU诫语10-1：需求变更管理的目标是控制变更，而非避免变更。
365SERU诫语10-2：控制变更的目标是减少变更对开发工作的影响。
365SERU诫语10-3：需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于SERU诫语10-3：“尽可能以弹性的设计来减少变更的影响”。
366SERU诫语10-4：建立统一的渠道让客户意识到变更的成本，减少“来路不正”SERU诫语10-3：的变更，记录“变更的工作”。
366SERU诫语10-5：CCB的核心人员只有两个，分别代表用户团队和开发团队，SERU诫语10-3：其他组成人员都是协作者和决策者。
367SERU诫语10-6：基于业务驱动的需求项（树型）列表，是对变更进行业务SERU诫语10-3：影响分析的有效方法。
372SERU诫语10-7：对变更进行分类、再分类，是管理变更的重中之重。
375第11章 需求跟踪操作实务
376SERU诫语11-1：需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求SERU诫语10-3：到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。
377
编辑推荐
《软件需求最佳实践：SERU过程框架原理与应用》可作为计算机软件专业本科生、研究生和软件工程硕士的软件需求分析教材，也可以作为软件工程、软件开发管理培训的教材，更是一线项目经理、需求分析人员、资深开发人员、信息系统运行管理人员、研发企业管理人员的必备参考书。 六年前，当我认识徐锋时，他就是软件需求领域的高手。潜心实践、研究，六年磨一剑，如今锋利出鞘。中国的软件产业并不缺乏软件工程理论，而是我们没有很好地运用这些理论。我给软件工程硕士讲授〈需求工程〉课程，使用过各种版本的教材，这些书籍的通病就是实践性不强。当我读到这本书稿时，倍感亲切，这不是一本软件需求的理论书，而是一本需求实践指导手册。 ——张友生博士（希赛网首席架构师，著名计算机教育专家） 涵盖面广，实用性强，有理有据（例），亦庄亦谐，朴实无华又非常受用，在技术类书籍中当属不可多得的佳作。 ——田俊国（用友大学执行校长，高级企业培训师） （软件需求最佳实践〉是一本足以令人拍案叫好的书。它经验密集，直击需求实践中各种问题，给出令人信服的问题解决思路。它实践体系完善，贯穿全书的SERLJ过程框架，详尽地覆盖了需求工作中各个环节的任务、要点及产物，脉络清晰，可操作性极强。最可贵的是，SERU过程框架漂亮地 “打通了”业务工程到传统需求的“鸿沟”，而众多企业需求实践中的最大困惑恰恰常在于此。故此，郑重推荐徐锋的这本佳作！ ——温昱资深咨询顾问．软件架构高级培训讲师）
作者简介
本书首先从软件需求实践中出现的主要问题和困难入手，指出了改进的主要方向；然后逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和具体手段；并提出了一个可操作性强、易于上手的SERU过程框架，能够帮助读者清晰地了解整个过程，理解各阶段的关键产物和产物之间的关系。
本书还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述，给出了具有很强实践性的具体建议。综观全书，语言浅显、文字生动，蕴含了许多人文、心理、交流方面的知识，即使非技术背景的读者也能够轻松读懂大部分内容，从中受益。
本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件需求分析教材，也可以作为软件工程、软件开发管理培训的教材，更是一线项目经理、需求分析人员、资深开发人员、信息系统运行管理人员、研发企业管理人员的必备参考书。
图书封面
发布书评
精彩书评 (总计8条)
-
这是参加徐锋的《软件需求最佳实践》课程培训后的再一次总结，笔者在提出SERU过程框架的时候常说到一个观点，就是我们并不缺乏软件工程，需求工程的理论，技术，缺乏的是将这些理论和技术有效的应用到实践。而作者的SERU过程框架正好是将软件工程理论和具体的需求实践工作真正的结合起来了，个人认为最核心的不是提出了很多重要的需求诫语，更重要的是可以通过SERU框架系统来梳理和回顾我们的需求开发和需求管理活动。首先对SERU模型的四个字母再做一个说明S:Subject Area，表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。E:Event，表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。R:Report，表示报表，统一处理查询，分析和统计类需求。U:Use Case，表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。SERU过程框架模型将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。第一阶段-需求定义阶段需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。同时也提出了类似任务卡片等很好的现场需求捕获工具。为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。主题域划分+上下文图，是需求定义阶段的重要输出。主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。主题域划分清楚了下一步重点就是要确定主题域的范围，自然引入了上下文关系图，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互。通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。在这里我觉得重点要借鉴的就是从顶向下的系统思维和分而治之，这是解决问题很重要方法。同时刚开始一定不要跳过这个阶段而落入需求细节。主题域和业务事件是两个重要概念，而这两个概念核心又是业务场景。第二阶段-需求分析阶段在第二个阶段重点就是粒度的细化，从主题域我需要细化一层到识别了关键业务对象的领域视图，从业务事件进行流程分析我们需要讲业务事件细化一层到具体的业务活动，而业务活动正式我们在识别用例的时候的重要参考。所以在这里我们基本清楚了第二阶段刚开始是通过业务事件进行业务流程分析，业务实体分析，业务场景分析，识别领域类和用例。需求分析就是先分解，在提炼，然后在这个过程中消除矛盾。不管是采用结构化的方法还是面向对象的方法，分解是人类控制复杂性，认知复杂事物的最佳实践。现代工程理论更建议采用业务导向的分解而非系统导向的分解。在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-》主题域-》业务事件；到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-》业务流程和业务活动-》领域类图和用例。业务流程是对信息系统进行庖丁解牛的核心线索，每个业务事件都是一个业务流程的触发，因此针对每个业务事件都应继续做业务流程分析。对于业务流程是企业核心业务的重要载体，业务流程本身就是结构化的，而且是分级的，通过分析业务流程就能够识别企业核心业务活动，为需求建模做好准备工作。在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例，在RUP核心三要素中专门强调了用例驱动，足见用例建模的重要性，但是我们要注意到第二阶段的重点仍然是搭框架结构，因此并没有要求要识别所有的领域类和用例。第三阶段-需求细化需求细化是什么？在第二阶段我已经通过分解和细化到达了具体的用例，而第三阶段的重点就是单个用例以及该用例可能涉及到的界面部分建模。书中将用例分为三类是有一定道理的，即业务用例，报表用例和接口用例。对于业务用例的重点是基本流，扩展流和业务规则。对于报表类的用例重点则是报表的输入，输出内容，输出格式。在这里有个情况不得不提出的就是，一些报表类用例脱离了只要不是项目历史开发人员很难看懂，原因即是关键的报表的数据来源在哪里没有说清楚，这点也是报表类用例必须关注的要点。如果将用例分为两个层次，第一重点就是关注业务活动流和规则的细化，另外一个就是涉及到交互和界面的建模和细化。这两个层次仍然有一定的关系，重点仍然是要先考虑业务流和规则，再来考虑交互和界面。如果先陷入到了界面建模再考虑业务流和规则，则又是顺序错误的开发人员思维，即违背了用例是业务活动驱动的初衷。这里多说一句即是功能点估算在什么时候用，在第一阶段用是毫无意义的，最佳的使用点就是在需求细化后，具体的业务流和规则，需要的数据输入和输出都基本清楚后，最适合进行功能点估算。因此我们也建议一种方法，即第一阶段先进行专家法估算，到了第三阶段通过功能点估算对专家法估算内容进行验证。 -
在一个苦逼小公司管理项目，同时负责需求。为什么用户会不满意，为什么会互相推诿，为什么沟通成本这么高，为什么项目总是延期。总之，各种在大学里，作为一个大学生的时候，觉得很简单的一件事情，随着人员的数量和项目的范围不同，显得越发复杂。终于也了解工作与在实验室是两个完全不同的概念。对于工具书，也读过项目管理的书籍，PMP的一些知识。也参加过项目管理工程师的考试，但是，对于理论，如何在实际项目中能运用得当，又是另外一件事情。对于这本书，价格算是不便宜的，那些心灵鸡汤的书打个折十几二十就可以买到，或者直接网上可以用到免费的电子版的书。而这本书，想弄电子书好像没弄到。所以才花血本买的，果然对得起这个价格。这本书暂且是读了第一遍。正巧这段时间杭州高温。大楼限电，空调没开，为了避暑，下午的时候去机房门口的办公室开着空调，读着这本书。第一遍下来，觉得作者真心牛逼，中间涵盖的知识面很广，说明作者的确在这方面和有研究，不像有些书抄抄编遍而成。其中的案例我很喜欢读，这些案例何尝不是在我们项目实际进行中发生的呢？对于推荐的一些工具或软件，我打算最近研究下，看看是否对我们的项目有帮助。这本书适合摆在案头，在闲暇时刻或者在项目中有问题的时候，翻到对应的章节，参考下作者的方案和方法，或许就会对项目有帮助的。 -
在经过很多资深需求分析人员推荐后，购买了这本老书。全书写作风格就跟做项目一样，现状分析、解决方案、实施落地等逐一展开介绍。全书除了秉承一图胜千语的风格外，还有很多典型小故事生动的案例剖析，解决了枯燥无味的理论知识，抽象、归纳、总结了软件需求的开发和管理全过程。更重要的是本书还将很多笔者多年积累的宝贵经验作为诫语醒目的分享给读者，而且整理成为目录，可以方便快速的为读者提供帮助！
精彩短评 (总计34条)
-
写的不错。推荐 -
产品狗都应该看一下，尤其是做后端系统产品相关的 -
入门的好书籍 -
同感，书写的真不怎么样http://www.tufangbian.com/bbs/ -
相当不错！ -
实例很多，推荐。 -
写一本书不容易，写一本让自己满意的书更不容易，而写一本让读者喜欢的书则是难上加难。或许这一“冠冕堂皇”的理由可以作为笔者一再错过向关注本书的读者所承诺的上市时间的借口。但是没有任何理由可以让笔者松懈下来，毕竟自己一直在标榜要解决“我们并不缺乏需求的理论，缺少的是真正落地的方法”的问题，为所有读者提供一种切实可行的实践手段，是笔者写作本书的核心目标。
在翻读本书时，或许你会从本书的字里行间读到几分轻松，这是因为书中有不少的文字是笔者在风景秀丽的员当湖畔的咖啡厅里写就的，希望笔者这种轻松的心情能够透过这些文字传递给每位工作在“沉重”的需求分析过程中的所有读者。
在细究本书时，或许你会从本书的文字里头看到几处零乱，这是因为文中有很多的段落是笔者在吚哎学语的一岁小儿的恶作剧边码成的，希望笔者这些零碎的想法能够借助书的脉络传达给每位工作在“繁杂”的需求分析原则下的所有读者。
在将书稿交付编辑之时，我深刻地感到：本书虽然没有Martin七年磨一剑的锋芒，却也有三年憋一本的艰辛。在整个写作过程中，多次经历了自我否定、推倒重来的痛苦，也享受了许多自我升华的乐趣；当然笔者衷心地希望本书能够向大家传递乐趣。
本书特点
本书是一本直击需求实践中各种问题的书籍，在这里没有大量的理论和教条，有的只是翔实、生动的案例与场景；在这里没有高谈阔论般的“道法自然”，有的只是源于生活琐碎细节的“欣然顿悟”；在这里没有鹰击长空般的豪情，有的只是“撒一把土、夯实它，再撒一把土……”的务实。
在全书的组织形式上，采用了简单明了的语法，段落简洁（就像写需求那样），让你能够轻松地阅读；同时贯穿了许多源于生活、源于项目实践的场景与案例，让需求艺术“源于生活、高于生活”，为全书添色增彩；穿插了许多能够令人沉思、轻松一笑的隐喻，为全书增加了一些涟漪；还埋伏了一些小提示，为全书增加了一些外延和联想；而且还罗织了大量的诫语，使全书更多一些骨架与韵味。
相信所有需求实践者都能够从书中看到你工作的影子，寻找到一些“开箱即用” 的技巧和手段，同时也会有整理了一下思绪的妙味。
本书讲了什么
本书的主线索是笔者在RUP（Rational统一过程）、信息工程理论、结构化分析方法、面向对象分析方法的基础上，结合长期需求分析工作的实际经验，剪裁出来的一个针对软件需求工程阶段的SERU过程框架。
SERU过程框架覆盖了需求定义、需求捕获、需求分析与建模、需求描述四大活动，明确地定义了工作任务、介绍了工作方法、指出了工作产物、说明了产物之间的连接方法，可以帮助软件开发团队快速应用到工作中，有效提高需求工程的质量。
本书一共由4个部分，12个章节组成：
部 分 名 章 名 主要内容 页码
第一部分
原理、模型与误区 第1章
需求实践现状分析 归纳实践中遇到的问题，分析问题背后的原因，提出解决问题的方法，强调“业务驱动的需求过程”的重要性
第2章
不同软件项目的需求视图 指出各类软件的需求视图与线索，帮助需求人员明确工作方向
第3章
软件需求与需求工程 从需求层面的角度理解需求工作的阶段，并掌握不同需求类型的组织方法；指出实现优秀需求的核心手段，实例讲解如何保障；对需求开发和需求管理工作的任务进行概述，说明需求分析人员工作的技能要求
第二部分
需求开发 第4章
需求定义最佳实践 指出需求定义的任务，介绍需求定义的操作思路，介绍常用的人文方法；介绍需求定义阶段确定系统范围的具体方法；并说明需求定义阶段的产物，核心内容为两图一纲（构件图、上下文关系图和需求大纲）
第5章
需求捕获最佳实践 从沟通的角度说明需求捕获的障碍，并结合心理学知识提升捕获能力；介绍各种需求捕获方法的使用时机、要点；能在正确的时机正确地使用
第6章
需求分析与建模最佳实践 帮助读者理解为什么要建模、什么时候要建模、如何选择模型等；学会正确理清流程分析、业务实体分析和用例分析，掌握正确的建模方法以及产物之间的关系；掌握填充用例和领域类的方法；学会有效地组织非功能需求、设计约束的方法
续表
部 分 名 章 名 主要内容 页码
第7章
需求描述最佳实践 介绍需求描述的主要格式、写作要点，以及一些提高需求规格说明书质量的手段与技巧
第8章
需求验证最佳实践 介绍需求验证的主要手段、常见误区，以及相应的解决方案
第三部分
需求管理 第9章
需求基线操作实务 说明基线和迭代开发的关系，通过实例说明基线管理中估算和优先级划分两大工作任务的具体执行方法。
第10章
变更管理操作实务 说明变更管理的目标与策略，并且进一步解释统一渠道、统一平台两大要点
第11章
需求跟踪操作实务 说明需求跟踪的作用、启动时机及操作要点
第四部分
总结 第12章
SERU过程框架总结 对SERU过程框架进行概述，指出在实际项目中导入该过程框架的具体步骤和方法，强调了需求分析过程中的一些重要的原则与方法
如何进一步互动
为了更好地与读者交互，提供相关信息及后续的更新，本书还将创建一个专门的网站来推广SERU过程框架，相信不久就可以在http://www.serumodel.com上看到它。
如果你发现本书中的问题，或者在实际的工作中遇到问题，也可以通过电子邮件xf@csai.cn和我取得联系。
致谢
望着这本倾注了巨大激情的书籍，不禁想起被它吞噬的日日夜夜，不由得萌生出对家人的深深歉意，没有你们的支持本书是不可能完成的；在此由衷地感谢我深爱的妻子许高芳以及敬爱的母亲杨美琴，感谢你们多年来的鼓励与支持。
望着这本汇聚了大量观点的书籍，不禁想起为它贡献的芸芸众生，不由得萌生出对朋友的深深谢意，没有你们的帮助本书是不可能精彩的；在此由衷地感谢我亲爱的朋友们以及予以支持的学员，感谢你们一直来的关爱与帮助。
望着这本集结了众多文字的书籍，不禁想起为它纠错的双双眼睛，不由得萌生出对编辑的深深敬意，没有你们的协助本书是不可能高质的；在此由衷地感谢本书的责任编辑以及所有工作人员，感谢你们尽职尽责地把好最后一关。
最后，我还要向CSAI创始人张友生博士，主要贡献者马映冰、田俊国、温昱、张华表示感谢，你们的观点让我如沐春风；向博文视点的郭立、李冰表示感谢，你们的帮助让本书最终付诸实现；向中国平安、中国工商银行、中国建设银行、中兴通讯、东软集团、用友政务、新大陆、福诺等企业中听过我的课程，以及参加各期公开课的朋友们表示感谢，你们的意见、观点、建议使本书更加精彩，在我向大家分享经验的同时也收获了许多宝贵的财富。
谭 文
2008年4月2日 -
见过的最好的中后台产品需求分析师的必备读物 -
我都是公交车看的。适合PM阅读。具体操作部分写得比较细，这部分相对比较晦涩一些。 -
领域经验和方法论的结合，绝对用心之作，值得一读。 -
虽然不赞同其中的有些观点（比如敏捷方法一些使用场景），但书的整体素质相当高。豆瓣9.1分非浪得虚名。 -
这是参加徐锋的《软件需求最佳实践》课程培训后的再一次总结，笔者在提出SERU过程框架的时候常说到一个观点，就是我们并不缺乏软件工程，需求工程的理论，技术，缺乏的是将这些理论和技术有效的应用到实践。而作者的SERU过程框架正好是将软件工程理论和具体的需求实践工作真正的结合起来了，个人认为最核心的不是提出了很多重要的需求诫语，更重要的是可以通过SERU框架系统来梳理和回顾我们的需求开发和需求管理活动。
首先对SERU模型的四个字母再做一个说明
S:Subject Area，表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。
E:Event，表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。
R:Report，表示报表，统一处理查询，分析和统计类需求。
U:Use Case，表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。
SERU过程框架模型将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。
第一阶段-需求定义阶段
需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。同时也提出了类似任务卡片等很好的现场需求捕获工具。为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。
主题域划分+上下文图，是需求定义阶段的重要输出。主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。主题域划分清楚了下一步重点就是要确定主题域的范围，自然引入了上下文关系图，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互。通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。
在这里我觉得重点要借鉴的就是从顶向下的系统思维和分而治之，这是解决问题很重要方法。同时刚开始一定不要跳过这个阶段而落入需求细节。主题域和业务事件是两个重要概念，而这两个概念核心又是业务场景。
第二阶段-需求分析阶段
在第二个阶段重点就是粒度的细化，从主题域我需要细化一层到识别了关键业务对象的领域视图，从业务事件进行流程分析我们需要讲业务事件细化一层到具体的业务活动，而业务活动正式我们在识别用例的时候的重要参考。所以在这里我们基本清楚了第二阶段刚开始是通过业务事件进行业务流程分析，业务实体分析，业务场景分析，识别领域类和用例。
需求分析就是先分解，在提炼，然后在这个过程中消除矛盾。不管是采用结构化的方法还是面向对象的方法，分解是人类控制复杂性，认知复杂事物的最佳实践。现代工程理论更建议采用业务导向的分解而非系统导向的分解。在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-》主题域-》业务事件；到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-》业务流程和业务活动-》领域类图和用例。
业务流程是对信息系统进行庖丁解牛的核心线索，每个业务事件都是一个业务流程的触发，因此针对每个业务事件都应继续做业务流程分析。对于业务流程是企业核心业务的重要载体，业务流程本身就是结构化的，而且是分级的，通过分析业务流程就能够识别企业核心业务活动，为需求建模做好准备工作。
在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例，在RUP核心三要素中专门强调了用例驱动，足见用例建模的重要性，但是我们要注意到第二阶段的重点仍然是搭框架结构，因此并没有要求要识别所有的领域类和用例。
第三阶段-需求细化
需求细化是什么？在第二阶段我已经通过分解和细化到达了具体的用例，而第三阶段的重点就是单个用例以及该用例可能涉及到的界面部分建模。书中将用例分为三类是有一定道理的，即业务用例，报表用例和接口用例。对于业务用例的重点是基本流，扩展流和业务规则。对于报表类的用例重点则是报表的输入，输出内容，输出格式。在这里有个情况不得不提出的就是，一些报表类用例脱离了只要不是项目历史开发人员很难看懂，原因即是关键的报表的数据来源在哪里没有说清楚，这点也是报表类用例必须关注的要点。
如果将用例分为两个层次，第一重点就是关注业务活动流和规则的细化，另外一个就是涉及到交互和界面的建模和细化。这两个层次仍然有一定的关系，重点仍然是要先考虑业务流和规则，再来考虑交互和界面。如果先陷入到了界面建模再考虑业务流和规则，则又是顺序错误的开发人员思维，即违背了用例是业务活动驱动的初衷。
这里多说一句即是功能点估算在什么时候用，在第一阶段用是毫无意义的，最佳的使用点就是在需求细化后，具体的业务流和规则，需要的数据输入和输出都基本清楚后，最适合进行功能点估算。因此我们也建议一种方法，即第一阶段先进行专家法估算，到了第三阶段通过功能点估算对专家法估算内容进行验证。 -
算是很细致的 值得读 -
其实就是有点零乱
其它的还不错吧 -
推荐这本书，里面很多软件需求分析的工具都很实用，同时书中的案例也很形象，看得出是作者日常工作中遇到的问题，而不是生搬硬套，语言也很简洁，由简入深，简述需求的定义及基本流程，再由具体项目从细致处着眼对需求进行实践，可以参照书中提供的方法进行需求捕获和调研以及需求分析的工作。 -
花了6个小时快速读了2遍，结合部门的需求模板和编写指引以及多年实践，发现实践到理论再回实践是亘古不变的成长法则！ -
可读性高，软件工程应知应会，老少咸宜的好书。 -
书中讲解的内容很实用，具有可操作性。 -
同参加过徐锋软件需求最佳实践SERU培训的飘过～～ 总结的很好，我们现在基本上也是应用这个模式 -
SERU这个框架很不错，不过这本书有点虎头蛇尾，前面很惊艳，后面到了需求管理的部分就平平了，毕竟是业务软件的管理方式，如果想用到互联网行业可能就显得太复杂了 -
不仅对于从事软件需求人员获益良多，对于其他行业的业务层开展理解更是一种很好的铺垫 -
很好，提供的明确的方法。 -
第1部分 原理、模型与误区
第1章 需求实践现状分析 2
在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。
1.1 软件项目失败的根源 2
1.1.1 CHAOS Report 1994 2
1.1.2 CHAOS Report后续版本 3
1.1.3 需求相关败因简要分析 4
1.1.4 一幅漫画带来的思考 8
1.2 透过表象，分析本质 12
1.2.1 需求变更频繁 12
1.2.2 上线阻力大 13
1.2.3 运行效果差 14
1.2.4 完全崩溃 15
1.3 方法论与需求工作 16
1.3.1 计算模式 16
1.3.2 软件工程方法论 17
1.3.3 开发思想 18
1.4 小结 19
第2章 不同软件项目的需求视图 20
随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用层面也在逐渐地深入，同时也意味着不同的软件项目具有不同的特点，这也就对需求工作产生了诸多影响。在本章中，我们就将针对信息系统、嵌入式系统、软件产品等不同角度来说明如何进行相应的需求工作，为需求分析师提供一个切实有效的视图。
2.1 信息系统的需求视图 20
2.1.1 信息系统的本质与分类 20
2.1.2 联机事务处理系统——流程电子化 22
2.1.3 管理信息系统——数据信息化 25
2.1.4 其他信息系统 29
2.1.5 信息系统的多维视图 31
2.2 嵌入式系统的需求视图 33
2.2.1 面向直接用户的嵌入式系统 34
2.2.2 面向特定设备的嵌入式系统 35
2.3 软件产品的需求视图 36
2.4 小结 40
第3章 软件需求与需求工程 41
笔者在做需求分析师的培训时，经常会问学员这样的一个问题：什么是软件需求？这个看似简单的问题却并不好回答，也许很多人会简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解却并不完整，如果对用户所处的业务场景没有建立正确认识，经常会给工作带来麻烦。因此本章将对一些与需求、需求工程相关的关键概念进行阐释。
3.1 什么是软件需求 41
3.1.1 需求的三个层次 41
3.1.2 需求的三种类型 43
3.1.3 优秀需求的标准 46
3.2 需求工程解析 50
3.2.1 需求工程的范畴 50
3.2.2 需求开发工作要点 51
3.2.3 需求管理工作要点 56
3.2.4 需求分析人员的技能组成 58
3.2.5 SERU模型概述 59
3.3 小结 61
第2部分 需求开发
第4章 需求定义最佳实践 64
需求定义活动准确来说是不属于需求工程范畴的，它实际上是立项管理需要做的工作。但需求定义阶段的产物对于需求捕获、分析与建模活动都有着直接的影响，如果这个阶段的工作做得不理想，就会出现“上梁不正下梁歪”的结果。因此本书还是将这个活动纳入进来，并将给大家提供一个能够与后续活动结合紧密的方法。
4.1 需求定义任务概述 64
4.1.1 需求定义的时机 64
4.1.2 需求定义的理念与策略 65
4.2 问题分析的五步法 66
4.2.1 在问题定义上达成共识 67
4.2.2 分析问题背后的问题 73
4.2.3 确定相关人员和用户 77
4.2.4 定义解决方案的界限 78
4.2.5 确定加在解决方案上的约束 80
4.2.6 小结 81
4.3 需求定义的产物与要素 81
4.3.1 需求定义的产物 81
4.3.2 需求定义的要素 82
4.4 定义需求范围 87
4.4.1 案例说明 87
4.4.2 划分主题域 88
4.4.3 确定主题域范围 97
4.4.4 标识业务事件与报表 101
4.4.5 生成需求大纲 104
4.5 小结 108
第5章 需求捕获最佳实践 109
需求捕获是需求开发中的第一个活动，可以说任何一个需求团队对它都不陌生，但如何提高需求捕获的有效性却一直以来是困扰大家的问题。需求捕获的要点在于计划性和科学性，计划性体现在对捕获对象、问题、时间的计划，科学性则表现在如何有效地选择合适的捕获方法。本章的目的就在于帮助大家更好地达到这两个目标，从而提高需求捕获活动的质量。
5.1 需求捕获的策略 109
5.1.1 需求捕获应该是主动的 109
5.1.2 需求捕获应该是聚焦的 110
5.1.3 破解需求的冰山模型 111
5.1.4 破解阻碍需求捕获的心理现象 113
5.1.5 不要忽视对变更可能的捕获 117
5.1.6 需求协商 118
5.2 需求捕获的主要方法 125
5.2.1 用户访谈 125
5.2.2 用户调查 137
5.2.3 文档考古 142
5.2.4 情节串联板 144
5.2.5 现场观摩 145
5.2.6 联合开发 147
5.3 需求捕获的记录工具 150
5.3.1 工具的选择与定义 150
5.3.2 任务卡片 151
5.3.3 场景说明 152
5.3.4 其他工具 153
5.4 小结 154
第6章 需求分析与建模最佳实践 156
需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。但由于分析这个词比较抽象，很多时候让人感到无从入手，甚至导致被轻易地滑过了，直接将需求捕获的结果整理到软件需求规格说明书中。而需求建模也有很多工具，到底怎么有效地应用到需求分析过程中也是令人感到难以掌握的东西。因此本章的目标就是为读者勾勒出需求分析的阶段与任务，指出如何选择适合的建模工具，以及在什么时机、如何应用这些建模工具。
6.1 需求分析与建模的要点与误区分析 156
6.1.1 需求分析到底做什么 156
6.1.2 建模的目标与要点 159
6.1.3 选择建模工具的要点 160
6.2 周期一：理清框架与脉络 164
6.2.1 业务流程分析 165
6.2.2 业务实体分析 191
6.2.3 角色与使用场景分析 216
6.2.4 周期一的产物 232
6.3 周期二：确定需求细节 249
6.3.1 确定行为需求的细节 250
6.3.2 确定结构需求的细节 270
6.3.3 周期二的产物 279
6.4 其他需求分析 292
6.4.1 接口需求 292
6.4.2 非功能需求的追踪 294
6.4.3 设计约束 297
6.5 小结 301
第7章 需求描述最佳实践 302
需求描述就是将需求捕获、分析的结果进行文档化的过程。在软件开发时，将分析的结果文档化是不可或缺的任务，也称为编写规约活动；而在某个项目中，可能还会由用户代表或需求捕获人员对捕获的内容进行整理，形成用户需求说明书。具体要干什么，想必大家并不陌生，而且在前一章中也看到了一些实例的片段。因此本章将重点从需求描述的风格与格式、写作策略与技巧两个方面做些强调和补充。
7.1 需求描述的风格与格式 302
7.1.1 常见的描述风格与选用标准 302
7.1.2 典型软件需求规格说明书模板解析 303
7.1.3 定义模板的技巧 318
7.1.4 用户需求说明与软件需求规格说明 326
7.2 写作策略与技巧 328
7.2.1 文字表达的先天不足 328
7.2.2 需求描述的两大原则 330
7.2.3 不要忽视陈述需求理由的重要性 332
7.2.4 注意措辞 334
7.3 小结 335
第8章 需求验证最佳实践 336
需求验证是需求开发的最后一个环节，它是一个质量关。也就是说，其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是Review（复查，也常译为评审）。但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本章的目标就是帮助大家缓解这个问题。
8.1 需求验证的主要手段 336
8.1.1 不同正式化程度的评审 336
8.1.2 审查过程概述 338
8.2 需求验证的主要误区与解决方案 340
8.2.1 需求验证的5大要点 341
8.2.2 需求验证常见的5大问题 344
8.3 小结 346
第3部分 需求管理
第9章 需求基线操作实务 348
需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。但许多相关书籍中对需求基线的介绍相对比较理论化，很少给出具体的操作方法，往往使得许多软件开发团队无从入手。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。
9.1 需求基线的理念与策略 348
9.1.1 基线思想的起源 348
9.1.2 基线的策略 350
9.2 基线划定的基础：优先级评价 351
9.2.1 组织需求项 351
9.2.2 业务优先级评价 352
9.2.3 根据技术依赖性和项目风险调整优先级 356
9.3 基线划定的要素：工作量估算 356
9.3.1 估算的意义与要点 356
9.3.2 定义阶段的估算示例 358
9.3.3 分析一阶段的估算示例 361
9.4 基线划定与管理 362
9.4.1 划定基线 362
9.4.2 管理基线 363
9.5 小结 364
第10章 变更管理操作实务 365
需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构 Standish Group的CHAOS报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在 CHAOS报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题，这里面就意味着存在距离，本章的目的就是希望帮助大家找到其中的差距。
10.1 变更管理的理念 365
10.2 变更管理要点一：统一渠道 366
10.2.1 CCB背后的道理 366
10.2.2 变更处理过程 368
10.3 变更管理要点二：统一平台 373
10.3.1 变更管理平台的选择 373
10.3.2 变更管理平台的应用要点 374
10.4 小结 375
第11章 需求跟踪操作实务 376
需求跟踪是一个高阶的管理活动，它的目标是为了更好地管理需求的状态、更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。本章我们就对跟踪的一些要点做一简要的说明。
11.1 需求跟踪的基本概念 376
11.1.1 用户需求到软件需求的跟踪 377
11.1.2 软件需求到软件需求的跟踪 377
11.1.3 软件需求到下游工作产品的跟踪 377
11.2 需求跟踪的操作方法 378
11.2.1 表格法 378
11.2.2 链表法 379
11.3 小结 381
第4部分 总结
第12章 SERU过程框架总结 384
笔者经常说一个观点：“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法”。而贯穿全书的SERU过程框架（也称为SERU模型）正是笔者基于多年不同领域、不同规模的软件项目实践的基础上，通过对许多重型方法的剪裁而得到的一个清晰、实用的软件需求过程框架。
12.1 SERU过程框架要点概述 384
12.1.1 SERU过程框架的理论基础 384
12.1.2 SERU过程框架全景图 385
12.1.3 SERU过程框架导入建议 388
12.2 需求实作要点概述 388
12.3 结语 391
参考文献 392 -
条例清晰，虎头蛇尾 #8.9/10 -
学到了部分东西，解答了当前的一些困惑 -
例子举的恰到好处 没有技术基础的人也能看懂 后面几张有点晦涩 整体来说 是一本非常好的书 -
实践的指导。
寻找实践的机会中 ：） -
不过书的思路真的非常非常的乱~ -
在经过很多资深需求分析人员推荐后，购买了这本老书。全书写作风格就跟做项目一样，现状分析、解决方案、实施落地等逐一展开介绍。全书除了秉承一图胜千语的风格外，还有很多典型小故事生动的案例剖析，解决了枯燥无味的理论知识，抽象、归纳、总结了软件需求的开发和管理全过程。更重要的是本书还将很多笔者多年积累的宝贵经验作为诫语醒目的分享给读者，而且整理成为目录，可以方便快速的为读者提供帮助！ -
很符合中国特色的软件需求过程，总结成SERU的形式，同时提供了诫语，对实践很有指导意义 -
需求工程的系统入门书。条理非常清晰。理论中穿插各种小事例，生动有趣。作者很用心。 -
需求设计要做得好还真是不简单。对于用画图的解说分析得挺细，其它的一般。 -
Felix Ding推荐的一本书，周末读了前三章，感觉很“顺”。 -
这本书应该是算100%的纯国货了,差不多应该算是我读过的在这方面的国产货中最出色的了.
从这本书中可以看出,本书的作者阅读了大量外国这方面的精华作品,对需求工程的理解也相当的深刻.
下面说一下本书的不足
1.虎头蛇尾
本书从一开始,章节内容逐渐增加,到第6章达到顶点,然后急转直下,每章内容迅速减少,越往后面写，越给人感觉是在敷衍.章节划分以及每章要写多少内容应该在最开始就规划好.
2.小故事
小故事这种形式已经被大量的运用在了外文书中,本书也学习了外文书的这个优点,不过编写故事方面还需要加强,很多时候我太愿意去读文中的小故事,读了之后感觉启发也不大.
3.结构
本书的结构很模糊.就我看过的外文书来看,结构一般分为三类,要么是总分的形式,要么是根据一个线索顺沿下来,要么是以一定的观点或者事件为中心独立成章.本书的结构组织哪一个也不象,给人有点混乱的感觉.依据本书所讲的内容,个人建议采用总分的模式.特别是依据现在这个结构,最后一章在我看来简直就是败笔,还不如直接放到附录中去.
4.细节
本书在具体细节方面还不够具体,给人更多的感觉只是在罗列事实,而非一个具体的指导过程,很多地方对方法的描述应该更细致,更具体.
5.错误
本书有些小地方犯了一些常识性的错误,不过影响不大.
不过,毕竟需求工程是个外来之物,国内对这方面的研究也没有国外时间那么的长,那么的精通,本书能做到这种程度,已经相当的不错了.
如果没有读过其他方面的关于需求工程的书，本书可以让你对需求工程有一个比较全面的认识和了解.读完这本书之后,然后可以去读<掌握需求过程>.如果已经读过了前面提到的那本书,那么本书可以用来选读,可以继续加深你对需求工程的认识和了解.