项目需求分析：做好需求收集，做客户真正需要的

（一）软件项目需求分析

对于软件开发团队而言，软件开发的全过程是：做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。
而在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。
今天，我们首先来谈一下软件项目中，需求究竟该怎么分析？

正确的需求分析决定了我们产品的方向，需求分析搞错了，做再多都是浪费。只有方向对了你才能走出迷途，方向错了，你只能迷失！基于此，我们的需求分析可分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。 

收集需求
需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。
1、还原场景
如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。
我们可以从以下场景进行分析：
基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去。
基于什么用户：具备什么特征，比如身份、收入、区域.....
基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......
场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
2、多问几个为什么
用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能发觉用户背后的需求。
3、数据分析
数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。
4、多和别人沟通/头脑风暴
一个人的力量是有限的，当我们吃不准的这个用户需求的时候，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。

处理需求
处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。
2.设置优先级
一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；
从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。
3.竞品分析
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
4.需求评审
在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。
需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。


（二）项目需求分析怎么写

项目需求分析的概念　　
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
　　狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
　　需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务　　简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程　　需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
　　问题识别
　　就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
　　分析与综合
　　逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
　　制订规格说明书
　　即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
　　评审
　　对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法　　需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
　　原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
　　原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
　　原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
　　在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
　　追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

（三）项目需求管理：客户真正需要的

一个项目的成功需要多方面原因，人力资源、需求范围、项目成本、进度控制、质量监督、风险监控、资源采购、干系人沟通，每个方面出问题都可能会导致项目的失败，所以项目管理也要有一套系统的管理办法。首先，我们需要明白的，是你的爱到底是什么？
对于无边界的需求蔓延，我们应该怎么办？为了更好地做好项目 ，你可能对项目进行需求镀金吗？
行文之前，讲一个故事：
客户：我家有三个小孩，我须要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。
项目经理：秋千这东西太简单了，秋千就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。
分析员：这个无知的项目经理，两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。
程序员：两条绳，一块板，一棵大树，接在树的中段；太简单了，工序完成。
商业顾问：您的需求我们以完成，我们通过人体工学，工程力学多方面研究。本着为顾客服务出发，我们的秋千产品在使用时给你如同游乐园里的过山车一样刺激，如同你在地面上坐沙发一样舒适与安全。
文档管理员：这么小的工程没有文档很正常，只要需求说明书与合同就可以了。
实施人员：我们的产品用户自己都可以完成安装，只要把绳子系在树上就可以了。

你的“客户”描述的期望。

项目经理是理解到的期望

设计师设计出来的

开发人员实施开发出来的

测试员们得到的

商业顾问形容的

项目档案纪录的

它是怎么付诸于实际的

广告是如何做的

它是如何被支持的

顾客如何买你的帐

客户真正需要的
为什么会这样？如何正常确地理解客户真正想要的，是一个项目最终成败的决定性因素，方向错了，再努力也白搭！
项目最重要的阶段是进行需求分析，明白真正的需求。项目需求指是用户真正需要什么，而不是供应商假设用户需要什么和供应商能够供应什么。需求的准确定位就是要按用户要求，对目标系统提出完整、准确、清晰、具体要求。这对一个项目的成功来说非常重要，需求分析做得不好，就会造成需求不断变更，从而影响进度、费用，甚至会导致项目失败。
因此，在项目执行之前，你需要了解以下几个问题的详细答案：
1.你被指定要解决的业务问题是什么?
2.你的项目发起人期望达到的业务目标是什么?
3.为什么说你的项目对经营战略很重要?
4.你的项目范围是什么?
5.对于你要改进的流程而言，客户的需求(CTQ)是什么?
对于一名项目经理来说，做出让客户满意的产品是我们的终极目标。但实际情况会是这样吗？实际项目过程中，我们可能面临如下诸多问题：
需求范围不明确，合同中规定的内容往往都是模糊不清的，需求不明确，或者只有几行说明，而且还可能有大断的套话、官话。
需求定位不准，项目团队在大多数情况下对于项目了解和理解很少，对项目的背景在广度和深度两方面的挖掘不够、认识不足、把握不准，从而导致了项目需求定位不准。
需求理解不一致，对同样的内容客户的理解与我们的理解不同。同样的文字，对细节的理解可能就是不同的，但实现的细节客户提供的需求里可能根本就没有提。
有些需求并没有直接写出来：话多为隐晦而不直白的说出，客户提的多是自己期望解决的需求，而对于最基本需求往往不说，因为他认为你就应该有。如做一款手机，手机打电话的功能客户是不用说的；
项目结束前客户总有提不完的需求，客户总是会在结项前提出各种需求，前期没有讨论过的各种需求都会在这个时候冒出来，让项目被动受制。这种情况原因一般有两种，一种是在项目开发过程中没有与客户充分的沟通。另一种就是客户生怕项目一结束付款，你们就不会再很好的支持我们了。那么所有需求不论重要与否，你都要在结束前给我做完。
项目经理无条件的迁就客户；或者为了追求完美，自作主张地给项目增加新的功能需求，以更好地让客户满意。
需求不合理，用户无法提出完整、详细需求，或用户认为已经明确表达自己要求，但实际上项目团队并不能按照用户所想象的那样去理解他们的需求，用户对于项目期望过高，或希望在短时间看到效果，但由于技术却满足不了要求，导致需求过度。
实际工作中可能还有各种各样的情况，我们要善于思考，勤于总结，找到适合自己的应对之策，下面讲一下个人以往经验：
1：确定项目范围，使用KANO模型来帮助自己，了解什么是Must Have的，哪些是should Have，以及哪些需求是Nice to Have的。只有建立在这个基础上，才能在大方向上不会有偏差。必须满足的需求往往都是理所当然的客户普遍讨论或出现问题的更多“越多越好”的特性愉悦因素一般不被提及，因为客户不会因为缺了这项就会不满意。

