背景
经过不断的折腾，一切过程都是为了呈现输出，这个阶段就是要交付需求和方案的环节了，很多失败的项目就是上来就到这个环节，倒着捣鼓，先写个文档，做个原型，甚至提出方案，然后再和客户沟通，对于走形式的项目是很经济有效的，可对于大多项目，失败的或者变更的概率太大了。当然，还有一些特色的悖论，比如，没有签订合同，需求分析不付费或者需求分析价值被低估，以及调研的报告容易做他人嫁衣等等，不展开讨论，这也就是做咨询公司的内容。所以，有些项目真的很适合先做咨询，可是能有这种意识的公司还是少数。
Requirements Analysis and Design Definition
任务
- 具体化、模型化需求。注意这里的需求也可以是设计（requirements or
designs）
- 验证需求
- 确认需求
- 定义需求架构 （structures all requirements and designs）
- 定义方案选项 (多个可能的方案，多选题）
- 分析潜在价值和推荐方案 （不同的方案对比，给出最优推荐）
交付
- 需求(具体的，模型化的)、需求（验证、确认的）、需求架构
- 设计选项、推荐方案
概念澄清
Verification vs Validation 用管理的一个术语讲比较容易理解
- 正确的做事 Vs 做正确的事
- 加深一个例子
Need vs Requirement ： 我饿了，need 吃东西；需求：吃水果，吃烤鸭，吃烧烤
Solution vs Design：各种解决办法，最后有个设计。
划重点
- 业务分析包含内容很多，但是对于80%以上的人，理解业务即可
- 业务分析中有会有很多问题，需要提出解决问题的方案和设计，优化流程等，这本来是目标，不过大多数人用不到，因为多数人是执行层面，螺丝钉的困局
- 各个行业都有其对应的需求模板，所以不要上来就套模板，囫囵吞枣，尽量能解决问题
看模板
模板太重要了，所以就不提供了，自己根据自己的情况设计模板
