多数公司，在工作中很少把需求分析当成规范性的操作流程，通常都是需求分析人员在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。
首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。
产品需求分析实际上就是需求决策。无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。
需求分析步骤如下
1.需求收集：
a, 是否在OOTB文档范围内，不是的话。需要提交项目经理审核。
b, 分析需求的业务背景，确定需求是否成立。引导客户产生合理有用的需求，要考虑公司的战略和产品的定位。
c, 即使需求成立，并不是所有需求都要一次实现。是否可以暂缓做。比如运营监控类的需求。
2.需求分析：
把需求分类，比如：rating、billing、运营监控、数据迁移、还是跨模块的。和相应的研发人员一起，提供解决方案。反馈到客户review。这是一个反复的过程。
输出：
需求文档生成，
解决方案文档生成，
3.需求实施：
工作量的评估，
安排实施计划，根据紧急程度(showstopper,urgent,important,general)
需求分析人员具备能力
核心的内容就是
1.对业务熟悉，能够准确的把握的需求。并进行有效的分解，分配。有阶段的对研发交待清楚任务。
2.协调客户和研发，最重要的是沟通，但是绝不能当传话筒，把双方的抱怨传来传去，让负面的情绪截至在自己这里。让双方都朝着达成目标的方向前进。
研发和客户的利益并不一定一致怎么办？
自己的立场就是结果导向，目标把事情做成。首先确定冲突的原因是：进度，优先级和资源？ 然后采用鱼骨图确定主要原因，解决掉。
1. 提早让研发入场
2. 把事情分解：
一致的地方，列出来
不一致的地方，列出来
针对不一样的地方，再深入沟通。
客户管理
1. 和客户建立伙伴关系，尽量搞好关系。
2. 主动积极的去理解客户的需求，引导客户需求，避免过分变更和不必要的变更。
3. 需求变更的的规范化管理。
第一个故事
1. 有一个需求，谈了1个月，评估了70个人天的工作量，后来在一次会议中听到一个客户端的人说，这个功能推出 2 3年了现在只有1000个用户，基本没有新增用户，每年也并没有多少收入。我们就建议客户 不要在新系统中实现该功能了，建议在市场侧给用户补贴，或者免费使用新的产品的方式，逐步让用户替换这个功能。
第二个故事
项目做到2014年的时候，xxx开始了丹麦电信项目的准备。杭州的研发中心同时支持两个项目。丹麦项目由于处于项目验证阶段，工作量非常的多。这时候对yyy项目的支持力度弱了很多，经常的邮件 3 4天回，电话要不不接，要买接的时候就说很忙。导致了yyy的现场对客户答应的交付进度，经常延迟，对需求的影响速度也很慢。产生了很多矛盾，但是又不能告诉客户说公司关注另外的项目，不管这个项目了。
后面，我和就研发商量说，你们也很辛苦，现场和研发安排成这样：
首先你们把泰国项目和丹麦项目人员分开，把容易实现的先交付。
第二：现场协调客户，把容易实现的需求，优先级和交付日期提前。比较难的需求，优先级和交付日期推后。
