SE_01 需求分析

1. 需求分析介绍

搞清楚了 “要解决什么问题”！

1.1 需求分析主要涵盖哪些问题

为什么要设计该系统？
系统由谁使用？
系统要做什么？
系统涉及哪些信息？
对解决方案有何额外限制？
如何使用该系统？
质量需达到何种程度？

1.2 需求分析分类

1.2.1 按产品/过程分类

• 产品需求
  1）功能性需求：满足系统需求提供的功能，如：订票系统可以选位置，可以微信支付。
  2）非功能性需求：为满足系统功能需求要满足的其他约束条件；
  （1）质量需求：正常工作时需要满足的额外的与质量相关的服务，“提供的服务好到什么程度”
  如，订票系统响应时间要小于1分钟；
  （2）约束：质量约束、技术约束
• 过程需求（软件开发过程）
  实现系统需求，如系统API需要支持Java程序访问系统服务。

1.2.2 按需求层次划分

• 业务需求
  客户高层次要求，针对业务部门的分析人员，帮助企业达成组织目标的需求项目。
  如：携程旅行的业务需求是卖飞机票。
• 用户需求
  用户具体的需求，针对客户方、承包方的管理人员、最终用户、客户工程师、系统架构师，用户接受程度的需求。
  如：客户希望照相机背后有一个液晶屏幕，这样在拍照之后可以马上看到照片。
• 系统需求
  系统角度，针对最终用户、客户工程师、系统架构师、承包方的程序员，满足业务需求，从用户角度描述系统在做什么，与系统由什么软件和硬件实现无关。
  如：软件会使得汽车的启动速度加倍。
  还分为功能需求、非功能需求<如响应时间>
• 设计约束
  针对客户工程师参考、系统架构师、承包方程序员。
  如必须使用某浏览器等。

1.2.3 其他需求

• 依从性需求
  对国家法律、国际公约、社会法则、文化与政治习惯、标准等约束的满足。
• 体系结构设计需求
  系统环境要求，分布式约束、安装约束（如操作系统的要求）。
• 设计开发约束
  对软件系统设计的约束。
  包括：成本、周期、产品特征的变化性、可维护性、可重用性、可移植性。

1.3 设计约束及过程约束的问题

1.3.1 物理环境

设备放在哪？
单节点还是多节点？
是否对环境有要求？温度、湿度、电磁干扰等
系统规模有何限制？
电源、供电或空调有何限制？
是否重用已有系统的构件？对编程语言的要求

1.3.2 接口

输入是来自一个还是多个其他系统？
输出是来自一个还是多个其他系统？
输入、输出格式是否预定义？

1.3.3 用户

谁使用系统？
几类用户？
每类用户技术水平如何？

1.3.4 过程

资源、材料
系统构造需要哪些人员、技能
多少文档
在线还是本地？电子还是纸质
读者有哪些？
标准

1.4 需求规则

好的需求是可以度量的，能给出项目成功的必要条件。

单个需求项目的质量：
准确、正确、明确、可行、可证

整个需求集合的质量：
现实、精确、全面、一致

1.5 常见问题

产品设计目标不明确
干系人参与不足
干系人之间缺少共识
画蛇添足
需求快速变化
变更管理不足
需求分析不足

2. 获取需求

2.1 获取需求的途径

目标：主动与干系人协调工作，找出他们的需求，识别潜在的冲突，磋商解决矛盾，定义系统范围与边界。

2.1.1 通过干系人（沟通和交流的方式）

好处：系统信息及内容的丰富、系统信息质量的提升、系统生产率提升、客户对系统理解加深、与客户达成共识、客户更希望系统成功、增强成功信心、共同确定系统边界、需求质量提升、提高团队整体性。

• 什么是干系人
  任何和系统有关的人，对一件事有决策权的人。
• 如何找出干系人
  产品谁来用？输入谁提供？输出谁要？谁监管？影响谁？奖励谁？惩罚谁？
  补充：尽量找出所有干系人，多人角度获取更全面的需求。
