确定：确定需求往往是承接需求调研而来，目的是搞清楚产品部门究竟要解决的是什么问题，有时候业务部门会要求你能为他们做到些什么，但这种要求往往过 于含糊，你还需要再和他们多了解一些信息，才有可能真正了解他们希望得到是什么，避免发生买个MBP回来只为装了winxp玩扫雷这样的杯具……在确定环节中，这只完成了一半的工作;接下来我们需要知道对应这个需求，会有哪些角色来使用，我们需要能够对这些角色涉及到的不同需求做出细分。这也是需要和业务/需求部门沟通好的。
分解：分解的意义在于把大问题化解为小问题，变成一个个可控的模块，注意这里是说的可控是指你可以通过一定的约束条件和已知存在的变量来实现对问题的描述。经常看到的所谓需求拆解只不过是把业务部门的需求换个描述方式，这种糊弄人的做法要不得，山寨，害人害己。大问题变成了小问题，我们就可以来讨论如何去实现了。至于该如何把大的需求拆解，这里提供两种思路：
1、流程驱动：根据业务流程和业务需求建立对应的uml，或者也可以对应每个角色建立起一个虚拟人物，把整个业务流程完整走一遍，这样可以模拟 出实际操作中会出现哪些具体问题，在完成最终的业务目标前，可能会出现的阶段性目标有哪些，同时又会有什么样零星的小需求出现。很多这些过程中的需求是业 务部门不会提及的，你有责任告诉他们这些情况。
2、公式驱动：以应用类产品举例，如果一个公司可以同时向用户提供两种服务A和B，二者的利润不同，同时又会受到市场季节性需求变化和产能供应 量的限制出现数量上的波动;现在要求我们能够找到合适的资源分配方式，来让公司获得最大的盈利。这其实就是一个根据制约条件来找到A和B两种服务对应各自 需要有什么变量的问题。不妨列出一个公式，看看究竟各个制约条件之间是如何影响的，从而找到合适的解决办法。要记得，在需求被拆解后的每一个问题有些是对应固定的角色的，而一些则是可认为是无所谓角色区分的共性问题，还有一些问题的处理结果会影响他角色。务须能分清楚来对待。分解阶段另一件重要的事情就是完成流程图的设计，对应产品人员要做的是业务流程图，如果有核心开发人员也参与了前期的需求讨论分析，可以建议他们同步展开架构流程的思考。