浅谈个人对需求分析的理解：

开始接触需求工作时，在对用户需求的沟通基础上，多依据于做软件开发的结构化思维方式来编写需求文档，这种方式易陷入实现细节的陷阱。如何在用户需求和软件需求之间找到平衡点，使得做出的产品即是用户想要的又在技术可行和成本上性价比最高，甚至超出用户期望，给用户惊喜，开展需求工作时需认真考虑。业内谈得比较多的‘六何法（what、why、when、who、where、how）’，在需求分析工作中同样适用，可作为问题分析的基本习惯。下面谈些自己的理解，欢迎拍砖：

1、信息收集和初步分析：
 what：需求是什么，解决什么人的什么问题（用户群体、用户规模、业务场景、性能指标和组网）？
 why：背景是什么，为什么有这个需求（高层领导思路、团队主动规划需求、竞品分析需求）？
 when：需求的市场时间（实验室验收、试运营和正式上线等各阶段时间）？
 who：需求的用户对象是谁（如：技术部），是否与其他用户对象（如：业务部、内容部、运维部）有关联？
 where：哪里做（现场开发还是团队本地开发）？
 how：怎么做？
  1.关注需求的输入
  2.关注需求的输出
  3.关注中间环节业务处理
  4.关注对历史需求的影响
  5.关注需求的价值延生（前瞻性）

2、结合现有产品的情况做进一步分析：
 原则：树叶—>树枝—>树干—>树枝—>树叶（树X思路借鉴自《人人都是产品经理》）
 过程：首先，从树叶—>树枝—>树干，其次，从树干—>树枝—>树叶的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以要继续把树干再重新分解成树枝、树叶。
总结成一句就是：自底向上的透过现象看本质以抓心核心，自顶向下的将需求逐步分解以指导研发。

3、需求分析过程：
 1）从全业务流程的角度，搭建需求框架。
 2）对各个功能需求逐步细化。
 3）标注需求分析过程中的疑问，形成访谈清单。
 4）与用户沟通澄清，达成一致。
 5）根据澄清意见修订需求。
 6）根据修订后需求及全流程，重新梳理一遍。
 7）考虑和已有功能的兼容性及并行下的业务处理
 8）考虑不同用户（不同区域或区域内的不同对象）的使用习惯差异
 9）考虑需求的外延和扩展，为后续迭代准备。
 10）需求查漏补缺，形成闭关。