怎样与用户有效地沟通以获取用户的真实需求？

  1) 访谈，正式访谈系统分析员将提出一些事先准备好的具体问题；非正式访谈中，分析人员将提出一些用户可以自由回答的开放性问题，一鼓励被访问人员说出自己的想法。需求分析的目的就是获取用户的需求，面对面的访谈可以更好更直接的了解用户的需求。

  2）面对数据流自顶向下求精，

  3）简易的应用规格说明技术；所谓的简易的应用规格说明技术就是第一次简单的访谈过后，软件人员和用户方面各自写出规格说明书，再约定时间相互讨论，去除冗余的部分。这样可以提高用户的参与。

  4）快速建立软件原型， 根据用户提出的需求，建立一个简单的模型，再跟用户进行讨论，可以更直观的将软件系统展现出来，可以更好的明确用户的需求，也可以引导用户将模糊的需求明白。 

详细描述小组项目的需求是如何获得的

一、明确项目干系人 

项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织。项目干系人对项目的目的和结果施加影响。应当从项目的启动开始，项目管理团队就要识别项目用户方干系人包含哪些人和组织，通过沟通协调确定他们的需求和期望，尽最大可能地明确项目干系人中的决策者在项目中所起到的作用，以确保项目获得成功。 

很多项目往往都是由客户单位的技术主管部门主导，项目经理在前期接触时，跟这些技术部门接触的比较多，而没有和业务部门或系统开发完成后的实际的使用者接触。该类人员对技术比较精通，但对应用部门的相关业务可能不是特别熟悉，从而导致项目组获取到的需求发生偏差，在软件开发完成后和用户的实际需求相差甚远，导致用户频繁提出需求更改，更有甚者推翻重建。

因此项目经理在与客户初次接触时应首先明确干系人，识别项目干系人及其角色，确定项目组的组织架构，确定项目组各干系人的职责范围，确定对需求实现的最终决策者。 

二、熟悉业务采用合理方法获取需求 

在明确了项目干系人后，那么在这个项目中各个业务场景，业务流程，业务规则，组织结构和岗位角色就是我们在接下去所需要重要调研的内容。而往往一些项目经理在获取需求的过程中，仅仅是充当了一个“书记员”的角色，即客户说什么？他就记录什么？在获取的过程中缺少与客户的互动。我们的的目的是为了搞清楚用户的业务现状和问题，而不是简单的听到或问到用户要什么，因为有些客户自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。 

我们一般可以通过双方对需求的了解情况上，分为四种情况：开发方和用户方都清楚项目需求；开发方不清楚项目需求但用户方清楚；开发方和用户方都不清楚项目需求；开发方清楚项目需求但用户方不清楚。针对这四种情况，我们可以采用问卷调查法、会议讨论法、界面原型法、原型系统法来获取客户的需求，这四种方法可以在需求获取过程中组合使用。我们结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。 

因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，这样才能设计出真正符合客户需求的系统。通过界面原型法或原型系统法，使客户人员能够比较直观的明白以后他们的业务流程在系统中是如何展现的，使客户人员对系统有一个观感上的认知，同时项目组成员也能够明确客户所期望的产品是怎么样的。 

使用上述方法有以下优点：(1)增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化；(2)可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。

      三、分析需求的可行性 

在需求获取过程中，项目组收集的需求往往存在以下几问题：⑴需求范围超出合同范围；⑵对同一功能，各干系人提出的需求不一致；⑶存在明显不合理的需求；⑷对需求理解发生偏差。因此对获取到的需求进行有效、准确的分析是必不可少的步骤。 

在项目建设过程中，不同的项目用户方干系人其愿望和追求的目标可能会存在不一致，有些干系人的期望值较高，远超合同建设范围；而有些干系人提交的需求，相互之间不一致，造成需求冲突。因此需求分析人员应对获取到的需求进行整理并进行有效分析。对于超出合同范围的需求，可由商务一起协调进行增补或在二期中进行建设；对于需求不一致的，可召开项目协调会，由甲方最终决策者拍板确定或寻求平衡点折衷处理；对于需求理解偏差和客户描述不清的需求，可通过原型界面法，反复确认。因为对于需求分析是需求管理中很重要的一个工作部分。 

对获取到的需求，进行优先级评估。需求分析人员应分清客户提出的需求，哪些特性是必要的，哪些是重要的，是需求开发的主要部分，设定这些需求的优先级，并与客户进行讨论明确。因为开发者应该按照客户的观点决定项目需求的优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。 

在需求分析过程中，应尽量使用已有的软件组件来实现，以节省资源。需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。 

很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。  

 四、编写需求规格书和进行需求评审 

在准确领会客户的意图后，软件需求规格说明书就是需求分析阶段需要产生的最主要的文档。准确而详细地编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，在编写文档时，开发人员严禁采用“猜测”的方式编写。在需求文档中暂时加上“待定”标志是个好方法。用该标志可指明哪些是需要再进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上 “待定” 。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。 

需求规格说明书的每个功能点的描述要通俗易懂，能够使客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。所以分析说明书对功能细节的描述不能有歧义或二义性，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。 

需求规格说明书一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的审核，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。 

需求文档完成之后，并不是把它扔给后面的设计人员就了事了。作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。 

五、做好项目需求变更管理 

在软件项目建设过程中，需求变更是不可避免的，但在开发生命周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。分析人员及时评估，为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。在不放弃所提出的需求变更情况下，对每项要求的变更进行分析、综合考虑，最后做出合适的决策。 

造成需求变化的原因有很多。比如:随着项目的进展,开发方和客户方对需求的了解越来越深入,原先的需求文档可能存在这样或那样的错误和不足,因此要变更需求;以或者由于市场、业务发生了变化,原先的需求文档可能跟不上当前市场的要求,因此要变更需求等等。需求的变更问题是每个开发人员、项目经理都会遇到的问题,需求的变更不一定是坏事,常常提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。但是一旦需求发生了变化,随之而来的将是不得不修改设计、重写代码、修改测试用例、调整项目计划等问题,对项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,这将为项目的正常进展带来诸多的麻烦,开发小组也要为此付出较重的代价。 

当然在软件项目建设过程中，并不是所有的需求变更都能够被采纳的话，要学会适当的拒绝，通过变通的方法实现。否则有可能，这个项目也许永远不能按时完成，进度无限期滞后。因此在需求变更过程中最难办的事情就是拒绝客户提出的需求变更请求,通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。因此作为一名项目经理，你应当规范需求管理，对客户的需求变更进行评估分析，对变更带来的影响、成本和得失告知客户。当然开发人员不能由于不想实施变更而随意夸大评估成本。

NABCD模型的介绍

Need（需求）—现在市场上未被满足但又急需满足的客户需求是什么？
Approach（方法）—要满足这种需求，我能够提出什么独特的方法吗？
Benefits （收益）—该方法给顾客提供的便利是什么？
Competition (竞争) —对于竞争对手和其他可选择的方案来说，这种单位成本收益的优势在哪里？

Delivery（推广）

列出产品的功能，并分别放到四个象限中          

第一象限

参考其他系统的优劣势，找出劣势，并且查出为什么以前人们没有想到这个劣势，把重心放在如何弥补其它系统劣势上

第二象限

要讯速完成基本框架设计，多与需求者沟通，让需求者试用，提出问题，及时更改程序，达到一个完美的框架

第三象限

检查本系统中不符合要求的地方，组员多多讨论，及时的更改，做出成品

第四象限

用户检测成品质量，看是否符合需求，如果有问题及时的修改系统，达到最初的客户需求

汽车管理系统