一、认识或了解需求提出人需求往往来自于一个idea，当一个灵感的火苗在需求方的心中被点燃的时候，意味着你一段工作的开始，你需要认识需求方，老板、业务负责人，也有可能是甲方客户，科技部负责人等等。跟不同角色的需求方沟通需要你提前准备好应对策略，面向老板你要提前懂产品，面向业务负责人你要提前懂现有业务，面向甲方客户你要有服务意识，面对科技部负责人你要了解IT技术等等。
二、业务流程梳理本文中提及的需求专指系统需求，不是某个小需求或小功能，当你要对某一类项目软件需求进行分析的时候，你得先转变思路，不要从自己的角度考虑问题，而是要站在业务层面，梳理出需求方的业务场景，梳理的越细对于后续产品化越有帮助，在这一过程中，你需要将客户家某一条或者多条业务线进行无差别的场景覆盖，熟悉每一种业务的全生命周期，这一阶段往往是你要跟多个需求方角色进行沟通，因为系统不是一个人用，而各个岗位的人员，所以你可能要和每一类可能会用到系统的岗位角色的负责人沟通、确定、以便能还原出真实的业务场景与在此之后的背景。
三、将业务需求转化成功能需求业务需求梳理清楚之后，在经过你的一番番逻辑处理后，划分为一条条逻辑清晰的功能清单和功能点描述，这里为什么要强调逻辑呢，因为你需要将隐藏在功能中的数据流和操作流与需求方的业务流尽可能100%的匹配！
四、将功能需求系统化成“产品”怎么样才能变为产品，而产品又是什么？我在多年以前将产品前期的打磨过程定义为“需求+策划”，所以有了需求之后，需要通过策划（产品设计、交互设计、UIUE）形成一个产出物，这里的产出物可以高保真的页面，也可以图文并茂的文档，这份产出物是一个中间产物，起着承上启下的作用。既能引导客户又能指导开发。
五、拿着“产品”与客户（也有可能是老板或业务方）达成共识引导客户的过程就是与客户达成共识的过程，双方经过讨论、博弈、争议、妥协、求同存异后，终达成共识！在此标志着作为产品经理的你完成了需求分析的工作，接下来又会是一段新旅程的开始，产品的技术设计、开发、编码、测试、上线....