2：多问问Why：对于客户每提出的新需求，我们尽量多了解他的目的是什么，多问、多想，当我们知道客户的终极目标时，我们就可以主导客户需求了。同时，我们了解了客户提此需求的目的后也有利于我们对需求的更好把握，不至于项目需求出现偏差。
3：力求需求理解一致：需求理解的一致性是项目成功的基础，在项目管理的各个阶段，要让所有相关人正确的了解和把握需求。
4：让客户参与到项目的各个阶段：拉着客户参与到项目的各个阶段，需求分析、总体设计、详细设计、测试，并随时让客户了解和提出自己的想法。尤其是在需求分析和设计阶段，当整理完需求文档和设计文档时，一定要请客户一起参与评估，以避免需求理解不一致，需求范围不确定等问题。要让客户对需求进行确认。与客户确认需求后，尽量让客户签字认可，如不能签字也尽量让客户方领导在正式场合当面确认。
5：做好服务，让客户信任：之所以在项目结束前尽量让我们把所有能想到的做好，有时还提出各种刁难，就是怕在项目结束后就不能很好的给予支持。建立完整的服务机制，让用户看到我们的服务。如果客户对我们认可了，相信以后的服务过程中就算有了问题，我们也会及时处理，那么客户才有可能允许把部分非核心需求放到将来处理。信任是种力量，让客户信任，就要始终如一的做好服务。


(四)做好项目中的需求收集

需求收集真正的体现了需求的市场和用户驱动。访谈，调查表，头脑风暴，竞争对手和产品分析都是需求收集的方法。需求收集我们需要搞清楚用户真正的需求，问题背后的深层次问题，这样才可能为挖掘需求提供数据。需求收集的过程应该流程化，收集的需求应该分类入库的归档化。必须将需求收集活动看做为一个结构化的流程或过程，以真正的促进收集的过程和采集的数据的有效性。

收集的需求在论证分析中应该确定优先级，而优先级的确认应该引入价值工程，即我们应该认识到一个需求的重要性应该体现到它对产品价值的短期和长期的增值上面。要理解这个，就必须要考虑收集的需求是普遍需求还是特殊需求，是核心业务对应需求还是辅助业务对应需求，是使用频率高的需求还是偶尔使用的功能点需求。我们必须有清晰的头脑来分析用户急的是否就一定是优先级高的需求。

用户往往习惯了给我们提希望系统实现什么功能，这些需求往往是用户已经转换后的需求而不是原始需求。当用户遇到业务上的问题的时候他们往往假设了一种实现方式，如果在需求收集过程中错误的把问题的解当做需求，则我们就忽略掉了真正的原始需求。需求收集的重点应该在用户真正面临的问题域和问题场景的收集。