• 分析干系人
  分析其隶属于四世界模型※的哪个世界，明确干系人的立足点，知道干系人更关注哪些方面。
  补充：四世界模型
  
  四个方面主要的待解决问题：
  主题世界：系统关注的主题内容。如，银行信息系统关注顾客、账号、交易；
  应用世界：系统未来的操作环境，关注人和企业流程，关注经理、职员、顾客、存款、取款等活动；
  开发世界：关注软件系统的开发过程，团队、人员、进度等；
  系统世界：系统在操作环境下的内部操作，包括系统要将操作记录保存到数据库中，统计账户交易报告、明细记录等。
• 干系人举例
  （1）用户：关心新系统特征和功能
  （2）设计师：想要构造完美的系统，尽量重用已有的代码
  （3）系统分析师：想要获取正确的需求
  （4）培训与用户支持人员：确保系统可用和可管理
  （5）业务分析师：想确保“我们做的比竞争对手好”
  （6）技术文档作者：为系统准备用户手册及其他相关文档
  （7）项目经理：希望按时、按预算、按目标完成项目
  （8）客户：为新系统买单的人
• 诱导干系人说出他想要的东西

2.2.2 通过业务过程（建模和分析的方法）

对现有业务过程的分析有助于识别业务问题并加以改进：

• 找出并列举当前业务过程中的问题
• 分析问题的本质（遗漏？不好用？新需求？）
• 分析改进的机会
• 分析改进的实质（自动化？流程改进？）

2.2.3 通过组织规章制度（文本阅读、文档处理等）

组织规章制度为我们提供了一个客观的、可参依据

• 规章制度定义当前最佳实践
• 分析规章制度有益于确定业务规则和约束条件
  1）业务规则：描述对业务过程的要求，如系统支撑的业务过程的结构、控制、行为效果
  2）约束：对系统开发过程的管理限制，主要涉及经济、政治、技术和环境四个方面，具体包括项目资源、时间、目标环境涉及系统本身
• 组织规章中往往还涉及过程自动化、工作流、关系、交互等内容

2.2.4 通过现有系统

用户手册、数据样本、界面描述、报告样本、截屏截图

2.2 获取需求的方法

常见的需求获取方法包括用户访谈、问卷调查、釆样、情节串联板、联合需求计划、文档分析、头脑风暴、原型化方法、建模方法、需求讨论会等。

2.2.1 访谈

人少但懂得多，最好有专家在。

1）技巧

• 访谈开始
  谈一些比较轻松，不太敏感的话题
  如天气，体育比赛，就受访者的照片，办公桌陈设发表感叹
• 询问受访者是否同意录音
  将录音笔放在受访者面前，提醒他们可在任何时候关闭
• 先问比较容易回答的问题
  如个人信息，在这里工作多久等问题
• 根据对方提出的某些现所继续体温
  关注用户说的能暗示你的方案可能错误的时候，“您可以就此多谈谈吗？”
• 将自由发挥性质的问题放在最后
  “您还有什么想补充的吗？”

2）访谈过程

• 明确访谈的目的
  通过访谈获得什么信息？什么时候目的达到了？

• 设计访谈提纲

• 界定目标人群

• 邀请访谈用户

• 进行用户访谈
  轻松开场、挖掘、把控

• 整理访谈数据
  反馈讨论、管理输出

3）访谈注意事项
避免一组固定的问题；
优先关注用户行为背后的原因；
避免让用户成为设计师；
避免讨论技术细节；
避免诱导性问题；
鼓励讲故事；
避免问无法回答的问题，比如如何系鞋带；
避免问基于隐含知识的问题，以及脱离了环境和上下文的问题；
注意面谈者的态度也可能产生有偏见的回答。

2.2.2 问卷调查

不同时间、不同地点、多人参与、分析师观察、验证有限次面谈得出的结论、针对特定问题

• 预先定义问题
• 面对广泛涉众的时候使用
• 统计分析的结果看起来更科学

1）优点
可快速获得大量反馈
可远程执行
可搜索关于态度、信念及特性的信息
2）缺点
简单的分类导致对上下文的考虑较少
留给用户自由表达其需要的空间较小
3）注意事项
选择样本时可能存在偏见
自愿的问卷回答者可能存在偏见
样本规模太小
自由发挥问题难于分析
对答案有诱导性的提问
问题的妥当性
含糊的问题

2.2.3 群体诱导

在一个房间中聚集3~20个干系人
每个人都将自己的观点大声说出来
群体的答案往往比个体好

