背景
经过不断的折腾,一切过程都是为了呈现输出,这个阶段就是要交付需求和方案的环节了,很多失败的项目就是上来就到这个环节,倒着捣鼓,先写个文档,做个原型,甚至提出方案,然后再和客户沟通,对于走形式的项目是很经济有效的,可对于大多项目,失败的或者变更的概率太大了。当然,还有一些特色的悖论,比如,没有签订合同,需求分析不付费或者需求分析价值被低估,以及调研的报告容易做他人嫁衣等等,不展开讨论,这也就是做咨询公司的内容。所以,有些项目真的很适合先做咨询,可是能有这种意识的公司还是少数。
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%以上的人,理解业务即可
- 业务分析中有会有很多问题,需要提出解决问题的方案和设计,优化流程等,这本来是目标,不过大多数人用不到,因为多数人是执行层面,螺丝钉的困局
- 各个行业都有其对应的需求模板,所以不要上来就套模板,囫囵吞枣,尽量能解决问题
看模板
模板太重要了,所以就不提供了,自己根据自己的情况设计模板