一、软件项目开发流程介绍
运营，市场等其他部门可能会需要参与其中，对产品的逻辑实现要了解，有助于后面的落地推广。
二、什么是需求分析
准确地理解用户要求，经可行性分析，对系统目标做更详细的描述，对系统功能需要实现完成什么与客户达成一致，解决"做什么"的问题
需求来源
外部需求：
市场（公司业务发展要求、环境变化的要求如移动互联网转型要求、
政策调整（人行、银监会等）、
行业数据（德勤、艾瑞、等机构行业报告）、
竞品（通过竞品分析，需时刻关注行业变化发展）、
用户/客户（用户反馈、调查、问卷）
内部需求：
老板、同事、自己、产品（数据分析、idea）
根据不同时期的产品定位战略情况会产生不同的需求。
战略定位：
决定产品范围方向的控制，如某公司根据战略定位，从目前情况出发只重视积累用户量，所以产品围绕吸引用户量做设计，不需要考虑现金流（烧钱做推广前期占领市场获取用户为主,如滴滴、瑞幸、各大外卖平台、共享单车等都是典型的代表，在资本推动下的运营推广打法都非常非常的凶悍）。
产品定位：
分不同的产品阶段，不同的阶段做不同的产品功能
（起步阶段：试错的形式验证产品可行性，收集用户反馈，稳定发展阶段：做优化丰富产品功能放到线上看用户反馈，迭代阶段：商业模式，形成闭环）
最典型的代表，三级火箭模式（用户--UGC--盈利）
搜狗：输入法--浏览器--搜索引擎（输入法积累了用户，再去做浏览器，搜索引擎留存用户，通过网址导航，搜索广告实现盈利）
腾讯：（qq、微信先做核心简单的聊天功能积累用户，有了用户再去做产品迭代优化开发qq空间，公众号等留存用户,最后做qq会员，皮肤，公众号甚至阅读、音乐、游戏等，最终形成商业模式的闭环）
360：免费杀毒软件积累用户--再做360安全卫士，安全助手，360安全浏览器、网址导航--通过网址导航浏览器搜索广告盈利变现
启示：做产品要有清晰的产品定位战略规划才能赢得用户，赢得市场
四、需求分类
按性质划分：
1、优化类需求
2、新增类需求
3、BUG-FIX
4、idea
按职能划分：
1、功能类（微信的摇一摇、附近的人、钱包）
2、运营类（活动推广，渠道合作、广告投放）
3、数据类的（报表，可能是对内部需要使用如对账类的报表）
4、设计类的（换视觉、色调、UI）
5、其他非功能类需求（性能、安全、应用指标、项目成本），尤其安全方面的问题上行特别重视
产品不一样需求偏向也不一样，思维要转变。
C端产品：注重UI交互设计，用户体验，解决用户个人需求让用户充满新鲜感、满足虚荣心、好玩，如社交类、工具类、娱乐休闲类的app。
B端产品：偏业务性更强，为提升工作效率，解决的是组织生产的需求和问题，如现金管理就属于B端产品更偏重业务性。
五、过程中存在的普遍问题
1、需求提出方或需求分析人员没说清楚他的需求或需求文档比较简单描述不全。
2、需求和开发沟通理解出现偏差，完成的功能和需求要求不一致。
3、进度与预期计划偏离，甚至不可控。
4、需求变更，原有工作推翻
5、新上线功能出现严重BUG。
6、功能完成了但没有对应功能文档，不便后期开发、运维、运营、业务、市场人员进行跟踪和宣传推广。
六、怎么做需求分析
方法论：
1、角色、场景、路径（需求场景分析）
角色：搞清楚提出需求的这个人，他的角色是什么，他提出这个需求的原因是什么，有什么动机，同时多分析不同角色的人需求有什么不一样，不同的角色会有不同层次的需求。
场景：用户需求的应用场景，用户会在不同的场景会产生不同的心理会有不同需求（如钉钉和陌陌都是社交软件但场景一个协同办公，一个是约pao）
路径：解决问题的具体办法
2、5W1H分析法
what ——产品或功能为用户解决什么问题？
Where ——用户在哪会用这个产品或功能？
why ——为什么需要这个功能？和其它产品有什么区别。
when ——用户在什么时候会用这个产品或功能？
who ——产品或功能为谁设计？
how ——用户如何使用这个产品或功能？
弄清楚这个七个问题，可以帮我们更好的理解我们要做的产品，我们的用户群，以及用户场景，帮助我们对产品进行决策。同样可用于功能分析和用户场景分析。
流程顺序：
1、收集需求
2、需求分类（功能类的，数据类的，运营类的可以标成不同的颜色）
3、需求决策（进行需求评审，哪些要做哪些不要做反复确认）
4、需求排序（参照四象限法则进行排序）
5、执行计划,排期（可以反应在需求文档里）
过程中方法：
1、建立个人、项目的需求池，按需求紧急重要程度划分，根据四象限法则对需求进行筛选决策，排定优先级。
2、时刻保持沟通，过程中可以定期进行review，开会讨论碰撞看是否可以进行需求优化合并，做到资源最大化，同时避免出现BUG。
3、文档和产品原型图要及时与客户进行沟通（最好通过邮件确认，历史可跟踪可查），不符合客户要求的要及时修改，并做好修改记录。
4、跟踪推进开发测试进度，收集问题，解决问题，完成后进行还原度确认。
项目要求：
1、需求人员需要保证需求分析思路清晰、讲解清楚、充分结合系统进行分析；
2、掌握对需求工作量的评估，保证其负责开发人员的任务饱和度（要能看到未来两周的开发任务）、报工准确度（自己要先了解清楚如何报工）以及后续需求报工的跟踪；
3、需求分析时找项目负责人确认测试负责人，让测试负责人也从测试角度分析设计的合理性；
4、负责需求规格说明书以及详细设计文档的产出；
5、拟定需求或项目整体计划，开发与测试计划详细计划安排开发组长和测试组长给出；
6、对所负责需求整个周期（分析-设计-开发-测试-验收-投产）的进度跟踪；
7、对存量功能或系统进行逻辑梳理，并形成文档（系统或功能说明书、表结构、流程图等）；
8、完成功能或系统逻辑梳理后，需组织全体组员进行培训。
关于四象限法则：
我们每天面对的各种繁杂的事情，都可以按照重要和紧急两个不同的维度进行区分，按照下图的方式，将所有的事情分为四个象限。
需求分析产物
1、业务流程图
2、思维导图
3、需求规格说明书
4、BRD，商业需求文档（非必须）：
主要面向项目立项，用户公司的发展，就需要对产品前景进行展望以及所要消耗的资源的权衡,决策层使用。
5、MRD，市场需求文档（非必须）：
面向市场，这里要重点去分析产品去市场上如何短期、中期、长期生存。核心用户的需求等。
6、产品原型（PRD）：
主要面向团队开发人员，设计、程序、运营等，我们需要更加详细的去阐述所有功能，详细功能说明（功能清单、优先级、功能目的、功能详细说明）、业务流程（业务流程、用例）、业务规则、界面原型（界面流程、界面原型）、数据要求（输入输出、极限范围、数据格式等））。
7、详细设计文档
一些常用的文档工具：
原型工具：Axure、MockPlus、磨刀，
思维导图：Xmind、百度脑图，
流程图：Visio、process（在线工具，多种图都支持）
八、思考点
1、用户需求不等于功能，不能把功能当需求，不是用户怎么说，产品就应该怎么做
（用户的需求远不止功能，还有深层次的需求，需求分析必须深挖功能背后更深层次的需求，所以经常问自己，我的产品满足了用户的什么心理需求）。
2、墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，它总会发生
（需求分析、写代码、测试考虑问题要全面要深让系统拓展性安全性更强减少BUG）。
3、三级火箭效应（不同的阶段思考不的问题，做事要有规划目标，要有定位，战略目标）。
4、四象限法则（合理的安排时间执行计划）。
5、沟通沟通再沟通（避免信息丢失，保持战线统一，提高工作效率）。