写需求分析必须牢记的5大要点
分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！
需求验证的5大要点
要做好需求验证，必须在思想、方法、语言、人员、内容5个要点上做好相应的工作，否则就会产生很多负面的影响。
1．思想
前面已经说过，由于Review被翻译成“评审”，导致很多人将其与中国人常说的评审相混淆，其实它们之间是有区别的：中国人常说的评审是评价，而Review应该是复查，是发现问题。这一点，必须成为所有组织、参加需求评审会的人员都应该建立的统一认识。
隐喻：
当测试团队严肃、认真地对你说：“经过我们三天时间的测试，发现你提交的程序一个Bug也没有！”请问你会作何理解呢？
A、我的程序很牛！
B、这个测试团队的方法或态度有问题。
我想很多人会选择B吧！因为“人非圣贤，孰能无过！”应该是测试手段还存在问题，导致潜在的问题没有被暴露。
可是，“我的需求评审通过了！”之类的话题总是被许多需求人员以很开心、愉快的方式说出来，我怎么听怎么觉得像听到“我的程序真牛！”。
就像我们不是想花大量的测试成本来验证自己的程序无错一样，采用成本昂贵的评审技术也不是为了验证需求文档是无错的，而是帮助我们尽早地发现问题、找到错误，避免因问题被延误到后期解决而付出惨痛的代价。
SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。
2．方法
统一了思想之后，接下来的重点就是“方法得当”。
SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。
3．语言
SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。
4．人员
要开好评审会，选择合适的参与人员是很重要的；要点在于合适，而不是越多越好。具体来说，包括三个方面的要点：
同级：别忘了，在CMM/CMMI中提到的是Peer Review，Peer就是同级，千万不要一开评审会就请高阶领导。
该来的人要请：也就是评审的内容所涉及的第一责任人，要想办法请他们参加。
不该来的人不要请：也就是评审不是越多人参加越好的，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。
SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。
5．内容
建议大家控制在9条之内，理由就是心理学中的“7±2” 原则，也就是人们容易记住的信息条目在5～9条之间。因此大家也可以根据实际的情况做一些变通。
除了要对缺陷检查表的规模进行压缩之外，还应该对评审的需求规格说明书进行压缩。根据笔者的经验，一个较熟悉的团队，要对需求进行相对有效的评审，应该控制在每小时30～40页之间。
那么在实际的工作中，我们如何对需求文档进行切分呢？是开一个时间周期很长的评审会，还是多次时间周期较短的评审会呢？似乎这两种方法都不尽可行。
解决该问题的关键在于必须对需求规格说明书进行拆分，根据读者的层次、所关心问题域的不同进行拆分，具体的方法我们在第4～6章中已经做了很多说明。
SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。
上述文字摘自于 徐峰老师 编著的《 软件需求最佳实践：SERU过程框架原理与应用 》一书
中国互动网购买地址：http://www.china-pub.com/209259
【书 名】软件需求最佳实践：SERU过程框架原理与应用
【作 者】徐锋 著
【ISBN】978-7-121-07395-3
【出版社】 电子工业出版社
【出版日期】2008年10月
【宣传语】
•经验密集，直击需求实践中各种问题。
•贯穿全书的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
SERU诫语目录
第1章 需求实践现状分析 2
SERU诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。 6
SERU诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益
SERU诫语1-2：（解决问题、创造机会、提高管控力等）的沟通。 6
SERU诫语1-3：缓解沟通失真最有效的方法是及时复述。 9
SERU诫语1-4：需求分析的本质在于业务分析，而非技术分析。 11
SERU诫语1-5：业务场景是需求之魂。 12
SERU诫语1-6：需求分析人员对于技术方法论的评价重在适用性。 16
SERU诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。 18
第2章 不同软件项目的需求视图 20
SERU诫语2-1：流程分析（业务事件）是OLTP系统的关键线索和主要视图。 23
SERU诫语2-2：报表分析是MIS系统的关键线索和主要视图。 26
SERU诫语2-3：决策场景是DSS系统的关键线索和主要视图。 29
SERU诫语2-4：工作场景是专家系统的关键线索和主要视图。 30
SERU诫语2-5：并行工作流是OA系统的关键线索和主要视图。 30
【书 名】软件需求最佳实践：SERU过程框架原理与应用
【作 者】徐锋 著
【ISBN】978-7-121-07395-3
【出版社】 电子工业出版社
【出版日期】2008年10月
【宣传语】
•经验密集，直击需求实践中各种问题。
•贯穿全书的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
SERU诫语目录
第1章 需求实践现状分析 2
SERU诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。 6
SERU诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益
SERU诫语1-2：（解决问题、创造机会、提高管控力等）的沟通。 6
SERU诫语1-3：缓解沟通失真最有效的方法是及时复述。 9
SERU诫语1-4：需求分析的本质在于业务分析，而非技术分析。 11
SERU诫语1-5：业务场景是需求之魂。 12
SERU诫语1-6：需求分析人员对于技术方法论的评价重在适用性。 16
SERU诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。 18
第2章 不同软件项目的需求视图 20
SERU诫语2-1：流程分析（业务事件）是OLTP系统的关键线索和主要视图。 23
SERU诫语2-2：报表分析是MIS系统的关键线索和主要视图。 26
SERU诫语2-3：决策场景是DSS系统的关键线索和主要视图。 29
SERU诫语2-4：工作场景是专家系统的关键线索和主要视图。 30
SERU诫语2-5：并行工作流是OA系统的关键线索和主要视图。 30
给我老师的人工智能教程打call！http://blog.csdn.net/jiangjunshow