1）什么时候采用群体诱导技术？
当很多人各自知道关于整体的一小部分时
当人们需要彼此交互来得到一个最优的答案时
当你能把人们聚集在一起时
需要匿名？采用一些工具
在不同的地方？采用一些工具

2）群体诱导技术

2.2.4 研讨会

• 目标
  介绍项目成员和干系人
  收集需求列表
  在会议过程中，运用头脑风暴、故事板、角色扮演、现有系统评估等方法获取需求
• 指导原则（主持人组织研讨）
  给每个人发言机会
  保持研讨话题的相关性
  定义需求属性
  记录需求发现
  总结并作出结论

2.2.5 会议

• 用于总结成果或获取反馈
  1）在每个阶段结束时与干系人安排会议
  讨论信息搜集阶段的结果
  对需求做出结论
  对某项设计所获得的信息，讨论新的发现
  2）通过会议来确认所获得的信息，讨论新的发现
• 会议是重要的管理手段
  1）用于推进系统开发项目的进展
  2）需首先确定会议的目标
  3）需对会议进行仔细筹划
  4）需首先确定会议目标，例如：陈述介绍、解决问题、协调矛盾、项目进展分析、搜集和汇总数据、培训、计划
  5）需对会议进行仔细筹划
  • 日程及设施安排
  • 确定日程并提前通知
  • 根据会议目的决定会议形式
  • 会议期间控制进度和程序进展
  • 对会议进行书面总结，并分发给与会者
  • 正式的陈述报告、项目预演及头脑风暴应遵循一定的规则

2.2.6 头脑风暴

• 目标
  • 通过群组效应，激发对新产品和系统的新想法
  • 在需求不完全明确的情况下比较有用
• 指导方针
  • 采用有组织的研讨会形式
  • 百花齐放、不评价、不争论、不批评
  • 不受现实可行性限制
  • 新观点多多益善
  • 抛砖引玉
  • 互相启发

2.2.7 参与观察法

• 分析师观察干系人进行日常工作
• 分析师越被动越好
• 观察影响观察到结果
• 观察参与者时，进行“动作研究”
• 什么时候观察？
  • 当有人或事需要观察的时候
  • 当知识无以言表的时候
• 方法
  纵深调查：观察者参与被观察对象日常活动，成为组织中的一员
• 优点
  • 总是上下文关系的
  • 能够发现其他方法无法发现的细节
• 缺点
  • 时间成本和开销很大
  • 获取过于丰富的细节，难于分析
  • 无法就改进建议所带来的结果给出更多评论
• 注意事项
  • 有被同化的危险

2.2.8 亲身时实践

• 目标
  • 通过观察和提问了解工作内容
  • 实时实地开展工作
  • 立即反馈
• 指导原则
  • 用户太忙无法安排专门时间来参加面谈
  • 人们并没有意识到在做什么
  • 反复观看一个任务的执行过程
  • 学习任务技能并做给用户看
  • 与用户或顾客建立密切联系

2.2.9 文档分析

• 目标
  • 理解待解决的问题
  • 作为下一步业务流程建模和访谈的基础
• 指导方针
  • 确定当前业务流程或产品的优缺点
  • 找出产品或信息中可充用的部分
  • 从多个来源获取用户需求

2.2.10 原型仿真

• 目标
  • 明确含糊、不确定的需求
  • 简化需求文档，确认需求
  • 今早获得最终用户和客户的反馈
• 指导方针
  • 用于确认需求
  • 用于提供需求评估的数据基础
  • 用于评估不同的用户界面方案
  • 帮助用户可视化关键的功能
  • 直观、有效的沟通工具

2.2.11 情景分析

• 目标
  • 清楚定义有用户参与完成的业务事件的步骤
  • 获取用户可见的动作
• 指导原则
  • 确定与用户间可能的交互：业务事件、感兴趣的领域性质
  • 将业务事件细化为具体业务活动和业务过程

对于用户来说，可能不需培训，客户直接写出他所期望的与系统交互的流程。

2.2.12 概念建模

• 目标
  • 用图形描述现实
  • 建立未来系统模型，即未来系统的抽象表示
  • 在建模过程中对原始需求进行评估、扩展
  • 得到清楚、完整、正确、一致的描述
• 指导原则：模型类型
  分解模型（对子系统结构描述）、数据（ER模型）、面向对象、用例（描述行为为中心）、过程、活动

