在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，若在系统测试时发现则需要5到17个小时来修复。要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出大约100倍的成本。因此需求管理作为软件项目管理的一个重要内容，贯穿项目实施的全生命周期。俗话说：万事开头难。需求作为软件开发的第一个环节，其重要性不言而喻。市面上关于需求管理的相关理论和书籍很多，但多数停留在理论层面，实操性不强。

1、与用户进行充分沟通

通常，与用户沟通前的准备时间要远远大于正式会面沟通的时间。一般情况下，用户在和你连续交谈两个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作至关重要。准备工作包括对项目整体环境熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的熟悉工作需要了解:项目的背景、项目的目的、项目的利益相关方等信息，以便对当前项目的整体情况有一定了解。对具体业务调研前的准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等内容。要充分珍视用户的时间，尽量避免由于准备工作不足而反复约见用户，给用户造成效率低下的印象。一旦发生这样的错误，以后可能就会很难约见到用户。需求获取的核心内容是通过调研掌握软件项目的实际需求，以便于指导整个项目的实施。需求获取的主要方法包括：用户访谈、问卷调查、现场观摩、头脑风暴等方法。在实际的项目操作过程中，相对比较明确的需求，我们可采用比较固定的需求获取方式，比如：问卷调查等。而对于相对比较模糊的需求或者说用户无法清晰表述自己需要的是什么的时候，我们可采用比较灵活的方式，例如：用户访谈、现场观摩等。需求的类型主要包括：业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，我们都需要自顶向下或自下向上去了解用户真实的想法。业务需求的获取对象主要是客户的高层领导，我们都知道，项目的发起、实施、最终的成败很大程度上都取决于高层领导，我们需要对他们进行访谈，了解高层领导的公司战略、发展方向，更为重要的是获取他们对将要开发的软件系统的期望，以及希望该系统在解决现有业务问题，对公司整体战略的支撑方面的期望。帮助我们去更好地理解系统的宏观构想。在掌握了业务需求后，我们需要对中层管理人员进行调研，核心问题是搞清楚在宏观战略目标落地的这层，或者说指标细化并负责实施的中层他们对软件系统的期望以及实际要求，他们或希望此系统能够带来工作便利，或希望此系统能够做到精细化管理，如此等等。但他们都是具体的业务部门负责人，对自身的业务以及系统对业务的促进方面，有比较深刻的体会。最后，我们需要在掌握了业务需求、用户需求的基础之上，通过对IT管理部门、主要操作人员的需求调研或根据我们对需求的理解，细化出系统的功能需求，这个需求是最低层次的需求，也是一个层层落地的过程。

2、主动积极了解客户业务和相关知识

在技术方面我们可能非常专业，但对于具体的用户业务可能并不十分清楚。这个项目对用户是否有帮助、某一系统功能是否有用、某一流程处理是否合理，在不了解用户业务的情况下，我们将很难做出判断。因此只有在了解业务的基础上，我们才和用户有共同的沟通语言和业务理解，才能真正理解系统应具有哪些功能。曾在经销商管理系统调研过程中，由于财务方面的知识有限，使得在对经销商财务部门的调研中对部分问题不是特别的理解。向用户虚心进行请教，并在调研结束后及时对自己的财务知识进行了补充。应用领域的知识是无边无际的，在各种项目的调研过程中，肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作的准确、顺利进行。遇到此类问题时，需求分析者应虚心向用户请教，同时应及时补充应用领域的知识。最好能够在调研前做好充分的准备。

3、引导用户，使用户充分表达自己的想法

在与用户交谈中，如何引导用户说出他们的需求是非常关键的。恰当的提问，会使用户滔滔不绝，充分发表自己的意见和建议。而不恰当的提问，可能会导致用户无法回答或敷衍了事地进行回答。提问可分为封闭式提问和开放式提问。封闭式提问目的明确。如:现在你们的送货单是手工填写还是电脑打印?但过多使用封闭式提问，会导致谈话枯燥，让用户感觉自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释，可使谈话达到一定的深度和广度。如:你认为目前的工作中存在哪些可以改进的地方?开放式提问缺点是容易使谈话内容偏离主题。因此在谈话过程中，应采用封闭式和开放式提问相结合的方式。以简单问题开始、从用户熟悉的内容开始。每次只提一个问题、集中一个重点，宁问勿猜。并尽量避免使用IT相关的一些术语，以便用户能够很好地理解我们的表达。

