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

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

2、结合现有产品的情况做进一步分析：
 原则：树叶—>树枝—>树干—>树枝—>树叶（树X思路借鉴自《人人都是产品经理》）
 过程：首先，从树叶—>树枝—>树干，其次，从树干—>树枝—>树叶的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以要继续把树干再重新分解成树枝、树叶。总结成一句就是：自底向上的透过现象看本质以抓心核心，自顶向下的将需求逐步分解以指导研发。
  分析过程：
  1）从业务流程的角度，搭建需求框架。
  2）对各个功能需求逐步细化。
  3）将需求分析过程中的疑问形成访谈清单。
  4）与用户沟通澄清，达成一致。
  5）根据澄清意见修订需求。
  6）根据修订后需求及全流程，重新梳理一遍。
  7）考虑和已有功能的关系及并行下的业务处理。
  8）考虑需求的外延（基于新业务规划和运营数据分析），为后续迭代准备。
  9）考虑不同区域客户或同一区域不同客户的易用性需求。
  10）需求查漏补缺，形成闭环。 

读后感：《项目经理应该知道的97件事》中关于“矛盾体的需求说明书”
      良好的需求具体描述了你正努力解决的问题，并描述了为何一定要解决这个特别的问题（即需求需要说明“做什么”和“为什么要做”），这会使程序员在开发过程中更灵活、更高效和更积极。编码人员只有致力于解决问题并深入了解这个问题时，才会做出独立的设计选择。他们应只受限于他们已经选用的技术，而不受限于非编程人员制作的教条式的脆弱说明书。
      将你努力制作的东西与怎样去制作它区分开来。然后，让训练有素的各个团队成员根据他们自己在项目中的角色来做决定。
      倘若不分清用户需求和软件需求说明书的界线，就会导致错误的人在作决定。导致的结果无外乎两种，要么是让软件开发人员来决定什么功能对客户重要，要么是软件项目经理来告知开发人员如何构建代码。无论如何，都只会产出低劣的软件产品。