2.2.13 竞争性需求分析

软件产品设计过程中，演化型产品设计和全新型产品设计。
而基于竞争性需求分析的框架，是对新产品的可行性进行评估。

2.2.14 A/B 测试

产品已经有用户在用，相对用户界面做些改进，但又不知道用户是否会欢迎时，可以配置A/B 测试使用环境。

• 确定待试验的两种UI
• 确定衡量标准
• 确定数据搜索流程
• 确定试验运行时间
• 确定人数（5~10%的用户）
• A/B 测试的技术实现
• 搜集数据
• 分析数据
• 作出结论

2.2.15 用户行为数据在线采集

在线对用户的访问数据进行分析和统计，得到对新产品设计的启示。

• 用户操作数据采集
  交互过程数据、眼动数据、页面访问时间、访问内容数据、用户偏好数据等
• 操作数据统计
  厂商、版本、IP地址、日访问量、地域信息、访问频次、用户身份、访问时长、打分等

2.3 获取技术的选择

• 获取界面需求
  原型法、情景法与建模法比较有效

• 获取业务逻辑需求
  观察法、亲身实践、面谈和情景法有利于对业务逻辑的精确理解和描述

• 对未来系统的信息和数据结构进行获取
  面谈和现有系统分析是最为有效的

要建立完整精确的模型很困难，建立完整的原型也不现实，因此，要根据需要和客观条件灵活运用。

2.4 获取需求注意事项

2.4.1 用户需求获取是一门倾听的艺术

• 倾听干系人的艺术
• 引导干系人的艺术，使得干系人的回答给出有价值的信息
• 协助和鼓励干系人表述他们需求的艺术

2.4.2 什么是“足够好”的需求管理

• 什么是“足够好”的人寿保险？
  1）足够多，所以你晚上可以睡得很安心，即使你不在了你关心的人也能得到很好的照顾
  2）但还没有太多，以致你因为担心保险支付的问题而无法入睡
• 什么是“足够好”的需求管理？
  1）足够号，所以你能让客户满意
  2）但还没有超过一定限度，以致项目延期或超支

2.4.3 比谁更聪明？

• 不要尝试向干系人证明你是聪明的
• 抓住所有的机会表现你认为干系人是聪明的
• 对比这两种情况
  客户问题：我的电梯太慢了
  回答1：好的，告诉我为什么你觉得电梯慢
  回答2：我不这么认为，我觉得你的电梯有吞吐量问题，不是速度问题

2.4.4 维护术语表

• 经验表明很大一部分需求沟通错误是由术语表达存在歧义造成的
• 确定术语表
  1）问这样的问题“X的含义是？”
  2）记录所有取得共识的术语定义

2.4.5 采用合适的需求获取技术

• 只采用一种获取技术是不够的
• 获取技术的选择与项目参与人相关
• 与待理解的需求相关
• 与具体应用领域相关

2.5 各方法使用情况

3. 分析需求

目标：识别系统需求，设计软件体系结构，建立需求与体系结构组件间的关系，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题。
实质：概念建模–选择常用的建模语言，进行功能建模和信息建模
关键：体系结构设计与需求分配

3.1 结构化分析方法

结构化分析方法是最为常用的需求分析方法，着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，建立系统的逻辑模型。核心是建立数据字典。
结构指的是系统内各个组成要素的相互联系；
主要工具：数据流图（数据和处理）、数据字典、判定树、判定表；
三个层次模型为：数据模型（E-R图）、功能模型（数据流图）、行为模型（状态转换图）

3.2 建模

建模的目标

• 描述清楚客户需求，客户能看懂
• 设计阶段的基础，内部技术人员能看懂，但不必写具体的技术细节
• 是验收阶段的标准，验收标准要写清楚

3.2.1 用例建模（角色和功能）

用例建模可以很好的描述系统的功能性需求（谁，做什么），便于理解系统所提供的服务，通过用例模型有利于验证和确认需求，并辅助开发。

用例建模形式：文本描述 + 图形辅助
1）文本描述
・用例模型概要
（1）简要介绍系统的功能与意义
（2）列出参与者列表
（3）用例列表
・用例规约描述
详细描述用例中会发生什么操作或事件，涉及的非功能性需求和规则约束等，也就是要对每个用例事件流进行描述
2）图形辅助
（1）用例图：用来显示一组用例、参与者以及他们之间的关系

