本从将从需求分析内容、需求分析过程2个方面来分享2B项目的需求分析相关内容。
一、需求分析的内容
需求分析基本包括以下几个关键词：调研（获取）、分析、整理（编写）、管理，当然了这4个关键词肯定和需求有关的，比如调研是指需求调研。另外，根据不同公司岗位工作的安排，可能有的需求分析岗还有软件产品设计等相关性工作，但不在本篇文章讨论范围内。
调研（获取）：和客户直接或间接沟通，对客户方的业务需求做深入了解。
分析：该过程中发生在调研过程中调研后，对需求的收集不仅仅是“获取”，更重要的是通过分析去挖掘需求。
整理：是对所有需求进行梳理，归类及详细描述，便于其他人能通过你的整理产出物快速准确了解需求。
管理：需求是动态的，需求变更是做项目性需求的常态，要学会适应。对于处于变化中的需求要学会需求管理。
了解了需求分析的内容，可以试着思考需求分析的目的是什么？答案一般包含于以下几方面：搜需求、挖需求、纠需求、砍需求等，个人认为需求分析要用一个词来归纳的话，那就是价值最大化：让软件或产品能够为客户提供最大价值。可能有人不太赞成我说的这句话，由于做项目会考虑到各方利益。但不管怎样，应该保持这样的初心。
二、需求分析过程
2.1 调研
调研的方法有很多种，比如访谈法、会议法、体验法、观察法等，但具体到某个项目就各有千秋了。访谈法和会议法是比较常用的方法，毕竟比较直接有效。在调研过程中，有以下注意事项和大家分享：
（1）找对人
做项目性需求时，一般都有专门的业务对接人或者叫关键用户。做需求调研时，一定要让关键用户在场参与。既然客户方指定某个人为对接人，肯定有是原因的。说明他是能够代表客户方利益，并且对客户方的需求也是有独到见解的。其他参与人的想法或思路，我们不是完全否定，而是要条条记录、层层分析，最后要和关键用户讨论是否要纳入建设范围。
现实中有一些比较缺乏经验的小伙伴在做需求分析时，可能太为客户着想，觉得应该接受客户方所有人的需求。结果把自己折腾得求生不能求死不得，更可怕的是关键用户不认可这些需求，一切都凉凉了。
（2）多沟通、多确认
平常大家可能有这样类似的经历，说话的人觉得自己说的很清楚了，听者也觉得自己明白说话者的意思了，其实双方还是没理解到一块。比如一句话客户说“我们部门工作内容有点多，平常很忙”，客户可能的意思是说他们部门是公司的关键核心部门，而听者可能理解为需要给他们部门减减压。
现实中可能还有些业务专家可能觉得自己在同行业很久了，用户说的他都懂。在和客户沟通时，侃侃而谈，有点“喧宾夺主”的赶脚，这是很危险的。同样的一个问题，在不同客户那可能诉求是不一样的，所以要有耐心，让客户多说话，不要盲目自信。
关于需求确认，个人觉得比较有效的方式是把你理解的意思重复一遍讲给客户听；或者把你理解的意思用具体的业务场景描述出来，比如把你和客户都当成实际需求中的用户，然后把需求描述一遍，让客户确认是否理解正确。
在调研时，不要一直局限于项目范围，因为这样会限制你的思路，也不能全面的去了解客户需求。所以可以暂时不考虑项目的范围，让客户尽情地表达他们的想法，把需求甄别放在下一步。
2.2 分析与挖掘
更准确的说，客户或用户提出的一般都不是需求，而是问题。他们希望我们需要对问题进行提炼，转化为软件需求（解决方案），然后转交给开发人员。从问题到解决方案就是一个思路、分析的过程。
比如客户提出“我们所有的工作都要用软件管理起来”一句话，这是一个10星级的很抽象的问题，作为需求分析人员需求对问题做深入的了解并转化，才能成为软件需求。
另外，有时候客户的想法也是脑门一拍的事儿，所以我们要通过分析去识别出错误的需求或伪需求，这里不再举例，回头有机会会补上。
需求分析的过程也是把控范围的一个过程，比如本次是给客户做一个OA管理系统，客户突然提到说他们的办公用品台账管理太乱了，这个问题很明显就不属于OA的建设范围。
技术是一步一步发展的，客户提出的所有需求并不是技术上都能实现，所有不能实现的需求也要靠分析去识别出来。
以上是对需求分析的概述（转化需求、甄别伪需求、控制需求等）。
满足用户提出来的需求不是目的，建立客户在行业领域的标准化管理体系才是目的。这也就决定了用户提出的需求不一定都要实现，没有提出的需求也不一定不实现。让用户提需求只是实现这个目标的手段之一。
2.3 需求管理之文档管理
从一开始的初步调研到最后的上线，需求管理是贯穿整个需求分析的过程中的。
日常对需求的管理，对文档的依赖性还是挺多的，所以一定要重视文档。有人觉得写文档太浪费时间了，可是从长远来看写文档确实是为了提供效率。如有新人进入团队，他想了解团队之前的工作，如果有文档的话他可以直接从文档中就能了解大概；如果没有文档，那他只能点点滴滴都去问其他人了，中间的苦衷就不言而喻了。
需求管理涉及到不少过程及方法，本篇文章暂时只分享用文档在需求管理中的应用。
（1）版本管理
由于各种原因，如调研不完善、规划不全面、业务有变化等，需求池也是不断变化的，那么如何对这些变化进行管理呢？
下面就说到文档版本的管理，因为需求的记录还是要用文档的。当需求变化或更新时，需要及时更新文档，重要的事情说三遍：及时更新文档、及时更新文档、及时更新文档。
对于规范的需求文档一般都会有文档的“更新记录”这样的类似的章节，每次对版本做详细说明，如本次修改了什么内容、修改人等：
提示：需求文档要保留历史版本，而不是只留最新版本。比如从版本v1.1向v1.11过渡时，应保留V1.1的文件，复制一份V1.1的文件并在它上面修改后作为V1.11。
（2）完成度及优先级管理
在软件开发过程中可以用以下格式的文档对需求进行管理：
由于篇幅有限，暂时对需求的分享先到这里了，以后有机会再对以上某个细分领域继续分享……
毕竟个人能力有限，欢迎大家批评指正。
