确定
确定需求往往是承接需求调研而来，目的是搞清楚产品部门究竟要解决的是什么问题，有时候业务部门会要求你能为他们做到些什么，但这种要求往往过于含糊，你还需要再和他们多了解一些信息，才有可能真正了解他们希望得到是什么，避免发生买个MBP回来只为装了winxp玩扫雷这样的杯具……
在确定环节中，这只完成了一半的工作；接下来我们需要知道对应这个需求，会有哪些角色来使用，我们需要能够对这些角色涉及到的不同需求做出细分。这也是需要和业务/需求部门沟通好的。
分解：
分解的意义在于把大问题化解为小问题，变成一个个可控的模块，注意这里是说的可控是指你可以通过一定的约束条件和已知存在的变量来实现对问题的描述。经常看到的所谓需求拆解只不过是把业务部门的需求换个描述方式，这种糊弄人的做法要不得，山寨，害人害己。
大问题变成了小问题，我们就可以来讨论如何去实现了。
至于该如何把大的需求拆解，这里提供两种思路：
要记得，在需求被拆解后的每一个问题有些是对应固定的角色的，而一些则是可认为是无所谓角色区分的共性问题，还有一些问题的处理结果会影响他角色。务须能分清楚来对待。
分解阶段另一件重要的事情就是完成流程图的设计，对应产品人员要做的是业务流程图，如果有核心开发人员也参与了前期的需求讨论分析，可以建议他们同步展开架构流程的思考。
在绘制流程图的时候需要尽可能标明其中的里程碑功能，大约需要哪些功能支撑、需要设计多少个页面或频道、组件，对应的管理后台需要有哪些对应的调用。这时候也需要一并带着整理。我的实践经验是，可以先做完流程图，然后把后面的这些问题带进去思考，一方面寻找答案，一方面也可以完善你的流程图。
如果能够一路坚持走下来，基本上可以做到很完整地了解自己要解决些什么问题了。这时候你面对的就不再是一个总的需求，而是一个个细节的问题。接下来要做的就是对各个问题进行评估，
评估；
如果我们把分解理解为找问题，那么评估就是为解决问题做准备。
鉴于我们在分解问题的时候，其实已经涉及了一部分评估的工作，这里不妨更深一层。例如，你打算使用多少个页面、会有多少个功能点出现。这些经过分析提炼后的内容可以用PRD或者低保真原型的方式展现给相关的开发人员和业务部门。
不过评估最重要的工作并不是要穷列出来究竟需要做哪些工作，而是需要对这些即将展开的工作做出排序，同时你可能必须舍弃一些原本精心构思的内容。
对工作的排序是产品自己无法完成的，需要尽可能和开发部门配合。开发人员对于业务需求有着自己的一套理解，同时由于涉及到很多实现细节的问题，也需要在达到共识的基础上才能继续推动。
因此，在真正展开具体的产品设计工作之前，需要能和开发人员进行沟通，尽可能做到以下几点：我们需要多少个功能点来支撑这个产品或满足需求；这些功能点都是可以在规定项目时间内开发完成的吗；开发人员对于自己要做的事情有足够的判断，知道哪些应该先做，哪些要后置；对于暂时无法实现的功能，是退回给需求方，还是产品重新构思或者延至2.0版本完成，需要说明清楚。
对于没有技术背景的产品，这时候很容易陷入被动，你可能会被技术提出的各种“不好实现”搅得心烦意乱。为了避免这种情况，你最好能找到一个能和你顺畅沟通的技术经理，很多问题其实并不需要你亲自上阵的。
决策：
在经过了前面几轮重重的折磨，才是产品人员真正发挥创意的时候，你将左右会有怎样的表现，你拥有整个产品开发的决策权。别人可以提意见，但是最终你才是那个决定事情该怎么做的人。
制定项目计划，针对每个细分功能拿出具体的实现策略，给出产出物的交付时间，绘制原型图和PRD文档。从产品整体框架到页面布局、频道功能再到按钮的位置，弹出层的设计。设计的创意才在这里真正迸发，你所有知道的界面设计、导航架构、交互形式的知识和才能都会在这里得到淋漓尽致的体现。
暂且撇下你的设计创意不表，如何把评估阶段的成果应用好是我们是否能顺利进入决策阶段的关键。总会有一些功能被砍掉，也有一些新功能提出来，原本想好的某些流程也可能要重新调整。在决策阶段，你需要有做减法的魄力和决心，抛弃一些东西，适当做一些让步，但是要能保证产品的核心功能不被阉割。对于核心功能，任何为了减轻工作量或者无法实现而要求绕道而行的借口都是可耻的；如果你有有充分的理由相信产品的核心功能，那就一定要坚持到底。
写在最后的话：
至此，我们通过确定、分解、评估和决策把需求分析阶段要做的事情做了一个梳理，也为后面的设计和开发开了一个好头。当然你仍然会面临业务部门的需求变更，设计或者开发人员在某个功能或表现形式上跟你死磕的局面，这时候你仍然可以应用这四个步骤来解决具体的问题，但是在实现上需要做一些变通，项目一旦进入到开发编码阶段，时间会非常紧凑，你能做的就是根据新提出来的想法迅速协调好利益相关部门，在开会之前你就能要准备好几套方案，否则会议就会变成一种折磨：低效，浪费时间，不解决问题。
源地址：http://www.lockon.cc/four-steps-to-analysis-requirements