背景

经过不断的折腾，一切过程都是为了呈现输出，这个阶段就是要交付需求和方案的环节了，很多失败的项目就是上来就到这个环节，倒着捣鼓，先写个文档，做个原型，甚至提出方案，然后再和客户沟通，对于走形式的项目是很经济有效的，可对于大多项目，失败的或者变更的概率太大了。当然，还有一些特色的悖论，比如，没有签订合同，需求分析不付费或者需求分析价值被低估，以及调研的报告容易做他人嫁衣等等，不展开讨论，这也就是做咨询公司的内容。所以，有些项目真的很适合先做咨询，可是能有这种意识的公司还是少数。

Requirements Analysis and Design Definition

任务

1. 具体化、模型化需求。注意这里的需求也可以是设计（requirements or

designs）

1. 验证需求
2. 确认需求
3. 定义需求架构 （structures all requirements and designs）
4. 定义方案选项 (多个可能的方案，多选题）
5. 分析潜在价值和推荐方案 （不同的方案对比，给出最优推荐）

交付

1. 需求(具体的，模型化的)、需求（验证、确认的）、需求架构
2. 设计选项、推荐方案

概念澄清

Verification vs Validation 用管理的一个术语讲比较容易理解

1. 正确的做事 Vs 做正确的事
2. 加深一个例子

Need vs Requirement ： 我饿了，need 吃东西；需求：吃水果，吃烤鸭，吃烧烤

Solution vs Design：各种解决办法，最后有个设计。

划重点

1. 业务分析包含内容很多，但是对于80%以上的人，理解业务即可
2. 业务分析中有会有很多问题，需要提出解决问题的方案和设计，优化流程等，这本来是目标，不过大多数人用不到，因为多数人是执行层面，螺丝钉的困局
3. 各个行业都有其对应的需求模板，所以不要上来就套模板，囫囵吞枣，尽量能解决问题

看模板

模板太重要了，所以就不提供了，自己根据自己的情况设计模板