4、对用户进行正确分类

组织中的用户在很多方面存在差异，例如:使用系统的频度和程度、计算机系统知识、所进行的业务过程以及个人的素质和喜好等。根据用户的特点，可对用户进行一定的分类。将用户分类并归纳各自特点，详细描述他们的个性特点及任务状况，将有助于需求的获取和分析。不同的问题需要询问不同的人，对于操作细节的问题，要和实际负责操作的用户进行沟通，而对于关乎全局的问题，则要和相应的管理层用户进行沟通。

5、应实地了解用户工作流程

实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据，并怎样使用这些数据，业务处理过程中需要处理哪些单据，需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。经验证明，与人们面谈关于他们如何完成任务时会有许多限制和不准确性，而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法，用户认为你也应理所当然知道，而不曾提起时。在用户需求已经确认后，将用户需求进行条目化，把每一条需求形成需求开发任务，借助软件项目管理平台，将其直接推送给需求分析人员，而需求分析人员的分析结果可以通过该平台导出成为格式化的需求规格说明。一旦需求规格说明编写任务完成，管理平台直接推送需求评审任务给相关人员。后续的设计、编码、测试等任务都以类似的方式融入流程。

6、分析需求可行性

没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选，这样的事也不干。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。在曾经负责的一个项目中，用户要求新的管理系统应实现和管理系统的数据接口，以方便这些系统中的数据导人新的管理系统。许诺提供系统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与它们的接口也需要时间，而且等这些商业系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。对于复杂的项目，还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。需求变更对大型IT开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以，实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

7、确定需求的优先级别

当客户的期望很高、开发时间很短且资源有限时，设定需求的相对优先级将有助于项目管理人员解决冲突、安排阶段性交付并做出必要的取舍。建立每个需求的重要性有助于规划软件的构造，以最少的费用提供产品的最大功能。特别是对渐进式的项目，优先级的设定就显得更为重要，因为在这些开发中，项目时间安排极为紧迫并且交付日期不可改变，一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消。当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时，需求分析者可指出每一需求所需的费用、难度、技术风险或其他特定的与权衡需求有关的指标，来客观评价每一需求的优先级。

8、正确理解需求分析文档确认

需求分析是一项繁琐枯燥的工作，需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项工作，特别当他被很多其他的事情缠身的时候。在需求分析文档上签字确认，通常被认为是用户同意需求分析内容的标志行为。而实际操作中，签字确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名，于是我就签了，否则开发人员不开始编码。”用户的这种态度将可能给项目带来潜在的风险，如不断地进行需求变更等。对于需要用户确认的需求分析文档，最好在用户确认前，就文档内容对用户进行一定的讲解，以确保用户完全理解并认可文档中的内容。若用户对文档中的内容存在修改意见，则修改后再与用户进行确认，直至用户完全认可文档中的内容为止。通常为对项目有一个整体、准确的理解，需求分析所包含的内容通常大于项目范围所包含的内容。

因此，应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的签字确认是建立一个需求的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。需求确认将给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的用户与需求分析人员的关系，为项目的成功奠定坚实的基础。将知识从一个地方传送到另一个地方并不是一件简单的事情，而且原始的需求通常是以不完整的形式呈现的。它也许只是在某个现有系统的用户脑中，甚至有时用户都没有意识到他们知道什么。同时需求分析工作者也应在日常工作中加强学习，不断总结，使自己的需求分析能力得到不断的提升。软件需求管理之所以重要，主要是因为绝大多数项目的失败主要由需求的理解不到位、需求的变更没有得到有效控制等原因造成的。因此，这就要求我们在软件项目的需求管理方面，要下更大的力气去做好需求的获取、分析、变更控制，结合项目管理的相关理论，如PMBOOK、CMMI等，在项目实践中，不断总结经验教训，做好需求管理。