《软件需求最佳实践》读书笔记
2023-09-05 15:34:08 0 举报AI智能生成
登录查看完整内容
《软件需求最佳实践》全文读书笔记，有想体系化学习需求分析的同学可以了解下
作者其他创作
大纲/内容
需求问题成为项目成败关键因素
需求规格说明书应该采用业务导向的树型层次结构来组织
1.不完整的需求
对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通
2.缺乏用户参与
主动地帮助用户更好地理解软件的成本
3.不切实际的用户期望
4.需求变更频繁
基于业务领域知识来衡量需求的必要性和充分性，在最开始有效地划分优先级
5.提供了不再需要的
需求相关败因简要分析
仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化
●文档
最简单、最有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真
●Review
1.沟通失真
一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高
● 客户希望支付的成本尽可能少，获得的效益尽可能多
调研需求时少问What多问Why
● 解决方案的选择权交给了不熟悉技术的客户
2.客户的需求放大
应该以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识
●项目经理经常会从技术的角度来对需求进行控制
3.项目经理的需求控制
需求分析的本质在于业务分析，而非技术分析
4.分析人员的技术加工
业务场景是需求之魂，除了描述清楚需求本身，也要将业务场景带入
5.编码人员的断章取义
需求“迷途”
1.1 软件项目失败的根源
说明需求描述与沟通有问题，导致需求在交流的过程产生失真；因此应该加强需求过程的管理，加强沟通手段的管理
● 需求变更是对原有需求的背离
说明需求捕获有问题，需求不完整；因此应该加强需求捕获方法的组合应用，加强对业务模型的梳理
● 需求变更是对原有需求的补充
说明需要采用工作流引擎
● 需求变更集中在流程间
说明需要开发用户界面动态生成器
● 需求变更集中在用户界面方面
...
1.2.1 需求变更频繁
直接提交给客户方的高层，减少开发团队的压力
1.利益冲突
● 提高易用性
● 工作量价值化
● 将数据迁移、准备工作独立出来
2.工作量增大
1.2.2 上线阻力大
要成功地实施一个项目，首要工作就是在客户方为项目找一个爹
● 从问题或机会入手，提高管理人员的推动力
● 从障碍和困难出发，解决操作人员的积极性
1.2.3 运行效果差
未调研分析清楚非功能性需求
1.2.4 完全崩溃
1.2 透过表象，分析本质
1.3.1 C/S还是B/S
标准瀑布式方法论
敏捷方法论
1.3.2 软件工程方法论
1.成熟度
2.溯源
3.了解局限性
1.3.3 开发思想
1.3 方法论与需求工作
透过表象、分析本质，努力分析、总结经验，真正做到“前车之鉴，后事之师”
1.4 小结
第1章 需求实践现状分析
子主题
1.信息系统的本质：数据信息化
● 联机事务处理系统是数据的生产者
● 管理信息系统是数据的消费者
● 主管信息系统、决策支持信息是数据的高级消费者
● 专家系统是对个人知识的沉淀，同时也是数据的消费者
● 办公自动化系统是对沟通与协作的直接支持
2.信息系统的类别
2.1.1 信息系统的本质与分类
信息系统是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业的日常运作，并支持管理人员和用户解决问题和做出决策
2.1.2 联机事务处理系统——流程电子化
2.1.3 管理信息系统——数据信息化
2.1.4 其他信息系统
2.1.5 信息系统的多维视图
2.1 信息系统的需求视图
2.2 嵌入式系统的需求视图
诸如进销存、ERP、OA、财务电算化等软件产品
1.信息系统类
基于使用场景的困难点分析是工具软件的需求要点
2.工具软件类
2.3 软件产品的需求视图
第2章 不同软件项目的需求视图
那是在项目立项阶段整理的，也就是需求定义的产物。
1.业务需求
用户需求是需求捕获的产物
2.用户需求
业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物
3.软件需求
3.1.1 需求的三个层次
功能需求的要点在于如何组织
1.功能需求
非功能需求的要点在于保证信息的有效传递和注意其局部性
2.非功能需求
（1）非技术因素决定的技术选型
（2）预期的软硬件环境
（3）预期的使用环境
3.设计约束
3.1.2 需求的三种类型
业务导向的层次结构是保障完整性的关键
（1）用户才是验证需求完整性的合适人选
（2）需求完整性存在不同层面
1.完整性
正确性
无歧义性
要确保需求不失真，加强需求的验证是关键手段；但在做需求验证时首先要认识到“验证是质量关”，尽可能多地暴露出问题才是关键
2.不失真
引导用户对需求的优先级进行划分
（1）优先级有不同的角度
（2）必要性是优先级评价的盲区
3.有优先级
需求规格说明书的读者是谁呢？就是开发团队和测试团队
可行性
可验证性
4.有技术早期介入
完整性、正确性、无歧义性、必要性、有优先次序、可行性、可验证性7个
3.1.3 优秀需求的标准
3.1 什么是软件需求
需求开发是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的需求规格说明。
需求管理则是对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足这些需求
3.2.1 需求工程的范畴
捕获范围不足
缺乏计划性
缺乏科学性
捕获对象不明确
捕获手段不足
在需求捕获活动中，化被动为主动是关键。
1.需求获取
需求分析的任务是对问题域进行研究，因此将从业务线索入手，而非系统结构
需求分析是业务分析
也就是将待开发的系统按职责划分成不同的主题域，然后分解成组成该主题域的所有业务流程，再分解到业务活动（用例）、业务步骤
需求分析是一种分解活动
需要将用户的原始需求合并到业务活动中去，要将各个业务流程合并成全局业务流程图，要将每个业务事件相关的领域类图片面合并成全局领域类图，要将各个业务事件的用例图片断合并成全局的用例模型等
需求分析是一种提炼与整合活动
也就是要找到冲突、矛盾，并且通过访谈等手段解决这个问题
需求分析是一种规格化活动
需求分析就是向下分解+向上提炼，外加一些规格化
（1）需求分析是什么
需求分析是目标，需求建模是手段。
（2）内容与形式
（3）何时开始、何时结束
2.需求分析
软件需求规格说明书总结了四字要诀：共享、更新
可获得
也就是确保软件需求规格说明书的读者能够知道他要的信息在哪些章节中，这需要通过符合团队特色、开发方法的模板来保障
可获知
（1）共享
也就是确保开发团队在需要阅读软件需求规格说明书时能够马上获得最新的版本，这需要通过行之有效的文档管理来实现。
需要为软件需求规格说明书指定专门的更新人
专人更新
写作风格
（2）更新
3.编写规约
需求验证的关键手段是评审，而且要注意分层次、分内容进行验证，以期在早期阶段尽可能多地暴露出问题
4.需求验证
3.2.2 需求开发工作要点
需求管理工作包括基线管理、变更管理和需求跟踪
每个需求项的大小（也就是工作量）是相当的，换句话说，衡量工作量时采用的单位（人月、人周、人天）是相同的
粒度均匀
将需求项划分到多大是合适的呢？这取决于你的管理粒度。如果采用的是迭代、增量的开发过程，那么通常每个需求项所需的工作量应该是以人周作为单位的；如果要对迭代内的开发做进一步的控制，就需要再拆分成更小的需求项，工作量应该是以人天为单位的
大小合适
最低一级的需求项应该涵盖所有的开发任务，也就是说，应该包括基础设施、复用控件等技术特性
完整
1.统一、明确的需求项划分标准
开始开发的基线内的需求（Baseline）
没有安排开发的待处理需求（Backlog）
一是确立优先级，确保高优先级、高风险的需求项在尽早的迭代中完成；
二是工作量估算，以确保每次迭代的时间安排是紧凑的；
三是未完成项的合并，每次迭代还是可能有某些工作未完成，在分配下一次基线时就需要将其考虑进去
基线划分需完成三个方面的事情
2.引入基线管理
从业务角度对变更的合理性、优先级以及对原有需求的影响进行分析，以便决定是否将其纳入Backlog中；如果决定将其纳入Backlog，还需要确定其优先级。
● 业务影响分析
从技术角度对变更的影响范围、工作量进行分析，并且决定是拒绝、在后续迭代中进行响应，还是在本次迭代中对其进行响应。
● 技术影响分析
基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大的影响。
● 项目影响分析
3.引入变更管理
4.引入需求跟踪
3.2.3 需求管理工作要点
是需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道
职责
定义业务需求
确定项目涉众和用户类别
获取需求
分析需求
为需求建模
编写需求规格说明
主持对需求的验证
引导对需求的优先级划分
管理需求
完成的活动
分析、协调、观察、写作、组织、建模
业务知识
技术知识
倾听、交谈和提问的技巧
人际交往和创造能力
沟通能力
掌握技能
3.2.4 需求分析人员的技能组成
SERU 模型
需求定义阶段就是项目的立项阶段，也与RUP的初始阶段相对应；对于需求分析人员而言，该阶段的核心目标在于定义目标和范围。根据SERU模型的总结，该阶段的任务就是划分Subject（主题域[插图]），并标识出每个主题域中的Event（业务事件）和Report（报表类型）。
● 需求定义阶段
相当于需求捕获、分析与建模的阶段一，对应于RUP中细化阶段的第1次迭代。根据SERU模型的总结，该阶段的任务就是对每个业务事件（它是业务流程的触发点，因此换句话说，就是分析业务流程）、每类报表进行事（流程分析，只针对业务事件）、物（业务实体）、人（使用角色）分析，并标识出绝大部分用例。
● 理清脉落阶段
相当于需求捕获、分析与建模的阶段二，在RUP中将从细化阶段的第2次迭代开始，直到构建阶段完成。根据SERU模型的总结，该阶段的任务就是填充每个用例的实现细节，以便开发人员进行具体的实现。
● 填充细节阶段
3.2.5 SERU模型概述
3.2 需求工程解析
第3章 软件需求与需求工程
第一部分：原理、模型与误区
拍脑袋
拍拍你肩膀
拍胸脯
拍桌子
拍大腿
拍屁股
六拍项目经理
清晰的项目目标和范围定义，能够引导需求工作顺利进行
4.1.1 需求定义的时机
当你看到一个比较虚空的目标时，首先可以尝试提出在项目的企业/组织内部寻找真正的项目发起人，和这些项目发起人的深入沟通是进行需求定义的第一步
（1）内部寻根
对于外部因素所激发的项目，需求定义时要找到目标参照物，通过对目标参照物的分析与了解，就能够很好地做好需求定义工作。
（2）外部溯源
1.破解混沌不清的项目目标
要么是解决问题的，要么是创造机会的
采用Goals（目标）→Problem（问题）→Option（可选方案）→Answer（建议方案）
问题、机会
2.需求定义的理念
4.1.2 需求定义的理念与策略
4.1 需求定义任务概述
需求定义阶段要善于将未知解问题转换成已知解问题。
将客户的需求转换成自己的已有产品；而不是简单地全部重新开发
（1）转换
在确定某问题的解决方案时，一定要思考是否会引发新问题
直接修改错误，不要用其他方案来弥补错误。
关键在于对问题的定义，先确定这里到底存在什么样的问题
（2）本源
1.问题定义的技巧
2.影响人群分析的技巧
4.2.1 在问题定义上达成共识
在问题被定义出来之后，接下来要做的就是分析问题背后的问题，也就是寻找问题的本源
1.鱼骨图
2.帕累托分析
鱼骨图为解决问题找到了靶子，帕累托图则标上了环数
4.2.2 分析问题背后的问题
Stakeholder背后的含义是：项目是一个博弈的游戏，有很多人都拥有相应的筹码，项目经理的目标就是尽可能多地获得筹码，只要获得的筹码足够多，项目就将获得成功。
你们的团队和哪一层客户打交道最多？
很简单的项目健康度评价方法
1.Stakeholder解析——筹码持有人
用户实际上也是Stakeholder的一类，他们是直接使用系统的人群。由于他们直接作用于系统，因此需要了解他们的特点、能力，所以就将他们单列出来。
2.用户分析
4.2.3 确定相关人员和用户
范围是指系统涉及哪些内容，而边界则是系统与人的职责边界
1.范围vs边界
2.确定边界
用户永远会希望花同样的钱，获得尽可能多的功能
3.边界谈判
4.创新边界
4.2.4 定义解决方案的界限
4.2.5 确定加在解决方案上的约束
4.2 问题分析的五步法
1.POS类
SWOT（优势、劣势、机会、挑战）等市场分析的内容
2.Vision类
4.3.1 需求定义的产物
● 必须是具体（Specific）的：目标必须能够指导具体的工作；
● 必须是可以度量（Measurable）的：这样才能进行成本/效益分析；
● 必须是可以达到（Attainable）的：否则是没有意义的目标；
● 必须和其他目标具有相关性（Relevant）；
● 必须具有明确的截止期限（Time-based）。
1.目标——SMART原则
2.范围
需求阶段描述的是用户的能力特点，旨在提高可用性。
因为只有了解用户的能力特点，才能够真正提高软件的可用性，因为可用性是相对而言的
你可以不做一件事，但一定不能不知道为什么需要做这件事
除了用户之外的相关人员则需要了解他们对软件系统的关注点，想通过系统获得或实现什么利益，这些信息对于项目实施过程而言是十分有价值的
3.相关人员与用户
4.相关事实与假定
4.3.2 需求定义的要素
4.3 需求定义的产物与要素
4.4.1 案例说明
在分解系统时，应该按业务的脉络来划分成不同的主题域
1.什么是主题域
各个主题域之间的服务接口是需求变更的防火墙
2.为什么使用构件图
前面已经说过，在划分主题域时应该从职责划分的角度来思考；换句话说，组织结构是划分主题域的重要参考，通常主题域的边界恰好就是部门的边界
● 以组织结构为线索
在划分第一级的主题域中还有一个技巧，那就是观察分管领导的设置。例如在本例中，可以观察该医院设置了多少个副院长，或者思考如果你是院长会设置几个副院长
● 从分管领导中找突破
例如，很多企业/组织中都有自己的产、销、供环节，这也是一条很有用的思路
● 借鉴典型的业务职责区块
3.主题域划分技巧
4.4.2 划分主题域
上下文关系图
4.4.3 确定主题域范围
业务事件是直接作用于系统的，也就是将触发系统行为
业务事件应该是主动触发的，并且将会产生一系列后续行为
业务事件是业务流程的触发点，标识出业务事件能够帮助我们识别出业务流程；
1.业务事件解析
因此业务流程的信息是掌握在中层管理人员手里的，它属于脉络信息
业务流程是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门、不同岗位协作完成的。
2.业务流程
因此业务活动和业务步骤的信息是掌握在操作层人员手里的，它属于细节信息
业务活动则从属于一个特定的业务流程，它是一个人的活动，因此一个业务流程应该是由一个或多个业务活动组成的
3.业务活动
业务步骤是完成某个业务活动所需要的具体步骤
4.业务步骤
业务事件
当业务事件标识出来之后，我们可以在此基础上分析潜在的报表类型
应该通过与用户代表（以中层管理人员为主）的访谈来确定所需的报表类型。关键在于从管理意图的角度进行梳理，以事、物为线索
报表
4.4.4 标识业务事件与报表
先从主题域划分，然后每个主题域一个小节，分别阐述业务事件和列表需求
（1）Word文档组织示例
img src=\
（2）Rose组织示例
4.4.5 生成需求大纲
4.4 定义需求范围
第4章 需求定义最佳实践
需求捕获是撒网打鱼，不是休闲钓鱼
其实问题的关键在于需求分析人员是否善于去把握主动权，是否能够根据每次访谈的对象制定相应的计划
5.1.1 需求捕获应该是主动的
善于聚焦访谈话题是需求捕获人员成功的关键。
5.1.2 需求捕获应该是聚焦的
这是位于海平面上的部分，通常是一些困扰用户的问题、用户自己能够设想得到的功能；但如果只知道捕获这一层信息，就不能够算是一个合格的需求分析人员，因为这将导致大量的需求将以变更的形式出现
● 意识到的需求
它是用户的实际工作场景，开发人员如果能够对这些场景做到“感同身受”的话，那么就可以大大减少变更的数量，而且能够开发出更加合理的解决方案。因此这是每一个合格的需求分析人员都应该做到的，具体的方法就是加强对业务知识的捕获
● 无意识的需求
用户对技术解决方案永远都不是最擅长的，因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分理解的基础上，选择合适的技术方案，才可能创造出用户未梦想到的功能，能够做到这一点就可以称为优秀的需求分析人员
● 未梦想的需求
5.1.3 破解需求的冰山模型
在很多的需求捕获活动中，我们总会遇到一些喜欢夸夸其谈的用户，说出来的流程都是很理想化、很规范化的
通过比较用户代表的表述来识别言过其实，利用差异展现、瓶颈分析法来缓解影响
1.言过其实心理
要解决这个问题，关键在于需求捕获人员能够识别出正确的被访谈者，也就是回答你要问的问题最佳的人选是谁
● 问题的层次是否正确：高层管理人员解决宏观问题，中层管理人员解决脉络问题，操作者解决细节问题
● 根据业务背景判断：也就是有效地识别该问题所针对的业务环节是由谁负责处理的？执行者往往是回答问题的最佳人选
针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。
2.越俎代庖心理
离开办公室、对访谈进行计划是避免非正事现象的主要手段
3.非正事心理
抗拒心理的典型表现，这在操作层的用户中最为常见。原因很简单，很多信息系统对于操作层而言效益并不明显（开发人员也不关注于此），而且经常还会使其工作量有所增加，并且还带来了许多培训的负担。
化敌为友是缓解抗拒心态的主要方向
倾听对方的抱怨是化敌为友的有效手段之一
4.抗拒心理
由于信息系统在企业/组织中并没有被广泛认同，因此很多人会抱着“事不关已，高高挂起”的态度。而且最令人为难的地方在于：他们说没有需求，你也不好多说什么，因为这只是能力的问题，不了解信息系统并不是错。
突破推卸责任心理的简单手段是让被访谈者介绍工作场景
5.推卸责任心理
5.1.4 破解阻碍需求捕获的心理现象
需求捕获时不要忽视对变更可能的了解。
5.1.5 不要忽视对变更可能的捕获
随着人们学识、经历的不断增长，其讲话时就会更偏向于说解决方案，而不会直接说出问题。这种心态对于需求捕获活动而言，显然会造成障碍。
why？看来“不直接说问题，而是说解决方案”的现象并不少见，那么面对这样的问题，我们应该如何解决呢？其实方法很简单，答案只有一个符号，那就是“？”。什么意思呢？就是要善于问为什么
选择解决方案的最佳人选是我，用户代表所需要做的只是把问题说清楚
在需求捕获时要善于使用“？”之箭，找到真正的需求。
1.揭开解决方案后面的问题
当真正了解了对方的利益诉求时，我们可能会找到许多折中的方法，它所带来的问题或许就不会太大了，也是双方可以接受的
“拨开立场，寻找利益诉求”是需求协商的要点。
2.共赢性谈判
特别是基于自有产品作定制开发的团队而言，应该尽可能将用户的需求转换成已实现的产品解决方案
在需求捕获中，如果用户代表有意无意地不指定优先级，或将所有需求都置为高优先级时，就可以采用这一策略。具体来说，就是选择一个其上层领导提出的、他也知道的需求来比较！如果这个需求并不是那么紧急，通常他自己就会放弃；如果这个需求对方一定坚持，就说明了它的不可或缺性。
不要孤立地看待需求项，应该将所有需求视为一个整体。
（1）相对重要→相对次要
事物都具有多面性，都各有优劣；而关注点转换的核心思想就是利用其多面性，引导对方向有利于自己的关注点进行思考，从而为自己赢得机会
当然并不是要把每张牌都变得王牌，而是变成可接受的牌，其关键技巧在于给它创设场景，让人们从你引导的角度去审视
“环境”将改变结果，切换不同的视角会得到不同的认识
（2）关注点转换
隐喻就是打比方，是用对方熟悉领域的事物来解释深奥问题的手段，它也是转换技巧中最精彩的一个
生活是最好的老师！只要你细心观察生活，就能够找到许多生动的隐喻，为沟通建立良好的基础
善于打比方是提高跨专业沟通效果的好方法
（3）隐喻
3.转换技巧
5.1.6 需求协商
5.1 需求捕获的策略
用户访谈的优点是直接有效、形式灵活、交流深入的宽带通信形式（有文字、有声音、有图像）
优点
● 占用时间长：通常要访谈人的比较多，而且语言交流会占用大量时间，因此我们更应该注意有效利用用户访谈的时间。
● 信息存在片面性：这点是很多访谈者没有意识或注意到的，用户代表经常各执一词，从而导致收集的信息无法代表所有用户的想法，从而导致偏差的出现。
缺点
1.优缺点与使用时机
访谈的线索是因“人”（用户类型）而异的。
2.用户访谈的类型
一般来说，一次用户访谈的时间应该控制在1小时以内，如果时间不够用可以考虑中场休息或者安排下一次访谈
用户访谈的时间安排
● 思维比较发散：那么就可能会把话题带得过偏，从而导致占用了大部分时间；这种情况下就应该尽量回归到预先计划问题上，先保证不遗漏这些问题，再对即兴问题进行处理。
● 思维比较聚焦：有些客户是比较有控制力的，他们会控制话题，这时可以适当地穿插即兴问题。
在实际的访谈过程中，预先计划问题和即兴问题有时并不需要截然分成两个阶段。具体来说，可以根据被访谈者的特点来决定
另外，为了避免访谈过程中受到外界的干扰，应尽可能选择诸如会客室、洽谈室等相对封闭、不易受干扰和被打扰的地方进行访谈，特别应该尽可能避免办公室
3.用户访谈的时空安排
最好有两份保险腾讯会议录屏+现场专人记录
4.用户访谈中的记录工作
尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。
2天前、1周内！时间太短，那么被访谈者很可能没有时间准备；访谈的时间太长，就会让被访谈者认为这事还早而置于一边
（1）制作访谈问卷并事先发给被访谈者
访谈者要注意谈话中心是“业务”，而非“技术”
明白自己是一位倾听者，交流的模式是“问问题，听取回答，然后反馈理解”
信息流向是“被访谈者→访谈者”，因此切忌喧宾夺主，导致获取的信息过少
访谈者说话的总时间应该控制在三分之一以内
● 沟通过程不是写文章：沟通时应该尽可能使用短句
● 不要问过长的问题；更应该避免将多个问题一次性提出。
（2）把握语言节奏
封闭式问题（判断题）
半封闭式问题（选择题）
开放式问题（简答题）
（3）有效结合不同的问题类型
● 金字塔结构
● 漏斗结构
● 菱形结构
（4）善于安排问题顺序
用草图绘制模型（DFD数据流程图、用例、思维图）
在需求捕获时别忘了“一图抵千言”这句经典提示。
● 让模型成为访谈过程中的工具
在访谈的过程中，如果访谈者情绪控制不足的话，很容易出现“我的时间比你的宝贵”、“我不知道你在说什么”的暗示，这将会对访谈过程产生巨大的干扰
你是专业的，你要想办法引导用户，而不是否定或轻视用户
● 避免出现一些干扰访谈的暗示
经常会出于“面子问题”而造成“不懂装懂”现象的出现，这样就会造成沟通障碍，产生对术语理解的偏差。因此应该勇敢地问对方：“你刚才说的这个东西是什么意思，表示什么”，这样就能够更好地在业务专门术语的理解上达成共识，为之后的业务实体分析打下基础。
虚心请教，业务人家是专业的，不用好于面子
● 注意消除“隔行如隔山”的术语影响
● 善于观察异常现象
在上一小节中我们已经说过，需求捕获是一个网罗活动，也就是说，访谈时一定要就预先计划的问题逐一得到解答，因此在访谈过程中需要不断地检查，以确认没有遗漏的问题
另外，在访谈结束之前应该询问“你认为我还应该了解些什么问题？”、“你有什么问题要问我吗？”之类的问题。
● 不要遗漏问题
（5）注意沟通的细节
5.用户访谈中的沟通技巧
● 计划时间、人员
用户访谈是一个有计划的、科学的过程
在进行需求访谈计划时，一般需要罗列出访谈要点与背景、访谈人的基本情况（姓名、岗位、联系方式）以及预先计划的问题，然后针对不同的访谈人分别整理一份如下所示的访谈计划
计划模版
● 计划内容
6.用户访谈计划
5.2.1 用户访谈
用户调查能够有效克服用户访谈中存在的片面性。
也就是先设计一个通用的问卷，从问卷的结果中梳理出一些关键点，然后选取一些用户代表，进行更有针对性的访谈。
● 先调查，后访谈：
也就是先筛选出一些典型的用户代表，然后对访谈的结果进行整理，在这些结果的基础上设计相关的调查问卷，通过调查来验证用户访谈的结果是否具有普遍性。
● 先访谈，后调查：
● 问题应该按由易到难的顺序排列
● 问题排列应该注重逻辑相关性
（1）注意问题的篇幅与布局
在需求调查问卷中应该尽可能避免使用封闭式问题，因为这类问题很容易诱导被调查人，从而产生不准确的结论。而解决的方法，就是用半封闭性问题来代替它。
也就是尽量让开放式问题跟随在相关封闭式、半封闭式问题之后；因为这时用户在脑海中有一些答案，填写出来的可能性就会大大增加。
● 跟随策略
● 保持简单
（2）注意问题类型的选择
● C现象
● D现象
（3）封闭式问题相关的两个小技巧
2.用户调查问卷设计要点
● 筛除无效问卷
● 对问卷的填写人进行分类
3.用户调查问卷的分析要点
5.2.2 用户调查(问卷)
文档考古也称为文档研究，它是一种比较贴近现实的技术。它的好处是能详细、直观地对数据流细节进行了解与分析。而缺点也很明显，由于在企业/组织中，文档量通常是很大的，因此容易使需求捕获人员陷入文山书海之中不可自拔，甚至常引起误导。
那么文档考古这种捕获技术应该在什么时机下使用呢？这就需要回答前面让大家思考的问题了！是的，文档考古恰好填补了用户访谈、用户调查技术在数据需求上的不足，它就是研究、分析、细化数据需求的主要手段。
为什么这么说呢？因为数据需求通常比较琐碎、趋于细节信息，因此不要期望用户能够将其记在脑子里，这些信息往往寄生于各种类型的文档中。
很多系统在实施的时候就是简单地把原来纸质上的流程搬到计算机上，并没有有效利用信息化工具对流程进行适当的改良。
分析文档资料时应该思考新流程对其的影响。
收集文档时，应该尽可能让用户提供带有真实数据的样本。
（1）注意文档的历史性
需求捕获人员要善于根据流程分析的结果主动收集相关文档。
（2）化被动收集为主动索取
2.文档考古的使用要点
5.2.3 文档考古
其优点就是用户友好、交互性，对用户界面提供了早期评审；
而缺点也十分明显，那就是花费的时间很多，使需求捕获的速度大大降低。
需求捕获的过程中虽然很大的一部分精力在于理解业务、分析业务、了解潜在的问题，但仍然不可避免地涉及一些解决方案的探讨，因为只有让用户了解你将如何解决时才会更容易达成共识。
就是用户的使用场景。
情节串联板应该以业务场景作为展示的主线索。
（1）确保以“情节”为线-场景
用户不仅仅关心用户界面的样子，更关心用户界面的流转过程、交互过程。因为交互过程是对工作任务的最好回答。
交互才是情节串联板的本质，不要只关注于界面的静态效果。
（2）理解“串联”的本质-交互
2.情节串联板的使用要点
5.2.4 情节串联板（原型法）
现场观摩技术的优点是：百闻不如一见，能够对需求与业务流程建立直观的认识
而缺点则是消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真
现场观摩技术能够使开发团队实现对业务场景“感同身受”。
优点是可用于发现异常的、关键性的任务
缺点是“示范”失真、耗时。
● 任务示范：也就是要求用户示范如何执行特定的任务；
● 做学徒：也就是和用户坐在一起，通过观察、问问题，并在用户指导下完成一些工作来学习。
2.现场观摩的常见变体
● 避免失真
● 不要看电影
录像、拍照
● 有条件的情况下，建立可重复观摩的场景
3.现场观摩类技术的使用要点
5.2.5 现场观摩
优点在于客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段
缺点则是成本高，如果缺乏控制会变成一次闲扯大会
● 项目启动初期
● 关键主题域、功能块的专项探讨
什么时候应该组织联合开发呢
联合开发是突破双方需求盲区的有效手段。
● 在理念上建立共识
出现“上面开大会，下面开小会”现象，一半责任在组织者。
● 确保真正的Stakeholder参与
● 准备好相关资料
● 准备好后勤保障
（1）会前有准备
在联合开发会议中，控制的是氛围、控制的是进程。
（2）会中有控制
没有总结的会议是没有效率的会议，但会议的总结是十分需要技巧的，一些形而上学的总结等价于没有总结
● 首先安排一位全程不参与讨论的记录员，由他负责对会议中大家提出的观点做好记录。这位记录员必须有技术背景，而且对大家所谈论的内容有较好的理解能力。
● 记录时千万不要采用“流水账”的格式，也就是大家所熟悉的诸如会议时间、地点、参与人员，以及按大家发言的顺序记录大家说的内容。而是将大家提出的观点以条目式的形式记录下来，可以是一个观点一个Excel行，可以是一张卡片。
● 在会议结束之前的最后一项议程安排给他，也就是将主持权交给这位一直没有说话的记录员。
● 他首先把记录下来的观点列表展示出来，大家先对其中一些价值很低的（因为头脑风暴经常会产生这样的东西）去掉。
● 然后把去除了低价值观点的列表拿出来，大家对它进行分类。
● 最后对每一类进行投票，排列出优先级，并把生成的结果发给所有的与会者。
这样处理之后，所有讨论到的观点就将被有效地整理出来，而且能够使大家获得共同的认识，有利于需求团队对其展开进一步的捕获和验证，使会议的结果最大化地利用起来。
（3）会后有总结
2.联合开发的使用要点
5.2.6 联合开发
5.2 需求捕获的主要方法
沟通决定内容，内容决定格式
5.3.1 工具的选择与定义
5.3.2 任务卡片
需求分析人员可以根据这些信息来进行抽象（其中加粗的字就是主要的线索）整理出子任务。这种场景描述可以在编写测试用例、用户培训材料时再次用到。
5.3.3 场景说明
Volere白卡
用户故事
5.3.4 其他工具
5.3 需求捕获的记录工具
● 主动性：始终别忘了需求捕获的目标是尽可能多地收集信息，在整个捕获过程中要确保有效地捕获方向、内容的控制性。
● 计划性：需求捕获应该是有计划的过程，要注意时间、人员、内容的计划，才能够更加有的放矢。
● 科学性：任何信息都有宏观和微观的部分，而且这些信息都是掌握在不同人手里的，先在宏观层面搭框架、建脉络，再到微观层面填细节是重要的思考方式。另外，要善于根据不同的需要、场景选择合适的需求捕获技术。
需求捕获的目标是为需求分析阶段收集足够的信息，而需求分析的过程又会发现一些信息的缺口，“白天捕获、晚上分析”的比喻指出了它们之间的紧密相关性、周而复始性，分析的结果将为下一次捕获指明方向。
需求捕获过程要点
5.4 小结
第5章 需求捕获最佳实践
需求分析的任务并不是分析系统如何实现用户的需要，这种认识是对需求分析最常见的误解。需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。
需求分析就是先分解，再提炼，在这个过程中消除矛盾。
目标系统→主题域的分解依据的是“目标决定范围”，主题域→业务事件、报表类型所做的是理清脉络，从业务事件→业务活动、报表类型→报表所做的是填充细节。这种分解结构笔者将其命名为SERU，也是本书最推荐的分解方式
（1）业务流程为主线索的分解结构
正如前面所说，这种分解结构一直以来是在需求分析过程中最常用的，但它过早进入了程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。因此，这种方法只适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等
（2）程序结构为主线索的分解结构
对于决策支持系统、面向用户的嵌入式系统而言，决策场景、使用场景就是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的关注点或功能域；而向下可以分成具体的决策步骤或操作任务
（3）基于场景的分解结构
前面几种分解结构虽然各自角度不同，但都是从“事”的角度来组织的。但对于诸如数据仓库之类的数据类项目，“事”这条线索并不明显，或者并不重要，这时就需要采用以数据为主线的分解结构。其中主题域仍然和第一种结构相同，而主题类是企业中的高层实体，它将由一组企业逻辑数据类来表示，而企业逻辑数据类在实现时又会对应于多个物理数据类。
（4）基于数据的分解结构
选择了一个合适的分解结构之后，就可以把需求规格说明书的大纲确定下来，知道应该捕获什么信息；因此当信息捕获回来后，需求分析的任务就是将其填充到相应的级别上，并不断验证是否已经填充完成。
（5）小结
1.分解
分解是一种自顶向下的方法，当你按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。
当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此我们还需要采用自底向上的方法进行提炼。例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。
2.提炼
在这样的分析过程中，显然会发现有些需求是相互矛盾、相互冲突的。由于你是在把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，你就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。
3.消除矛盾
6.1.1 需求分析到底做什么
建模最大的好处在于：更好地理解正在开发的系统。
目的是：帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化。
1.建模的目的
要注意：设计要考虑到计划之外的变化；
设计要文档化，这样才能够使不熟悉的新手也可以有效地利用这个设计；
用可视化的模型表达架构，有助于理解变化所代表的含义。
不过，切忌“为了建模而建模”，如果模型不能够对软件系统的构建起到帮助作用，那么就是一种人力资源的浪费。
要点
● 选择创建什么模型对如何动手解决问题和如何形成解决方案有着深远的影响；
● 每一种模型可以在不同的精度级别上表示；
● 最好的模型是与现实相联系的；
● 单个模型是不充分的，对每个重要的系统最好用一组几乎独立的模型去处理。
原则
2.建模的要点与原则
6.1.2 建模的目标与要点
建模的要点是根据要完成的任务选择合适的建模工具。
1.正确认识建模方法论
随着面向对象编程（OOP）的出现，逐渐催生了面向对象设计（OOD）、面向对象分析（OOA）技术的出现。
● 已进入全面应用阶段的事实标准
● 应用领域正在逐渐扩展
● 成为“产生式编程”的重要支持技术
（1）UML的发展历史
● UML是一种Language（语言）
不是用于编程，而是用于建模
不仅仅包含软件建模的功能，实际上它还包含了业务建模、流程建模等其他的多种应用领域
● UML是一种Modeling（建模）Language
OMG组织认可的工业标准
是得到了IBM、Sun、Borland等众多大型公司支持的事实标准
● UML是Unified（统一）Modeling Language
UML本身不是方法论。
（2）UML的准确理解
统一的、标准化的建模语言
参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造。
不仅可以用于软件系统建模，还可以用于业务流程、业务知识、数据库、嵌入式等多个领域；而且对于不同的领域，其所采用的本质元素是相同的
不同的人们就可以基于相同的语言沟通；不同的领域模型就可以通过相同的机制进行互换与迁移。这就是统一的优势
（3）为什么要用UML建模
根据UML 2.0标准，一共定义了13种不同的图
需求阶段使用的图
（4）如何选择UML图
2.正确认识UML
6.1.3 选择建模工具的要点
6.1 需求分析与建模的要点与误区分析
针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系
了解这些业务活动需要接受哪些信息，将产生哪些数据（表单），确定数据传送的路线
同时标识出业务活动是由哪些部门、岗位负责等信息
注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的烦琐及反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节
1.业务流程分析任务概述
业务流程是对信息系统进行“庖丁解牛”的核心线索。
流程是针对要达到的目标进行设计的，换句话说，流程是一个整体，或许从一个局部来说是低效的，但目标是整个流程的高效，是为了更好地满足用户的需要
● 目标性
也就是流程本身是一个高内聚的整体，它是一个很好地分离业务耦合点的线索
● 内在性
通常流程是由多个业务活动组成的，分析的要点在于确定业务活动之间的关系
● 整体性
流程是行为流，不是一个静态的快照，而是一个顺序的行为流
● 动态性
组成流程的活动本身也可以是流程，这也经常困扰进行流程分析的需求人员。其实要点在于理清流程的层次，通过逐层嵌套的形式理清脉络
● 层次性
流程之间的关系主要包括串联、并联和反馈三种
● 结构性
（1）流程的6大特性
解决流程变化的问题关键在业务上的梳理
（2）工作流实现的本质
● 流程应以产出为中心，而非任务为中心
● 让那些需要得到流程产出的人自己执行流程
● 在决策点位于工作执行的地方，在业务流程中建立控制程序。
● 流程多样化
● 单点接触客户
（3）流程设计的原则
● 清除不必要的运输
● 整合供应商
（4）流程改进的ESIA策略
2.业务流程分析与流程管理理论的关系
三大层次:流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括
● 部门级
● 组织级
● 岗位级
（1）流程是有层次的
● 生产性流程
● 管理性流程
● 支持性流程
（2）流程是有类型的
Visio
● 跨职责流程图
Rose、Together
● 活动图
● 数据流图（DFD）
应该根据项目的特点和团队的技能情况选择合适的模型。
（3）流程分析的产物
3.业务流程分析的要点与产物
● 流程名称
● 职责带区
● 流程阶段
长方形表示的“业务活动”，它表示一个岗位执行的一个原子级活动
菱形表示的“判断”、“审批”，它是一种条件分支
燕尾切口的“文档”，表示活动之间传递的文档、表单等信息
● 流程元素
● 并行
● 流程引用
其他元素
（1）跨职责流程图的主要元素
要真正保障绘制出来的跨职责流程图是真实、有效的，就必须强化用户的参与
应该先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动，说明活动的执行岗位以及它们之间的关系、数据传递。在这个过程中，我们应该尽可能地在访谈的过程中及时地绘制出流程图，及时地进行验证，这样才能最为高效地达成共识
第一是善于、敢于抛弃细节，不要过早地钻研到业务活动的具体步骤中，这样必然会导致流程图的规模被扩大了，也就破坏了此目标的达成
第二个是抛弃一次成型的思路，不要精雕细琢，而是出草稿、谈问题、修正草稿、再讨论、再修正……最终达成共识，这才是合理的过程。
必须加强两个方面的意识
（2）绘制要点
从这样的结果中我们会发现很多待定的、不合理的问题，这就是我们需要进一步和被访谈者进行交流和沟通的地方
根据被访谈者谈及的部门，按出现的顺序从左到右地排列在职责带区中，然后将他们的活动添加到各自的职责带区
一是所有的职责带区上的命名都将细化到具体的岗位
二是每类活动之间的关系已经没有疑问，大家都达成了共识
还有一点是需要特别注意的，那就是不管怎么样，都不应该对业务活动进行细化，例如这里的许多活动都有更细节的步骤，这些应该在填充细节阶段用子流程图的形式来建模。
结束标识
模型最有效的方式是在交流中演化出来的。
（3）参考案例
4.跨职责流程图应用基础与要点
（1）活动图概述
一个用来表示活动的初始节点，它用一个实心圆表示，在一张不包括子图的活动图中有且只有一个初始节点。
① 初始节点和活动终点
活动节点是活动图中最主要的元素之一，它用来表示一个活动
在UML中，活动节点所描述的活动可以是原子的动作，也可以是能进一步分解的一系列操作；
它可以是文字描述、表达式、事件等
② 活动节点
当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称为“转换”，用一条带箭头的直线来表示
如果你需要对这些转换设置一些条件，使其在满足特定的条件时才触发，则可以借助监护条件来完成。
③ 转换
④ 分支与监护条件
除了顺序结构、分支结构和循环结构之外，还可能存在并发的事件流
⑤ 分岔与汇合
（2）活动图的主要元素
（3）带泳道的活动图
带对象流的活动图
活动图中的对象、对象流表示法
（4）带对象流的活动图
如果一个活动图过于复杂，或者活动图中某一组活动与主控制流关联不大，那么就可以借助辅助活动图来描述它
活动节点“收款”，实际上就包括了多种不同的处理：网上银行、点卡、汇款等
活动图外联
① 辅助活动图
② 汇合描述
● 时间信号：就是用来表示随着时间的推移而自动发出的信号，它的作用与VB、Delphi等开发工具中的定时器类似。你可以用来表示一个特定的时间，例如每天10:00点，每一微秒等。
● 发送信号：也就是发出一个异步消息，而接收的目标就是“接收信号”。
● 接收信号：就是等待一个外部信号的发出。
例如小张去必胜客吃饭，发现要排队，他决定如果15分钟还轮不到，就到隔壁的肯德基吃饭，那么就可以通过上述的符号来表示。为了使例子保持简单，图6-29中假设小张排在最前面。
案例
③ 发送信号与接收信号
引脚是一个对象节点，代表活动连接输入、输出值的连接点。每一个输入的参数都有一个输入引脚，而每一个输出的参数也都有一个输出引脚。活动的引脚是有序的，它与实际的参数是相匹配的。
④ 引脚（pin）
在绘制活动图时，经常会遇到一个活动需要多次执行的情况
例如，我们在选购手机时，可能先确定品牌，然后尝试各种机型，最后做出决定。在这个流程中，确定品牌和最后做决定都是一次活动，而尝试各种机型则是有可能并发多次的活动，因此，可以利用扩展区来表示
⑤ 扩展区（Expansion Region）
（5）复杂活动图
那就是当流程图绘制完之后，应该尽可能对其进行一些分析。
● 瓶颈分析：也就是看看有没有哪个环节的工作量会过大，如果存在这种现象的话，就很可能在执行时出现问题，最终导致信息系统无法很好应用的尴尬局面。在动手实现之前，将其揭示出来，就可能获得一些提前改进的机会。
（6）绘制活动图之后
5.活动图应用基础与要点
（1）数据流图的主要元素
（2）分层的数据流图
案例，课程注册系统的流程是：教务处提供有关课程信息，学生获得课程安排后，进行申请注册，教师在注册完成后得到班级列表。
① 构建顶层图
首先，通过对问题域的分析和需求的调研，可以建立业务事件列表
② 根据业务事件绘制DFD片段
③ 将DFD片段合并成DFD
“安排课程”进行分解到业务步骤
④ 逐步细化，分解到底
（3）数据流图的绘制过程
6.数据流图应用基础（DFD）
6.2.1 业务流程分析
在领域建模的过程中，应该更多地采用“自底向上”的方法，也就是针对每一个业务事件、每一类报表创建局部的领域类图片段，然后当完成这些建模工作之后，再对其进行抽象、提炼，形成全局的领域模型
步骤包括三个：识别出业务实体，确定实体之间的关系（语义关系和数量关系），定义实体的关键属性
● 类图：类图是面向对象分析与设计方法引入的，它是UML规范的一部分，它在语义上要比传统的E/R模型更强，在领域建模领域更加合适一些。
● E/R图：E/R模型也叫实体关系图，它的历史更加悠久，与数据库结合得更加紧密，但在领域建模阶段语义不够丰富
1.业务实体分析任务概述
显然张三就是一个对象，它可以归到“订货人”这个类中；而绍兴蛋糕店也显然是一个对象，它可以归到“商户”这个类中。而从中也显然可以得出以下定义：每个对象都扮演了一个角色，并为其他成员提供特定的服务或执行特定的行为。
（1）面向对象的思想
类是对一组具有相同属性、操作、关系和语义的对象的描述。关系是类之间的、语义是蕴藏的，因此对于一个类而言，其关键的特性是属性（成员变量）和操作（成员方法）
（2）类的表示法
在UML中，使用一条实线来表示关联关系
关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的
① 关联关系
继承关系是泛化关系的反关系，也就是说，子类是从父类中继承的，而父类则是子类的泛化
② 泛化关系
● 聚合关系
● 组合关系
区别：依赖于“应用场景”的
③ 聚合与组合关系
（3）类之间的关系
把握三项内容：类、关系、多重性（这也就是类图中那个重要的20%
分析出类和属性
① 读出类
在绘制类图时就应该将这种关系最复杂的类放在图的中间，否则就难以避免交叉线的出现，从而使类图的可读性受到影响
② 读清类之间的关系
③ 理解数量关系
（4）类图的主要元素
① 导航箭号
② 角色名称
③ 导出属性
④ 限定符
⑤ 约束
⑥ 向非技术背景的用户解释
（5）类图中常用的辅助建模元素
（6）关联类
● 找到备选类
● 决定候选类
① 标识类
● 确定关联关系
● 多重性分析
② 明确类间关系
③ 确定类的主要职责
● 导航性分析
● 约束
④ 补充类之间的结构规则
（7）领域建模的方法示例
就是先绘制出领域类的片段，然后再抽象、提炼、汇聚成全局领域模型
（8）领域建模是自底向上的过程
① 立即给关联指定多重性，确保每个关联都有明确的数量关系
② 对名词和动词做过度的分析，而背离初衷
③ 不对用例和时序图进行研究，就将操作分配给类
④ 对象和类的通用程度越高，在其他项目中重用它们的可能性就越大
⑤ 对于每个“整体/部分”关系，就使用聚合还是组合表示而争论不休
⑥ 未对问题空间进行建模之前，就假定一种具体的实现策略
⑦ 将类命名为难以理解的名称，而不是直观的名称
⑧ 直接进入到实现结构，如友元关系和参数化类
⑨ 领域类和关系型数据库表之间建立一对一的映射
⑩ 过早地执行“模式化”
10个误区
人看到如图6-55所示的领域类模型片段时，总会忍不住要合并它
过早地将子类合并掉
例如将客户类分拆为：客户基本信息、客户联系信息……，以及经常会对一些同类进行抽象，例如将报表格式、表单格式抽象成为模板，这些做法都会阻碍与客户的交流与验证。
经常会把相对比较大类的类进行分拆
领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、同类不抽象”的原则。
常见问题
（9）领域建模的常见误区领域模型的要点是拒绝实现、保持简单、忠于问题域。
类建模的三个阶段
后续的交流来细化、补充这个领域类模型
① 领域模型
● 实体类
● 控制类
● 边界类
② 分析模型
③ 设计模型
（10）类模型的演化
2.类图应用基础与要点
（1）数据建模过程
●实体：也就是在问题域中的业务实体，它等价于“类”，是对一类业务对象的抽象，是E/R模型中主体的元素。在E/R模型中，有两种标准的表示法，一种是与类图相似的矩形，另一种是带圆角的矩形。
● 属性：也就是描述业务实体的字段信息，等价于类图中的成员属性。它可以像类图那样直接写在实体中，也可以放在外面，用一个椭圆表示。而且还可以指定各个属性的数据类型、长度、是否为Key属性等信息
● 关键属性：也就是键值，包括主键、外键等信息，它是数据库中的概念，对于概念模型而言是不需要指定此类信息的。
● 关系：当描述两个实体之间的关系时需要指定一些特殊的属性，例如任职关系（需要指定任职时间、职位信息）、借阅关系（需要指定借阅时间等信息）。这时可以将这些信息打包成一个“关系表”，它等价于“关联类”。
① 基本元素
“乌鸦脚”的表示法
② 元素之间的关系
（2）E/R模型的主要元素
3.E/R图应用基础
6.2.2 业务实体分析
用例分析：用例图是目录，用例描述是封装所有需求的形式
1.用例分析技术概述
什么是参与者（Actor）呢？参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物
参与者是用户相对系统而言所演的角色。不过值得注意的是，参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟
两种表示法
参与者是直接使用系统的最终用户
（1）参与者
● 用例场景是有步骤的（执行了一系列动作）：也就是说，它是一个由一系列业务步骤组成的业务活动。
● 用例场景是有目标的（可见的价值结果）：也就是说，它能够为参与者带来有意义的结果，例如“填写搜索条件”显然就是对参与者而言没有意义的，就不是一个合适的用例。
● 用例是对一组用例实例（也称为场景）的抽象，也就是说，用例是有路径（基本事件流、扩展事件流、子事件流等）的。例如我们在ATM上取款时，可能会遇到很多不同的场景：正常取到钱、卡里钱不够、密码忘了、机器里没有足够的钱、卡被吞了等；而这些都可以概括为一个名为“取款”的用例。
（2）用例
2.参与者与用例在用例模型中，所包含的元素只有两个：参与者、用例
用例图来理解图的构成，以及用例与用例之间的关系、参与者与用例之间的关系、参与者与参与者的关系
客户、总台服务员和银联POS系统
3个参与者
预订座位、安排座位、办理结账等
8个用例
方框称为“系统边界”，也叫做“系统范围”
（1）系统边界
在参与者和用例之间的关联是用一根带箭头的线来表示的，不过虽然在图形与用例之间的关联的表示法相同，但它所表示的含义是不同的。
一个参与者和用例之间的关联关系表示两者之间将进行通信，任何一方都可以发送和接收消息。
（2）参与者与用例的关系
两个用例之间可能存在的关系包括3种：包含、扩展和泛化，而通常不应该有通信关系
用例“预订座位”就包含了用例“检查座位信息”
只有当某个事件流片段在多个用例中出现时（就像本例中，在客户预订座位和总台服务员安排座位时都需要检查座位的详情），我们才将这个事件流片段抽取出来，放在一个单独的用例中，这样就可以简化基用例的事件流描述，同时也使得整个系统的描述更加的清晰。
① 包含关系
也就是说，基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展。
② 扩展关系
而用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置。
用例收款只定义收款的一般过程，而处理现金结账和处理银行卡结账则是两个子用例，它们完成不同情况下的收款工作。父用例和子用例之间的关系如图
③ 泛化关系
面向客户的用例图通常都不应该出现“包含”关系，因为子事件流存在共性对于客户而言是不关心的，它应该是在开发团队对用例细节进行填充之后的归纳；而泛化关系则更是如此
另外，如果将所有的扩展事件流都用扩展关系表示出来也会导致图的规模大幅扩大，它只是在需要将一些相对优先级不高的扩展事件流放在后期开发时才需要绘制出来，并与客户协商以达成共识的。
最值得说明是，不管是被包含用例还是扩展用例，从其语义角度来看它们仅仅是子事件流、扩展事件流，而不是一个真正意义上的“用例”。
千万不要为了使用扩展、包含关系而使用它们。扩展用例建模的通常是优先级较低的扩展事件流，包含关系建模的通常是多个用例所包含的公共子事件流。
④ 用例间关系小结
（3）用例之间的关系
参与者之间的关系只有一种，那就是泛化
通过泛化关系避免交叉线
（4）参与者之间的关系
首先定义了3个基用例：预订座位、安排座位和处理结账。
“收款”这个子事件流只有“办理结账”一个用例用到，因此不应分解出来；我们只是为了讲解泛化关系才做这样的处理。因此更合适的方法是建模，结果应如图
棋牌馆管理系统案例
3.用例图
① 边界确定（去除非End User的职责带区）
② 确定角色（对剩下的职责带区进行角色化）
③ 确定用例
有了上述的分析，我们得到了用例、参与者，接下来就可以绘制出如图6-82所示的用例图片段。
在访谈现场，就流程图讨论出用例图是高效的建模方法。
④ 绘制用例图
（1）自顶向下导出法
① 收集原始需求
② 确定参与者
③ 合并用例
（2）自底向上合并法
4.用例的来源
● 被包含用例、扩展用例：有人将其认作了用例，既然这种“步骤”级的东西都可以视为用例，粒度问题就模糊了。记住，它们表示的是子事件流、扩展事件流，不是真正意义上的用例。
● 技术性用例的引入：例如“登录系统”之类的东西过早被建模出来，但业务价值却并不明显。
① 业务价值判断是关键
真正会影响用例大小的是业务流程，是工作任务的分工
如果说用例有粒度，那么它取决于业务流程和任务分工。
②“用例粒度与系统复杂度相关”的观点是错误的
系统动作（诸如新增、删除之类）和业务名词在用例名称中相遇时，就是一个十分危险的信号。
③ CRUD的价值被过于放大了
（1）用例真的有粒度吗
（2）用业务动词命名用例十分重要
我们应该将人（角色、参与者）和事（场景、用例）分开考虑；在确定它们之间关联时，要先事后人地思考
错误的思路
业务活动是收处方、配药、审核，然后将参与者对应上去，再通过泛化关系来改进
医院管理系统案例
（3）采用先事后人的方式分析是要点
5.用例分析技术应用要点
6.2.3 角色与使用场景分析
体检医院案例
核心任务就是结合业务流程、报表的需求，梳理出结构框架（领域模型）和行为脉络（流程图→用例模型），为第二阶段的需求分析工作建立基础；指出方向。
而具体来说，就是从上一阶段标识出来的业务事件（业务流程的起点）和报表列表开始，展开对中层管理人员的访谈与调研，而范围就是“体检业务子系统”所对应的服务中心、体检科室和综合科三个部门。然后再根据访谈的结果完成事、物、人的分析，最后在此基础上抽象出该主题域的领域模型和用例模型。
1.工作任务说明
我们已经通过和客户交流、绘制上下文关系图的方法，标识出了体检者申请体检、体检者中途改单、财务部门提交团队缴费情况、客服中心查询体检情况、维护人员管理体检项和系统通知用户取报告6个业务事件
看到这张图，也许读者会感到许多疑惑：这张图也实在太简单了吧！开单、收费过程都涉及许多业务性的判断呀！为什么都不体现呢？
它们属于细节层次，而判断的原则是：对不影响泳道间协作的判断、活动均属于细节信息。
为了便于在后续填充需求细节时更好地进行数据需求分析，在此可以标识出相关的表单、文档、规则等，以便定向收集。在本例中可能就会标识出以下相关文档：体检申请单（体检者在申请体检时填写的）、体检单（开单时打印出来的）、账单（收费时打印的）、体检项收费清单（在收费时使用的）、体检结果报告（体检科室的产物）以及体检报告（综合科出具的结果）。
● 业务流程分析
● 业务实体分析
● 角色-使用场景分析
（1）体检者申请体检
（2）体检者中途改单
（3）其他业务事件
2.业务事件分析
对于报表而言，Why要解决的问题包括：部门/职位、目的、相关场景与查询频率等方面的内容。
（1）Why
● 相关业务实体分析
● 报表项分析
● 数据项及计算方法分析
对于每一类报表，我们还需要确定与它相关的业务实体（用类图来表示）、主要的数据项、数据项的计算方法，同时还要确定有多少具体的报表。
（2）What
3.报表分析
（1）抽象用例模型
（2）抽象类模型
4.抽象与整理
xx体检医院管理系统需求规格说明书
【金山文档】 xx体检医院管理系统需求规格说明书
5.填充需求规格说明
6.2.4 周期一的产物
6.2 周期一：理清框架与脉络
根据行为需求的特点，我们可以将其分成“业务功能、报表功能、接口、技术支撑” 4种类型
1.用例的灵活应用
RUP版用例描述
2.用例描述模板
（1）前、后置条件
“取款”用例（取材于ATM机），按预设金额顺利取到钱就是基本事件流
● 基本事件流
而密码不对、机器里没钱、卡被吞掉等都是表示异常情况的扩展事件流
● 扩展事件流
● 子事件流
事件流类型
● 使用简单的语法
● 明确写出“谁控制球”
● 显示过程向前推移
● 用“确认”而非“检查是否”
● 从俯视的角度来编写
表述要点
（2）事件流的类型与表述要点
（3）业务用例与系统用例
（4）不当事件流示例分析
场景和用例之间的关系，与对象与类之间的关系类似；也就是说，一个用例是一组相似场景的抽象；因此，一个用例通常是一组事件流所构成的。
参考书籍《编写有效用例》
3.事件流分析
（1）用户原始需求
（2）相关功能点
4.相关需求整理
● 需求人员应该提供设计依据而非设计结果
● 软件需求规格说明书里的用户界面原型不是解决方案！它应该被视为约束、建议；
● 创建用户界面原型时，重点在于实现用例事件流的交互过程，在于讲述每个界面中要满足的用户意图，而不仅仅是浮于表面的元素个数、位置、大小等信息。
（1）要点
（2）交互不要忽略
● 目的
● 信息要求
● 操作要点
界面原型部分是约束、是建议，目的是支持有效的UI设计。
（3）别让界面掩盖本质
5.界面原型
● 行为规则：或称为功能规则、业务规则，它是指和业务逻辑、业务流程相关的规则。例如：客户上笔订单未付清，新订单就不能发货；500元以上的报销必须由处长审批，500元以下可由科长审批等。
● 结构规则：或称为数据规则，它是指和业务实体、属性、派生属性相关的规则。例如：一条短信的最大长度是70个汉字（140个英文字符），当出现一个汉字时，则每个英文字符算一个汉字；销售人员的当月有效业绩是当月已付款的所有订单的总金额合计等。
● 界面规则：它是指和用户界面相关的规则。例如：在界面中必须以不同颜色显示不同等级的告警；本界面的下拉列表应该提供汉语拼音首字母筛选功能等。
（1）规则的类型
（2）规则的影响层次
出现的频率、使用者的数量等基础信息，提供一些系统响应时间等方面的要求
● 性能指标等非功能要求
● 软、硬件环境限制
● 技术选择限制
（3）用例级的约束
6.规则与约束
7.基于Stakeholder利益分析的需求挖掘
6.3.1 确定行为需求的细节
（1）领域模型的组织
（2）数据窗口分析
（3）数据组成与格式
（4）派生数据的计算方法
1.基本内容
① 主要字段与次要字段
② 稳定字段与不稳定字段
③ 即时记录与历史记录
（1）数据结构特点
（2）数据使用特点
（3）非功能要求
2.常见盲区
6.3.2 确定结构需求的细节
填充用例、填充领域类
据迭代计划来分阶段细化
● 用例名称：开单就是一个比较合适的用例名称，它是一个用户熟悉的业务动词，能够很好地理解。
● 编号：正如前面所述，建议不要使用顺序号，而是使用有一定意义的编号；在此我们使用UC_B_TJ_KaiDan作为编号，表示这是一个业务功能类用例（B），属于体检主题域（TJ），用例名称为开单（KaiDan）。
● 参与者：该用例的参与者显然就是“服务人员”。
● 用例概述：用例概述应该从目标、意图的角度进行表述；因此对于本用例而言，可以写作“服务人员根据体检者的选择或预约单开具体检单，并打印出来交给体检者”。
● 相关Stakeholder：对于本用例而言，和其相关的Stakeholder有两个，一个是上游的体检者，另一个是下游的收费人员
① 用例概述
● 前置条件
● 后置条件
事件流也可以通过活动图（不带泳道，或者只包括参与者和系统两个泳道）来表示；但对于本用例而言，事件流中的内容较多，但分支、循环结构并不复杂，因此更适合采用这种结构化文本，而无须采用活动图
案例分析
② 事件流分析
原始需求：作为需求跟踪的方便
难以归纳到用例事件流中的功能点：建议一定不要省略，否则需求将是不完整的
③ 相关需求
④ 用户界面原型
规则与约束是仅针对该用例的行为规则、结构规则、界面规则以及设计约束
⑤ 规则与约束
（1）开单用例分析
● 报表名称：说明报表作用概述性名称，也就是报表型用例的名称；在此显然就是“体检业务周期统计报表”。
● 报表概述（Why）：可以从报表类型概述的基础上引用和补充，具体包括：
● 报表内容（What）：涉及的数据实体以及相关的数据字段，具体包括：
● 输入/输出格式（How）
● 其他：与报表实现相关的其他信息
（2）体检业务周期统计报表用例分析
2.填充用例描述
（1）数据窗口分析
（2）数据组成与格式分析
3.填充领域类细节
4.填充需求规格说明
6.3.3 周期二的产物
6.3 周期二：确定需求细节
哪里有分解，哪里就有接口
● 使用者名称：罗列出该接口的外部使用者，通常是外部系统、其他主题域。
● 业务目的：说明使用者将通过该接口实现什么样的业务意图。
● 使用时机：说明使用者将在什么场景中调用该接口
● 使用频率：描述各类使用者调用该接口的频率。
1.使用者
● 交互过程说明：在调用接口时，数据的传输方向、顺序信息。
● 数据包说明：对前面标识出来的各次数据传输的内容与格式做进一步说明，内容包括什么属性、每个属性的格式、长度等信息。
2.内容与格式
● 协议格式要求：数据包必须采用TCP格式，数据交换必须以库交换实现，数据包协议必须符合8583规范都是相关的例子。
● 性能要求：例如“接口调用必须在3秒内完成应答”。
● 环境限制：例如“使用者可能通过Internet访问接口”。
4.示例
6.4.1 接口需求
基于ISO/IEC 9126（GB/T 16120-1996）
（1）功能性
（2）可靠性
（3）易用性
（4）效率
（5）维护性
（6）可移植性
1.质量特性分析
2.确定非功能需求树
6.4.2 非功能需求的追踪
（1）节点
（2）连接
（3）节点包含的内容
1.部署图基础
（1）描述设计约束：需求人员
（2）表示环境要求：架构设计师
（3）说明人工制品：开发人员
2.部署图的演化过程
6.4.3 设计约束
6.4 其他需求分析
6.5 小结
第6章 需求分析与建模最佳实践
优点在于易于编写、易于阅读，不要求掌握特定的技能
缺点在于不够严谨，歧义性强，表述力差（对于复杂问题的描述就更为明显，往往需要很大的篇幅来解释）
1.自然语言
优点就是前面提到的可视性、聚焦性
缺点，那就是要求编写和阅读的人都能够正确地理解模型，而且并不是所有的信息都是可以用模型表示的
2.图形化模型
优点就是严谨、精确
缺点也是很显然的，那就是编写和阅读的人都会感到很困难，容易产生理解歧义
3.形式化规格描述
● 自然语言为主，辅之以图形化模型，需要的地方少量使用形式化规格描述：这是现在最常见的组合形式，对于绝大多数信息系统、软件产品而言都是十分适合的方法。
● 图形化模型为主，辅之以自然语言作为补充，需要的地方少量使用形式化规格描述：这是RUP所推荐的方法，当项目团队对模型标准有较高的认识时可以考虑这种方法，它在需求管理方面会更加方便一些，但出现交流障碍的可能性更高，特别是和最终用户代表的交流。
● 以形式化规格语言为主，辅之以图形化模型，以自然语言为补充：适用于质量要求很高的领域，例如航天、军工中的一些重要项目。
4.选择建议
7.1.1 常见的描述风格与选用标准
1988版本
2006版本
需求规定的子项分析
● 国标/ISO版本
● RUP版本
● 咨询商版本
各类模版比较
7.1.2 典型软件需求规格说明书模板解析
SERU需求规格说明书模板大纲
1.自定义模板示例
（1）模板
（2）指南
（3）示例
2.模板以外的内容
7.1.3 定义模板的技巧
（1）什么是用户需求说明书
（2）何时需要用户需求说明书
1.用户需求说明书概述
用户需求说明书是为生成软件需求规格说明书服务的。
2.从用户需求到软件需求规格
7.1.4 用户需求说明与软件需求规格说明
7.1 需求描述的风格与格式
虽然我们很强调“软件需求规格说明书”这一文档的重要性，但同时也必须紧记“文档无法代替沟通”这一道理。
7.2.1 文字表达的先天不足
也就是尽可能不要采用长篇大论的方法，因为段落越长，读者的压力越大，产生歧义的可能性也就越大。
文字的歧义可能与其长度成正比。
● 简洁、段落文字少
● 列表、图表相结合的表示法
需求描述片段
需求描述片段（修改版）
参考案例1
参考案例2
要使需求描述更加清晰，就应该转用“结构化文本”式描述。
7.2.2 需求描述的两大原则
隐喻
当我们发现需求的How没说清楚时，一定要反思是不是Why没说清楚，因为需求人员（包括用户代表）并不是解决方案的最佳决策者，他们在解决方案域的知识、经验缺乏也是变更的来源之一。
在这里，需求的What显然是“系统在酒店图上显示空闲的客房”，如果向开发团队传递的信息只有这些的话，那么开发出来的可能就是一个无法放大、缩小，没有平移功能的静态平面图，毕竟开发团队会“适度”地压缩需求。
但如果你一开始就告诉开发人员，要实现“系统在酒店图上显示空闲的客房”功能的原因是“客人要求相邻的客房”（Why）时用户很麻烦，那么这些变更可能根本不会出现
在你被逼在需求描述中增加How的信息之前，先确认自己已经尝试过为需求添加了Why。
7.2.3 不要忽视陈述需求理由的重要性
例如，在写可靠性时，不写“高可靠性”，而是写“需要提供7×24小时不间断的服务”、“需要提供5×8小时的服务”；在描述易用性时，不写“高易用性”，而是写“符合只达到计算机一级水平的用户的操作习惯”等
对于非功能需求而言，应该抛弃定性，改用场景化描述；并通过选取指标、积累经验值的方法过渡到定量描述。
1.尽可能减少使用定性词语
在……之间、但不包括，大于但不等于；这些都容易产生疏忽，因此我们应该改为使用数据表达式来说明
建议改为“当前库存量=领取人本身的实际库存+其下属的实际库存”
2.避免使用描述数据的词语
7.2.4 注意措辞
7.2 写作策略与技巧
谨记“信息的有效传递”
● 可获得：随时可以获得最新的版本，需要用文档管理制度来解决；
● 有更新：应该有专人更新，需要制度来保障；
● 可获知：写的人、读的人都能够正确地从文档中获得所需的信息，需要通过良好文档模板来解决；
● 易更新：应该确保一类信息在一处出现，这需要良好的文档模板来解决。
希望大家能够创建出符合自身项目特点、团队特点、开发方法论特点的模板，千万不要“削足适履”
7.3 小结
第7章 需求描述最佳实践
8.1.1 不同正式化程度的评审
要开好一个评审会，好的规划是必需的。简单地说，就是规划内容、规划人员，即谁参加？评审什么？
1.规划
在召开正式的评审会议之前，召集参加评审会议的所有成员开一个简短的会议，讨论、明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表。
2.总体会议
评审会的效果好不好，关键在于评审者是否提前做了阅读、做了准备，要想让大家在现场提出有价值的、完整的建议是不可能的。因此，我们应该为每位评审者提供完整的参考资料，提供一些时间，预先阅读、查找错误。同时，要求所有的评审者将阅读时发现的文字、版面类的错误直接发给作者，不要让这些东西浪费评审会的时间。
3.准备
准备阶段的目标是发现问题，而召开审查会议的目标则是暴露问题、讨论问题，大家对预先找到的问题，逐一讨论，给出结论。
4.审查会议
只有审查没有返工，那么必将使“评审”活动变成形式主义！也是对评审文化的建立最具破坏力的因素之一。
5.返工
● 解决问题：我们必须对提出的问题是否解决进行跟踪、督促；● 避免问题出现：对所有的问题都应该进行分类、因果分析，找到出现这些问题的深层次原因。
6.跟踪
8.1.2 审查过程概述
8.1 需求验证的主要手段
需求验证的目标是尽可能暴露问题，而不是证明无错。
1.思想
由于东方人这种处事的特点，这种特点会在需求评审会上表现出来：那就是中国人通常是不太愿意接受“当面指出问题”的这种沟通方式的，更不要说在“众目睽睽”之下被人指出问题。
要想慢慢创建企业的评审文化，就必须建立这种对评审活动的认同；而要建立对评审活动的认同，就必须看到评审的效果；而要看到评审的效果，最快的是通过正式化程度较低的评审手段。
● 当需求人员还没有建立在每次交流结束时进行即时评审的习惯，就无法真切地体会评审的意义和价值，更难全心地投入到专门的评审活动中。
● 当需求人员连把自己写的东西发给同事，让其提提意见的习惯都没有建立，那么更不可能习惯在公开场合听人“指手画脚”。
在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。
2.方法
如果说前面讲的是东方人通常不是一个好的、积极的“被评审者”，那么这里想要说的是，东方人还经常不是一个好的、有效的“评审者”。
在评审会中，不要用“评价者”的口气谈论你的观点。
应该以“建议者、协作者”的身份、角色出现在会议中
3.语言
● 同级：别忘了，在CMM/CMMI中提到的是Peer Review，Peer就是同级，千万不要一开评审会就请高阶领导。很多人连“当着别人面被指出问题”都受不了，更何况是当着领导的面呀。
● 该来的人要请：也就是评审的内容所涉及的第一责任人，要想办法请他们参加。
● 不该来的人不要请：也就是评审不是越多人参加越好的，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。
参加需求评审的人不是越多越好，一定要保证同级、适合。
4.人员
评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。
5.内容
8.2.1 需求验证的5大要点
● 解决建议按照评审者关注的内容拆分分场，与其大家聚在一起讨论，还不如分主题、分场次、分人员进行周期更短的评审会。
1.评审会上是上面开大会、下面开小会
● 解决建议让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。这既可以通过培训评审者的方式来实现，也可以通过主持人以身作则的方法示范。
2.评审会成了审判会
● 解决建议和前一种情况一样，要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。
3.评审会成了吵架会
4.评审会成了语法纠错大会
5.评审会成了翻书会
8.2.2 需求验证常见的5大问题
8.2 需求验证的主要误区与解决方案
8.3 小结
第8章 需求验证最佳实践
第二部分 需求开发
9.1.1 基线思想的起源
9.1.2 基线的策略
9.1 需求基线的理念与策略
● 业务优先级判断：根据业务结构特点，对所有需求项划分等级。
● 技术依赖性、项目风险判断：从技术实现、项目风险两个角度调整优先级。
9.2.1 组织需求项
评价具体功能点的优先级时，应将其放到业务场景甚至是业务流程环境中考虑。
9.2.2 业务优先级评价
● 技术依赖性：对于本例而言，“管理体检项”和“管理体检套餐”属于基础工作，“体检者申请体检”中的所有用例都依赖于它，因此它们应该升级为“关键”用例。
● 项目风险：也就是项目经理觉得在技术上、管理上存在风险的需求项要提前开发，也就是提高它的优先级，对于本例而言没有需要调整的。
9.2.3 根据技术依赖性和项目风险调整优先级
9.2 基线划定的基础：优先级评价
● 在需求定义阶段完成时应该安排一次估算，其结果相对比较粗糙，因为需求项还很粗糙（业务流程、报表类型、接口项）；生成的结果可以作为立项的参考；
● 在需求分析一阶段（也就是确定了框架和脉络阶段）完成时应该再安排一次估算，此时需求项已经细化到用例级（通常是人周级），可以得到更准确的估算结果；这个阶段的产物是划定基线、安排迭代计划的基础；
● 每次开发迭代完成之后应该填充实际进度数据，并根据它调整估算值，调整迭代计算；随着项目的不断进展，估算值也将越来越趋近于实际值。
1.何时进行估算
实际上可以归纳为“寻找计数单元，考虑复杂因子”两大步骤
● 需求定义阶段：可以考虑以业务事件、报表类型、接口作为计数单元；● 需求分析的一阶段：可以考虑以用例作为计数单元；● 需求分析的后续阶段：可以考虑使用FP或COCOMO中推荐的计数单元。
2.估算的核心思想
● 分部分、分类型估算
● 基于权重的估算
3.建议的估算操作要点
9.3.1 估算的意义与要点
1.对每个主题域进行估算
由于需求定义阶段标识出来的是B、R、I三类，对于T（技术类）还未涉及，因此在估算结果中还应该增加这个部分的考虑。对于这部分非用户可见的基础设施而言，通常占据总开发量的30%是比较正常的。
2.后续估算任务
9.3.2 定义阶段的估算示例体检医院管理系统
9.3.3 分析一阶段的估算示例
9.3 基线划定的要素：工作量估算
通过计算可以得知，这些“关键”需求的总工作量是11.2个“标准1”，即67.2人天（折合为13.44人周）。通常这样的工作量是可以放在一次迭代里的，如果一次迭代完成不了，那么就应该考虑分成不同的迭代。假设这个主题域的开发工作中将投入3名开发人员，那么就可以考虑安排一次历时4～5周的迭代。不过在划定基线时还需要考虑一个关键的因素：人员产能之间存在很大差异；而且这个因素对于回填历史数据也很重要。
9.4.1 划定基线
● 需求变更：在整个开发过程中，需求会发生变化；这些变化应该更新到“待处理需求”集（Backlog）中，并不直接影响基线。而对于变更的处理，请参阅“第10章 变更管理操作实务”。
● 迭代过程未完成：虽然从项目管理的角度，我们不希望每次迭代结束时还有遗留任务没有完成；但从需求管理的角度，这种现象又是不得不处理的。每次迭代总是有可能发生未完成某些任务的情况，这些将影响下一次迭代的基线。
有两个重要的变化因素，会对预先的计划产生破坏：
9.4.2 管理基线
9.4 基线划定与管理
RUP对软件开发过程的总结也谈到了这一点：“用例驱动，架构为中心，迭代、增量的开发过程”
9.5 小结
第9章 需求基线操作实务
一是我们错了，捕获的信息不全面，分析的结果不正确等
二是世界变化了，现代商业社会充满变化，业务流程、业务规则都是日新月异
需求变更产生的根源
需求变更管理的目标是控制变更，而非避免变更。
控制变更的目标是减少变更对开发工作的影响。
需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计来减少变更的影响”。
10.1 变更管理的理念
● 变更可能相互冲突：如果没有统一的规划与管理，程序员所响应的变更可能相互冲突，导致新问题的产生。
● 变更量无法引起重视：国内的许多客户通常是没有为变更付费的习惯，其实从某一个角度来看，对变更量没有直接感受是一个很重要的因素。
建立统一的渠道让客户意识到变更的成本，减少“来路不正”的变更，记录“变更的工作”。
原因主要包括两个方面
项目的“变更管理委员会（CCB）
● CCB是业界的最佳实践，可以由一个小组或多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用。
● CCB的组成：项目管理部门、产品管理或需求分析部门、开发部门、测试和质量保证部门、市场或客户代表、用户文档部门、技术支持部门、配置管理部门……
CCB 的核心人员只有两个，分别代表用户团队和开发团队，其他组成人员都是协作者和决策者
CCB中的其他人员并不是常设人员，并不需要参与到每个变更的决策过程中；确定这些成员的目的在于当常设人员需要协作者，需要最终决策者时，能够有的放矢地找到相应的人员。
1.正确认识CCB
只要规定开发人员收到客户代表的变更之后，必须将变更交给CCB，然后再由CCB下达给开发人员，当客户代表询问时，就直接回答“你提交的变更已经给CCB了，他们会尽快进行处理”。
2.使CCB成为真正的统一渠道
10.2.1 CCB背后的道理
● 行为需求类变更：也就是具体的功能方面的需求，包括用户界面的需求，通常可以直接找到对应的需求项，也就是可以归属于某个具体的业务活动中；当然它也可以变成新增的用例，甚至是新增的业务事件。
● 数据、非功能、规则类变更：对于这类的变更则需要考虑它影响的范围，它可能只影响一个业务活动（用例），也可能影响一个业务事件。
（1）确定影响范围
（2）选择正确的评价者
对于每个需求都需要从合理性、必要性、影响度等几个方面进行评估，从而决定是否“接受”
（3）对变更做出评价
1.业务影响度分析
● 对于修改型的变更：罗列出会影响哪些人工制品，包括数据库表、字段、界面窗体、控件，类、方法；在这个方面要想做得比较精确，就必须借助于“需求跟踪”，具体来说就是“需求项”与“人工制品”的跟踪。
● 对于新增型的变更：可以采用类比法进行，从已经实现的（也就是已有工作量记录的）功能中找一个与其相当的，以得出一个大致准确的工作量估计。
2.技术影响度分析
考虑是否对整个项目的时间、进度、成本产生较大的影响，并在这个基础上做出最后的决策。
3.项目影响度分析
● 出现了对前面假设有巨大影响：暂停迭代，重新考虑基线。● 工作量比较小，重要性或与开发中的需求的关联性很强：加入基线。当然，尽力做到“不打破基线”是很有意义的；只不过我们可以根据实际的情况做灵活的处理，目标就是有效地为开发活动服务。
业界对这个问题的结论是：变更通常是不打破基线的，而且从理论上是永远不打破基线的。
4.是否打破基线
10.2.2 变更处理过程
10.2 变更管理要点一：统一渠道
● 需求变更的生命周期管理：即从提出、评估、接受、实现到最终的验证，实现全过程的管理与跟踪，另外还应该能够支持“重激活”之类的活动。● 有效的权限管理体系：让需求变更的提出者、评价者、实现者能够在同一平台中各取所需。● 变更的分类与分析功能：应该能够对变更进行自定义分类，并且在此基础上提供相应的查询、分析功能。
包括Rational的ClearQuest、开源的Mantis，甚至还包括最简单的BugFree
10.3.1 变更管理平台的选择
10.3.2 变更管理平台的应用要点
10.3 变更管理要点二：统一平台
10.4 小结
第10章 变更管理操作实务
需求跟踪涉及5种类型的跟踪链：从用户原始需求向前跟踪到软件需求，从软件需求向前跟踪到下游工作产品；从下游工作产品向后回溯到软件需求，从软件需求向后回溯到用户原始需求；以及软件需求到软件需求的跟踪
● 审核：跟踪能力信息可帮助审核确保所有需求被应用。● 变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。● 维护：可靠的跟踪能力信息使得维护时能够正确、完整地实施变更，从而提高生产率。● 项目跟踪：认真记录跟踪能力数据，可以获得计划功能当前实现状态的记录。● 再设计：可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。● 重复利用、减少风险、测试。
需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。
11.1.1 用户需求到软件需求的跟踪
11.1.2 软件需求到软件需求的跟踪
11.1.3 软件需求到下游工作产品的跟踪
11.1 需求跟踪的基本概念
11.2 需求跟踪的操作方法
11.3 小结
第11章 需求跟踪操作实务
第三部分 需求管理
● S：Subject Area的首字母，它表示子问题域；这是“信息工程”中的概念，核心的思想就是根据业务区划来分解系统，使系统的各个部分在业务上保持相对独立，降低耦合性。
● U：Use Case的首字母，也就是用例，这是RUP之父Ivar博士发明的一种需求技术，它是迄今为止应用最广泛的技术之一；在笔者的实践中，发现它是封装需求的最好手段，可以作为需求组织的最小单位：一个业务活动（B类用例）、一个具体的报表项（R类用例）、一个具体的接口（I类用例）。
● E：Event的首字母，表示事件（对于信息系统而言就是业务事件），它是流程的起点，最早源于实时系统的需求分析，后来被结构化分析方法之父DeMarco引入到业务软件的分析中；通过业务事件的标识，就能够找到流程，通过流程就可以有效地将不同的场景串接在一起，起到承上启下的关键一环，它覆盖了OLTP（联机事务处理）部分的需求。
● R：Report的首字母，表示查询、分析、统计，用来覆盖MIS（管理信息系统）部分的需求；通过寻找管控点（也就是从意图出发），以确定报表类型，然后再细化到具体报表项。
12.1.1 SERU过程框架的理论基础
1.需求定义阶段
2.理清需求框架和脉络阶段
3.填充需求细节阶段
12.1.2 SERU过程框架全景图
1.建立基础
2.熟悉方法
3.全面应用
12.1.3 SERU过程框架导入建议
12.1 SERU过程框架要点概述
1.需求定义勿忽视
2.需求捕获要科学
3.需求分析要业务
4.需求建模要实用
5.需求评审要实效
6.需求文档要应用
12.2 需求实作要点概述
12.3 结语
第12章 SERU过程框架总结
第四部分 总结
《软件需求最佳实践》读书笔记
收藏
收藏
0 条评论
回复 删除
下一页
