需求分析，是一个最简单入门，但是成为高手却非常d难的一个专业。难点在于，貌似没有可以遵循的一个既定路线，不像开发工程师，我学语言，学习框架，学习模式，有很多看得见的阶梯可以向上。
而需求分析很多时候像门艺术，需要的是沟通，是平衡，是裁减，是创意。那是不是就没有学习的路劲了呢？
博主在这里试图把需求进行一定层级的抽象和归类，给出一种类型的需求的分析方式，让你从实际案例中快速的入门，快速的提高。
需求特性：一个全新的功能性需求，没有复杂的业务流程。
实战例子：邮件群组管理需求
五步搞定：
弄清痛点 -> 提出解决方案 -> 梳理需求用例（UML，从角色出发，梳理出场景） -> 梳理非功能需求 -> 定义需求实现优先级 （梳理一定以“全”为原则进行，最后版本安排一定以“解决核心痛点”为原则）
一、痛点梳理【识别价值，判断优先级】 HR的可爱MM找到我吐槽，作为业界著名移动互联网企业，我们的群组维护居然还处于千年不变的手工维护时代，简直兼职不能忍耐啦！ 一听之下，非常合理，那是否我们就应该拿过需求就直接开发呢？ NO。我们还是要冷静下来，分析下手工维护群组究竟有啥痛点：1、新建群组和增加成员效率底下，容易出错；（这个也只是影响到HR MM，就是每周辛苦1~2小时；影响范围：小 严重程度：小） 2、个人维护，不及时，存在错误，会导致信息不能及时传达（这个影响范围就会比较广，会影响到那些没有被及时加入到群组的人；不过就算他没有收到，其他同学也可以转发给他 影响范围： 中严重程度：小）
所以综合判断，价值是存在，但是优先级：低
二、解决方案：外购和自研的选择； 这个需求没有太多个性化的业务背景，是一个适合购买的解决方案，所以第一想法是进行外购。But，供应商联系后，发现人家不愿意做； 内部评估大概需要15人天研发。并且想到就算采购，对接外部厂家也需要投入人力。最终确定自研； 三、功能需求【以UML需求用例方法进行梳理，“角色”＋“场景”】 这个梳理，两个关键词：角色、场景。方法是先罗列出各种角色，然后再列出场景。 角色：群组管理员、部门主管、普通用户 场景：1、维护群组（创建、增加/删除成员、群组基本信息维护）2、查阅自己所在邮件群组列表 从角色分析，群组管理员和部门主管可以进行角色合并；继续分析发现需要一个超级管理员【这个分析过程体现了角色的合并和分拆】 然后出原型和高保真设计 四、非功能需求 1、考虑到企业信息化管理的安全要求，需要有操作日志（安全需求） 2、新增一个群组需要有通知（把审批改成知会，效率&安全兼顾） 3、群组成员数量限制（安全需求） 五、版本计划划和实施 在版本安排的时候，需要考虑需求的优先级。在需求分析的时候一定要把场景考虑全面，但在安排实现的时候就要优先考虑核心需求，并非所有需求都要做，或者说都要同时做 。