需求收集人员的业务背景和经验往往对需求收集有效性有很大的影响。需求收集的访谈过程不是简单的听用户如何讲，而是需求我们去引导用户讲出他们真正面临的问题。通过我们积极的沟通让用户把他们真实的想法真正的表达出来。

需求收集是整个软件产品开发的源头，是确定产品方向和定位的重要活动。需求收集活动出现大的误差将是方向性的重大错误。如果我们开发出来的产品不能真正满足用户的需要和得到用户的认可，那产品本身就不可能创造价值，及时这个产品有很好的质量，易用性和功能等，这个产品仍然是失败的。

需求分析和开发

需求分析工作需要意识到是包含了业务分析和系统分析两部分内容。对于业务分析包括了业务流程分析，组织结构和岗位角色分析，以外的对象分析，数据流分析，重点是描述现在。系统分析的内容重点是将需求转换为系统可实现的软件需求，因此必须要考虑到需求的可实现性，如果对于面向对象分析则重点在用例分析，业务对象建模，业务规则分析。系统分析最好是有软件开发经验的人和业务背景的人进行，这里的一个重点就是要把软件开发中已经成熟的分析模式和模型和实际的业务进行匹配。

软件产品要能够适应需求的变化，不仅仅是软件架构上的可扩展性考虑，更重要的是在需求分析阶段就需要考虑软件需求如何适应用户需求的变化。对应用户经常可能变动的需求点进行抽象，引入一些标准的可配置的模型，如权限模型，工作流模型等。软件需求对业务需求和用户需求的一个处理要点就是会考虑到哪些经常变化的需求需要转换为灵活的可配置的需求。

用户都不清楚自己要什么或者说用户的需求经常变动更应该促进我们去改进需求分析和开发的过程。在这个时候系统分析员的开发经验和业务背景将起到很重要的作用。需求的一种变更对于软件开发往往是一种必然的情况，只是如何把它变更的范围控制住，如何实现需求的变更不是要修改设计和编码，而是通过灵活的配置来实现的。

收集来的用户需求如何转换为需求规格说明书，中间的一个重要过程就是需求分析和开发。这样正好体系一些需求分析工作的重点内容，通过识别需求的优先级以更好的安排项目资源和进度，有的放矢。通过对原始需求的分类，合并，抽象以提取通用的需求模型。通过识别非功能性需求以增加整个系统的健壮性，性能和易用性。通过对需求模块单元的划分，流程和规则的描述，功能点分析为项目进度计划安排和进度跟踪创造条件。因此我们将需求分析是一种业务和系统的模式匹配，如果才能够匹配好就是需求分析的责任。

需求管理

应该首先看到需求管理的目的首先为项目管理服务，结构化的需求管理使项目管理真正做到可视化，另外需求管理为用户服务，通过有效的需求管理能够更好的满足用户的需求，提升用户满意度。最后需求管理为后续项目提供支持数据和依据，因为需求管理的内容是结构化和文档化的，这些是内容是项目重要的过程资产。

要管理需求，则我们的需求必须是结构化和文档化的，否则就谈不上需求管理。因此需求管理必然会涉及到配置管理相关工作。同时为了量化的说明需求管理的有效性，我们的需求本身又必须是可度量的，需求功能点的粒度应该在一定范围内。需求规格说明书是需求管理的重要对象，必须文档化，而且会在整个软件开发生命周期中被多次使用到。

需求全生命周期的管理的一个重点就是需求的状态管理，用户提出来的需求就是是否实现了，现在处在哪个环节都需要依靠需求的状态管理和跟踪来实现。因此需求分析阶段需求功能点的条目化就是需求状态管理的一个重点，而需求状态跟踪的过程正好就是我们对项目进度和状态的跟踪过程。如果项目管理的状态监控的好，则需求状态管理也可以做好，同时拆分后的需求状态管理为我们增量和迭代开发提供了基础，有了这个才可能真正做好项目挣值管理，才可以更好的应用挣值中的0-100原则。

需求的变更控制重要性体现在真正的使甲乙双方对范围的承诺有共同的重视。当有了共同基准依据的时候才能够真正的体现用户满意度上面，同时需求变更真正的体现出项目计划的严肃性，保证项目计划的受控和严格执行。需求老发生变动，项目老延期都是需求变更没有做好的一种表现形式。对于已经开发完成的软件产品，我们更需要有结构化的需求变更流程，将变更的影响分析影响植入到流程中，这样才可以保证整个软件产品的稳定性。