3.2.2 流程图模型

3.2.2.1 数据流程图-功能模型（功能如何改变数据的）

从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；

复杂的数据流程图，要分层去画，思路更清晰，更容易理解和阅读！！！

3.2.2.2 业务流程图

1. 单纯业务流程图

2. 业务流程 + 泳道图（角色或状态）

业务流程图结合泳道图，可以将角色和业务流程相结合，流程更清晰易懂。

3. 业务流程 + 泳道图（角色和状态）

3.2.3 类模型

类的划分，哪些属性和哪些方法绑定到同一个类，根据数据流图等进行分析。
同一类型放到一个包里面

3.2.4 行为模型

3.2.4.1 状态图（事件和状态）

通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等）。

3.2.4.2 序列图

3.2.5 ER模型（数据模型）

主要描述实体、属性，以及实体之间的关系。

3.2.6 判定树和判定表

4. 撰写软件需求规格说明书（SRS）

4.1 简介

• 具有一定法律效力的合同文档
• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么（定义边界范围）
• 通过定义输入/输出、以及输入到输出之间的转换方式来描述功能性需求
• 描述经过干系人磋商达成共识的非功能性需求
• 一般参考需求定义模板，覆盖标准模板中定义的所有条目
• 作为后续的软件评估依据和变更的基准（验收标准）

4.2 文档的组织形式

• 文档需要有逻辑组织结构
  如：参照IEEE 的模板

• 典型的组织形式包括
  （1）按系统能够响应的各种外部环境情况来组织
  如飞机着陆管理系统，风速、燃料余量、跑道长度等来组织需求的撰写
  （2）按系统特征来组织
  如电话系统，呼叫转移、电话屏蔽等
  （3） 按系统的响应方式来组织
  如工资管理系统，工资条生成请求、成本计算、打印税单等
  （4）按所管理的外部数据对象来组织
  如图书管理系统，按所管理的书籍类型来组织需求的撰写
  （5）按用户类型来组织
  如项目管理系统，按照经理人、技术人员、管理人员来组织
  （6）按软件的工作模式来组织
  如对文档编辑器，根据文档编辑时的页面布局，分为大纲模式、分页模式、普通文档编辑模式等
  （7） 按子系统的划分来组织
  如飞行器管理系统，命令控制子系统、数据处理子系统、通信子系统、设备管理子系统等

• 文档的主要内容
  （1）范围
  （2）引用文件
  （3）需求
  （4）合格性规定
  （5）需求可追踪性
  （6）尚未解决的问题
  （7）注释
  （8）附录

4.3 软件需求规格说明书风格

• 描述性的自然语言文本
  用户故事
• 从用例模型产生
  • 用例模型与需求转化可看成可逆的过程
  • 如果需求模型以用例的形式表示，我们可以逆向生成需求的完整集合
• 从需求数据库中生成
  • 商业需求数据库有内置的功能来生成经过筛选的需求规格说明
  • 从产品线需求规格数据库中生成特定产品的需求规格说明书
• 从混合模型中生成
  特征模型和用例模型

4.4 选择何使的需求规格说明方式

考虑以下两个具体项目场景：
1）小项目，1名程序员，2个月的开发周期
程序员直接和用户对话，写了两页纸的备忘录
2）大型项目，50名程序员，2年的开发周期
专门的团队进行需求建模与分析，撰写了500页的需求规格说明

项目B需要根据规格说明书中的功能点、工作量来分配人员和时间，对任务进行规划，是很多后续工作的参照依据。
团队人数较多，后续的测试人员、管理人员都需要随时参考，对项目进度进行控制，对项目质量进行把握，整个团队唯一的共同参考媒介。

4.5 生成不同风格SRS 的方法一览

4.6 用户手册作为SRS

• 撰写用户手册作为一种性价比高的一箭双雕的方法，同时获得SRS和用户手册

• 用户手册作为SRS对于和用户交互的系统是比较有效的，这样系统由交互驱动

• 好的手册描述了所有用例的所有场景

  • Fre Brooks 的《人月神话》中描述了将用户手册作为需求规格说明书的做法
  • 据说在苹果的第一台电脑编码工作开始之前用户手册就写好了

• 但是，用户手册并没有描述

  • 非功能性需求
  • 不和用户交互的功能性需求，如函数计算、过滤器或者翻译工具的时候

用户手册大纲

• 介绍
  • 产品总览及基本原理
  • 术语和基本特征
  • 展示格式与报表格式的总结
  • 手册的大纲
• 开始
  • 开始指令
  • 帮助模式
  • 样倒运行
• 操作模式：命令行 / 对话框 / 报告
• 高级特性
• 命令语法和系统选项

4.7 需求规格说明的用户

需求规格说明要覆盖软件产品的功能、外部接口、性能、质量属性、设计约束
不应该包括项目开发计划、产品的质量保证计划、具体的设计方案

4.8 高质量需求规格说明书

4.8.1 一个高质量需求规格说明

• 是所有需求的集合
• 描述产品要提供的所有功能
• 是软件系统解决方案的商业合同的基础
• 是测试计划的基础
• 定义产品需求的度量标准
• 是产品需求跟踪的先决条件
• 影响开发产品的项目计划

4.8.2 高质量需求规格说明的评价标准

4.8.3 保证需求规约是简洁的

• 定义：一个需求描述是简洁的
  • 一个需求只描述了系统的一个独立特征
  • 除了必须的信息外没有包含其他信息
  • 用清晰、简单、可理解的词表述
  • 避免“应该”、“可以”、“可能”之类的用词
• 举例：
  • “急救电话的响应应本着先到先响应的原则” 简洁
  • “急救电话应该按照其拨入的次序存入一个先入先出的等待队列当中，并且按照进入队列的次序逐一应答” 复杂

4.9 需求规格说明生成过程

使用需求数据库时，优先通过数据库，从新生成需求规格说明

• 创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它
• 不直接修改规格说明，修改数据库中的需求并且重新生成规格说明
  

4.10 需求规格说明的结构

基于子系统划分来组织需求规格说明，如下图的分层结构

4.11 需求规格说明SRS 模板

4.11.1 简介

• SRS 需要根据预先定义的标准章节模式来组织，即根据模板来撰写
• SRS 的模板使得撰写统一的SRS 变得简单
• 对于QA 人员来说定义SRS 指标变得简单
• 模板也适用于业务需求和系统需求
• 模板可以被用于半自动地从需求数据库或者用例模型生成SRS

4.11.2 举例（IEEE）

从整体上描述系统的外部接口，相关的用户，软硬件平台以及操作和节点上的一些要求
对系统的功能性和非功能性需求给出详细的描述

重要

4.11.3 SRS 模板的优缺点

优点：
模板提高效率
在有模板的情况下，面对一个完整的大纲，不容易遗漏重要的信息

缺点：
并非对所有的系统，模板的章节设计都是类似的
如果仅仅为了满足标准，而填写模板的所有章节，在不相关的章节，会加入一些没有意义的内容
读者很难将这些无意义的文字和真正的需求粉卡

4.12 需求撰写目标

• 首先在干系人之间沟通需求
• 其次建立合同约定，为后续的验证提供基准，为后面的需求变更提供参考
• 系统的规约可以给技术和非技术用户来使用，所以应该尽快的开始撰写需求，产生一个初始的版本来获取用户反馈，确定哪些属于可以用于进一步细化分类需求，将其定义到需求的列表当中
• 在遇到问题时，直接询问用户往往比咨询场外的专家更为有用

4.13 总结

• 尽快开始写需求
• 确定哪些属性将被用于分类和细化需求
• 产生一个初始版本来刺激反馈
• 询问用户往往比咨询专家更有用
• 撰写需求时需要遵循的法则：
  • 使用简单、直接的语言
  • 撰写可测试的需求
  • 使用定义好的并达成共识的术语
  • 一次只写一项需求，保持需求项之间的独立性

随时准备迎接需求变化

获取到原始需求之后，我们应该本着随时准备迎接需求变化的心态

• 这是一种态度
• 越多的干系人参与，将获得越多的需求特征
• 但不能通过减少干系人的方法来解决这个问题
• 干系人有改变他们想法的权利
• 不要问：“这是你最终的需求吗？”
• 请将变化看成机会，而不是威胁

注意：
统一名词
任何缩写第一次出现时，必须用全称，之后给出缩写称呼