项目需求分析，项目需求分析

项目需求分析篇1

　　【关键词】软件项目 开发过程 需求分析 原型法 需求变更

　　随着经济全球化的发展，我国经济市场内各行业都面临着冲击与挑战，软件开发行业是近年来发展势头较为强劲的经济产业，在市场经济的考验下国内软件开发行业的发展也在逐步实现一系列改革，其发展趋势也更为复杂。然而随着各类软件在市场中的饱和度不断提高，个人或企业用户对软件质量的标准也在不断提高。在软件工程项目中开展必要的软件需求分析能够第一时间掌握软件使用用户的实际应用需求，降低软件开发过程中的开展成本损耗，提高软件应用在市场中的适应性与受欢迎程度。因此，优化软件需求分析工作，是提升软件开发质量，开展优质开发工作的首要步骤！

　　1 需求分析在软件应用开发工作中的存在意义与目的

　　1.1 需求分析在软件应用开发工作中的存在意义

　　完整的软件开发工作是由于五大部分组成，其中包括软件前期需求分析部分，软件初步设计规划部分、开发编码部分、软件试运行部分以及软件后期维护部分。其中，软件前期分析部分的工作是进行后期四个软件开发部分工作的基础和前提，关系到开发的软件程序能否受到软件试用装的欢迎，软件消费者是否愿意买单以及软件是否能在实际运行过程中为客户处理具体需求，能够对整个软件开发工作的过程以及结果起到决定性作用。

　　1.2 需求分析在软件应用开发工作中的存在目的

　　首先，软件需求分析向软件工作者提供了具体的软件开发规划，能够清晰开发者需要开展得各项开发内容，并给出目的性明确、应用范围精准的软件开发、设计需求。软件需求分析的目的在于通过科学、合理的手段具体说明软件的实际应用，以处理和解决实际问题作为需求分析的最终目的。

　　2 需求分析在软件应用开发工作中的运作机制

　　需求分析的运作机制可以分为问题识别部分、需求分析与综合部分，说明需求分析部分以及软件评估和审核部分。

　　2.1 问题识别部分

　　软件开发部门的系统分析工作者根据软件可行性研究结果以及软件开发规划，表明目标系统对于本次软件开发工作的具体需求，并提出将需求投入实践的前提和具体需求内容。一般将目标系统的需求分为两个主要部分：即软件功能部分以及软件非功能部分。此外，问题识别部分的工作还承担了完善需求分析的必要通信路径，以保障分析工作的开展。

　　2.2 需求分析与综合部分

　　此部分工作的目的在于导出具体的系统逻辑模型，能够与目标系统兼容，需要通过多次反复的需求分析与需求综合步骤来完成。

　　2.3 说明需求分析

　　主要指将经上一步工作结果通过详细的编制与规范进行说明，为软件客户以及试使用者提供必要的数据说明和使用说明。

　　2.4 软件评估和审核。

　　是软件需求分析的结束部分，也是最重要的部分。通过对软件应用的准确性、适用性等功能进行评估与审核，提供有改善性意义的反馈与评价。

　　3 需求分析在软件应用开发工作中的主要采用的分析模式

　　软件开发设计过程中使用到的需求分析办法多种多样，其中包括最开始的传统分析模式，后期发展的原型分析模式以及针对性较强的模型驱动分析模式等，采取适宜的需求分析模式需要软件开发者根据具体的软件开况进行判定。以下主要针对原型分析模式进行详细介绍：

　　3.1 原型分析模式的意义

　　原型分析模式在初期主要适用于传统制造行业以及机械行业的开发与设计过程中，开发者首先制作出产品模式，在此原始模型的基础上不断地加入具体需求进行整改，最终生产出能够满足用户需求的产品。在软件行业中，原型主要是软件系统的初始框架，包含最基本的软件目标功能，是软件最先试运行的模式。

　　3.2 原型分析模式的类别

　　根据软件模型的不同适用目的，构建软件原型的办法也不一样，主要有三种常用的分析类别：

　　（1）需求探索：通过制作软件模型，分析

　　标客户的具体应用需求，并根据用户反馈定位软件特性，探究其他开发方案的可能性。

　　（2）实验测试：主要应用于较大型的软件开发项目中，在开展软件开发设计之前首先对软件开发方案的可行性进行考核，软件的设计规范是否科学。

　　（3）改善进化：该类原型不再停留在实验目的上，主要在于优化软件系统的构造，让软件原型在功能、界面上逐渐具备最终的系统形态。

　　3.3 原型分析模式的优越性

　　（1）强化软件设计方与目标用户的沟通，优化开发者对于目标用户具体软件要求的理解程度，清晰软件功能性以及非功能性需求。

　　（2）原型分析模式能够为开发者带来更直接的软件学习、进步条件。

　　（3）提高需求分析工作效率，在较短时间内精确定位目标系统的实际软件功能需求，并确定软件开发的可行性以及实际应用型。

　　（4）原型分析模式基本能够将最终制作的软件模型作为目标产品，只需要修整、改进部分软件设计功能，直接缩短了开发时间，降低开发成本。

　　4 软件应用开发工作中的需求变更

　　软件的开发与设计需要一定的时间来完成，在开发阶段中，不能避免目标客户的潜在的需求变更，用户需求变更对于软件开发工作的成本投入损耗较大，需要开发者制定有效的应对机制处理此类问题。目前大不部分软件开发企业主要通过以下方式提高需求分析的稳定系数：

　　（1）强化软件开发工作者专业技能。软件开发者只是计算机软件的工程师，其知识面并不能涵盖所有用户要求的软件应用灵虚，因此在进行软件需求分析工作的早期需要强化软件开发者对于目标领域的了解，特别增加关联领域的知识宣讲教育培训。

　　（2）提供畅通的软件开发与功能需求沟通路径。为软件开发者与目标客户之间构造更加容易、便利的交流平台，开发者通过双方交流内容对用户的实际软件需求加以搜集与分析，并向目标客户提出可行性较强开发方案并告知潜在不良威胁。

　　（3）通过有力的法律约束文件提高需求分析稳定性。软件开发企业在承担软件开发任务时一般会与目标客户签订必要的开发合同，其中包括了具体的软件功能要求，能够降低需求变更风险。

　　5 结语

　　软件开发行业是一门新兴产业，发展历史与其他经营产业相比虽然短但依然没有影响其在经济市场中的经济发展优势与地位，可见在软件开发市场中对于优质应用软件的需求依然存在较大缺口，其行业发展趋势十分乐观。但是随着人们物质生活水平的提高，软件用户对于应用软件的要求也不断提高，软件开发企业要在软件市场中占据有利的竞争地位，首要工作在于做好基本的软件需求分析，明确目标客户的实际软件应用需要，提升自身软件的设计开发质量。通过需求分析能够较好的完成这一目标。

　　参考文献

　　[1]周勇，周新颖，姜滨。气象数据通信软件需求分析方法[a]。信息技术在气象领域的开发应用论文集（一）[c]。2005.

　　[2]鲍有文，黄建华，王辉。第21届世界大学生运动会信息系统的软件工程实施[a]。全国计算机网络应用年会论文集（2001）[c]。2001.

　　[3]石振强。浅谈信息系统软件工程的监理[a]；第二十届中国（天津）'2006it、网络、信息技术、电子、仪器仪表创新学术会议论文集[c]。2006.

　　[4]张立春，赵合计，安琳。基于agent的软件工程方法与应用[a]。第全国数据库学术会议论文集（技术报告篇）[c]。2002.

　　[5]曲继刚，万建成。软件工程中的用户界面需求描述[a]。第六届全国计算机应用联合学术会议论文集[c]。2002.

　　作者简介

　　罗亚东（1969-），男，四川省成都市人，四川水利职业技术学院副教授，硕士。主要从事计算机教学与研究。

项目需求分析篇2

　　【关键词】需求分析 系统开发 信息系统

　　1 引言

　　需求分析是系统开发的基础。在信息系统项目的开发过程中，人们越来越体会到需求分析的重要性，含糊的需求描述，频繁的需求变更，加重了用户和系统开发双方的工作任务，需求分析的偏差，将会造成设计，编码工作的大量返工，甚至导致项目失败。

　　当一个信息系统项目的规划获得批准，进入开发阶段后，需求分析作为系统分析的第一项工作，要解决系统“做什么”的问题，明确系统的功能，确保所开发的系统符合用户预期，如果最终系统不能满足用户的需求，则一切的工作都是徒劳。

　　2 信息系统项目的特点

　　信息系统项目是根据用户的需求，选择适合的先进技术，进行设计开发，遵循计算机软硬件开发的技术规范，提出全面的解决方案，为用户最大限度的整合相关信息资源，提高用户的工作效率。

　　信息系统项目通常具有如下特点：

　　目标不明确，用户很难精确的描述最终系统的要求，最初提出一个大的方向后，只能在开发中渐进明细。

　　智力密集型，信息系统项目是典型的多学科合作项目，需要应用多个领域的知识。在针对气象领域开发的系统中，应用地理信息系统可以直观的描述观测站点的状态。

　　设计人员高度专业化，行业特征较明显。比如气象数据的传输对时效的要求较高，逐小时观测数据需5分钟内传完，在整点的时候并发传输数量达到峰值。在处理文件时，气象报文严格参照行业制定的编码规范。

　　3 需求分析的步骤

　　需求分析要实现对系统功能和性能的全面描述。具体的说，需求分析的工作分以下几个步骤来完成。

　　3.1 需求获取

　　需要获得各类用户的业务需求，了解系统需要完成的工作，并预估系统可能达到的目标。

　　3.2 需求分析

　　对用户提出的需求进行优先级分类，分析系统需要实现的功能，要达到的性能目标，提出系统的解决方案。

　　3.3 需求定义

　　编写出需求规格说明书，对确定的需求进行详细描述，形成文档。该文档作为系统开发中分析阶段的重要成果，是后期系统开发和维护的基础，也是系统设计和编码的依据。

　　3.4 需求验证

　　对已描述需求的完整性和正确性进行最后的评审确认。

　　4 需求获取的方法

　　需求获取是需求分析的前提，直接面向系统的用户和相关干系人。需求获取一般采用访谈，用户调查，现场跟班，联合讨论等多种方法。其中访谈是最基本的一种手段，与项目的关键干系人进行特定范围的访谈，对了解系统概况大有帮助。有了初步框架后，再结合其他方法全面收集系统的需求，争取没有遗漏，减少后期变更的成本。

　　在气象信息系统的开发中，我们用得最多的就是联合应用开发这种引导式研讨会的方式。研讨会上干系人和开发人员集中在一起讨论系统的功能，鉴于开发人员也熟悉气象业务的数据处理流程，在会上能够与系统的用户代表在同一个纬度和语境下顺畅的进行沟通。我们将之前收集的需求逐条整理，大家一起有针对性的讨论，将需求渐进明细，以保证开发团队与用户对需求的理解达成一致。

　　5 需求定义的方法

　　需求定义的过程就是将需求文档化，以形成需求规格说明书，一份高质量的需求说明书有助于系统项目的成功。需求定义通常有严格定义和原型化这两种方法。

　　严格定义方法主要应用于传统的结构化开发中。结构化开发适用于需求明确，功能相对简单的系统项目，它要求所有的需求都能够被事先定义，通过业务流程图等方式表现出系统的逻辑结构，但前期不能在用户的终端显示出系统的实际效果，用户看到成果的周期较长，等系统已出雏型再修改功能需求的话，修改的工作量将会翻番。而保证需求不发生变更几乎是不可能的，因为随着用户对系统的认识逐步加深后，会产生一些新的想法。对于初期需求不明确的项目更适合采用原型化方法来定义需求，可以弥补结构化方法中抽象的理论描述，首先快速生成一个简单的系统模型，满足用户的基本要求，然后和用户一起讨论修改，逐步增加功能，最终实现系统的全部需求。

　　我们在气象资料传输监控平台项目的需求定义时，将结构化和原型化方法相结合，大大提高了工作效率。每个模块的功能我们用结构化方法严格定义，该方法的严密性和精确度有效保证了需求在实现过程中没有遗漏。在网页显示方面的需求定义则采用原型化方法，先取一种资料，生成一个页面，和用户讨论，是否满足需求，要修改的地方记录下来进行更新，然后再次与用户讨论，如此反复，直到无疑义，便形成了网页的模版，之后其他资料的显示页面都参照模版即可。

　　6 小结

　　总之，做好信息系统项目开发中的需求分析，需要开发团队和项目干系人的有效合作，需求分析看似简单，但要真正做到位，并不是一件容易的事，像信息系统本身采用的技术更新快，需求复杂，就要采用多种方法相结合来做好需求分析的工作。仔细掌握和管理好系统需求对促进项目的成功具有重要作用。

项目需求分析篇3

　　关键词：网站 项目管理 需求分析

　　1 网站项目管理的特点

　　网站项目是以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。网站项目管理就是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其特点表现在以下几个方面：

　　1）涉及的领域很多。狭义地讲，网站项目包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题。这对参与项目管理的人员提出了很高的要求。

　　2）参与项目的角色很多，水平可能参差不齐。对于网站项目管理，最关键的角色是项目经理、业务流程分析师、用户界面工程师、系统分析员、编码人员（程序员）和质量控制工程师等。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。其中需求分析过程中主要角色有客户代表、业务员、业务流程分析师、用户界面工程师，另外还有项目经理、数据库工程师、文档工程师等参与。

　　3）网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，项目管理人员必须了解各种技术的利弊，帮助用户选择高效、廉价并富有前瞻性的方案。

　　2 需求分析在网站项目管理中的作用及要求

　　需求分析是一个项目的开端，也是项目建设的基石。由于以上提出的网站项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，网站项目需求分析的重要性是不言而喻的，在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。

　　在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。需求分析所形成的文档最终达到如下要求。

　　1）正确性：每个功能必须清楚描写交付的功能。

　　2）可行性：确保在当前的开发能力和系统环境下可以实现每个需求。

　　3）必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时被“砍”掉。

　　4）简明性：不要使用专业的网络术语。

　　5）检测性：如果开发完毕，客户可以根据需求检测。

　　3 网站项目需求分析的一般方法

　　根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

　　第一阶段：“访谈式”。这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况和客观信息，建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。

　　实现手段：访谈、调查表格。

　　输出成果：调查报告、业务流程报告。

　　第二阶段：“诱导式”。这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际和客观信息的基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性，界面的便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和改进方法。

　　实现手段：拜访（诱导）、原型演示。

　　输出成果：调研分析报告、原型反馈报告、业务流程报告。

　　第三阶段：“确认式”。这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查报告来提出反馈意见，并对已经可接受的报告、文档签字确认。

　　实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统。

　　输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）。

　　整体来讲，需求分析的三个阶段是需求调研中不可忽视的一个重要部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。

　　4 网站项目需求分析的注意事项和技巧

　　项目的整体风险往往表现在需求分析不明确、业务流程不合理，导致用户不习惯或不愿意去用承建方的软件。承建方和客户方都要重视需求分析的重要性。为更好地把握用户的需求和方向，应该采用必要的手段和方法来进行需求调研。

　　4.1 挖掘用户需求

项目需求分析篇4

　　[关键词] 软件开发；需求分析；用户沟通

　　[中图分类号] TP311.5 [文献标识码] A [文章编号] 1673 - 0194（2013）17- 0057- 03

　　1 前言

　　成功的软件产品是建立在成功的需求分析基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题需要用计算机系统来解决，而开发人员开始帮助用户解决这个问题时，沟通就开始了。

　　需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。有些开发人员对需求的获取往往有错误的认识，认为：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，要做什么或不做什么或都凭用户自己确定就行了。但是实际上需求获取并不如想象的这样简单，一个软件项目的需求要经过开发人员与用户的有效沟通与认真分析才能确定下来。

　　这其中还有对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只关注自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎样工作效率更好，不关心系统中信息资源的规范与共享问题，也不太清楚哪些工作可以交给软件完成，他们大多不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导。但是用户与开发人员之间的交流很容易出现障碍，容易忽略了那些被认为是“很明确”的信息。

　　本文结合笔者在实际软件项目开发工作中的经验，就需求分析时与用户沟通中应注意的几个问题进行研究分析。

　　1 沟通前的准备工作是开发人员必须做的功课

　　开发人员与用户沟通前的准备工作一般有常规准备和可能需要的业务领域知识准备两个方面。

　　常规的准备工作包括对项目整体环境的熟悉，着重需要了解项目的背景、项目的目的、项目的利益相关方等信息，以便对当前项目的总体情况有一定了解。同时还要围绕这些方面对将要展开的调研进行需求调研问题的准备、需求调研模板的设计、需求调研时间安排等。

　　承担需求调研的开发人员除了做好上述基本的准备工作外，还需要结合自身对用户业务领域知识的掌握情况，主动积极了解客户业务和相关知识。这是因为，虽然开发人员可能在信息技术方面非常专业，但对于具体的用户业务可能并不十分清楚。这个项目对用户将有什么帮助、某一系统功能是否有用、某一流程处理是否合理，在不了解用户业务的情况下，我们将很难做出判断。这一掌握业务领域知识的工作也可能是要贯穿项目发展过程始终的。

　　因为只有在了解业务的基础上，我们才能和用户有共同的沟通语言和业务理解，才能真正理解系统应具有哪些功能。笔者曾在对某钢铁企业ERP项目的生产管理系统进行调研的过程中由于缺乏冶金生产方面的知识，有许多问题不能很好理解。

　　当时，笔者向用户虚心请教，并在调研结束后及时对有关生产知识进行了补充。后来在进行该项目的设备管理系统调研前，笔者结合前段时间了解的冶金生产工艺知识，又事先浏览式地学习了一下有关冶金设备知识，再进行调研时与用户的沟通就顺畅了许多。

　　应用领域的知识是无边无际的，在各种项目的调研过程中，肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作准确、顺利进行的问题。遇到此类问题时，需求分析者应虚心向用户请教，同时应及时补充应用领域的知识。在调研前做好充分的准备是十分必要的。

　　2 把握好需求的层次是与用户有效沟通的保证

　　对于一个软件系统项目来讲，开发人员需要面对不同层次，不同部门的客户，要广泛听取意见。不同组织机构层次，不同业务部门，甚至不同计算机使用水平的客户对系统的要求都会有不同。比如，总经理级别的客户可能只是对宏观报表感兴趣，业务细节操作他们一般不会发表什么意见。部门经理则关注日常工作报表，系统功能的实现以及可能的扩展策略。普通业务操作人员则关心操作方式、界面风格、易用性等。因此，把客户分成不同的群组就变得非常有价值，这样将会使需求分析的工作变得简单。因为开发人员可以从不同群组的维度来分析需求，对于特定的需求问题，则需要关注特定的客户群来合作沟通。

　　在软件工程中将软件需求分为业务需求、用户需求、功能需求与非功能需求3个层次。从与用户沟通的角度来看，也可以分别通过3个不同层次的需求将用户划分为三大类群体。

　　业务需求反映了用户对软件产品高层次的目标要求。在项目中，一开始用户高层领导通常会讲，我们上这个系统的目标是什么，我们为什么要上这个系统，我们要达到什么样的一个高度。通过这个层次的调研与分析来确定所开发项目的目标和范围。

　　经过上面的业务需求分析确定了项目的目标和范围后，紧接着就是同用户中层领导讨论，他们主要会讲我们的业务是什么，我们怎么工作，我们的工作流程是什么。这就是用户需求。通过对项目的用户需求分析，得出了项目的基本业务流程。

　　得到了这些信息后，开发人员开始整理，把软件功能点找出来，确定软件如何完成用户的工作，这是软件功能需求。按照功能需求做出来的软件是否能够被用户认可，这时不仅要面对用户的中层领导人员，还要面对基础管理人员和现场操作人员。

　　在功能需求满足用户要求的基础上，用户自然会提出一些方便性、安全性之类的要求，也就是非功能需求。所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。例如系统的性能、可靠性、可维护性、可扩充性，以及对技术和业务的适应性等。非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。

　　4 注意在沟通中掌握不同用户群体的代表性人物

　　用户组织中的人员在很多方面存在差异，例如：使用系统的频度和程度、计算机系统知识、所进行的业务过程以及个人的素质和喜好等。结合不同需求层次的用户的特点，可对用户进行一定的分类。将用户分类并归纳各自特点，详细描述他们的个性特点及任务状况，将有助于需求的获取和分析。

　　不同的问题需要询问不同的人，对于操作细节的问题，要和实际负责操作的用户进行沟通，而对于关乎全局的问题，则要和相应的管理层用户进行沟通。如通过组织架构图得知储运系统的仓储管理活动涉及3种角色：仓库主管、计划员、理货员。

　　我们发现仓库主管是对全盘业务相当熟悉的人，他负责协调本部门的全局事务；计划员则是负责接收和处理采购计划和到货信息，理货员按出入库通知单承担收发货的具体操作，这些人都将通过建成后的系统操作完成自己的业务。若我们调研的目的是搞清该部门的整体性流程，我们会很自然地选择仓库主管作为访谈的对象。

　　不可能对所有的用户都进行需求获取，这样做时间不允许，效果也不一定好，所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。每类用户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策，用户代表往往是本类用户中的3类人：对项目有决定权的领导、熟悉业务流程的专家、系统的实际使用者。

　　每一个用户代表代表了一个特定的用户类，并在那个用户类和开发者之间起沟通连接作用，用户代表从他们所代表的用户类中收集需求信息，同时每个用户代表负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。

　　5 注意积极引导与合理利用用户的需求

　　由于用户往往对规划中的项目没有直观的认识，对于计算机系统的应用特点也缺乏了解，所提出的需求大多是以眼前的工作环境为基础，只关心自己局部的业务与数据要求，不能从全局的视角理解新系统投运后的组织机构与业务流程，对于一些有前瞻性的设计思想会不以为然。

　　例如在做ERP项目的能源管理系统时，由于数据是以自动采集为主的，我们规划了每分钟的能源仪表运行数据和按小时、班和日的结算数据功能，负责能源管理的用户人员却说他们只是月底有套月报表就可以了，没有精力按日管理，更不会按小时来管理。我们根据自己在这个领域的开发经验，耐心地向用户介绍了这样设计对于用户能源管理的必要性，同时说明这样一定能够满足按月报表的需求，方案获得了用户高层领导的认可与赞许。结果在项目投运的一年后，该企业就围绕节能降耗和降成本工作，利用能源计量系统的小时量和班量数据在基层车间开展了现场能源管理与指标考核活动，利用日量数据上形成的周报、旬报，开展了全面的旬成本分析和重点工序的周成本分析。

　　这个案例说明开发人员在具备充分的业务领域能力后，在与用户的需求沟通中主动发挥引领作用，可以实现项目开发中的甲乙方双赢效果。

　　还有些时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。如在笔者曾经负责的一个项目中，用户要求新的管理系统应实现和社保、医保等管理系统的数据接口，以方便这些系统中的数据导入新的管理系统。

　　许诺提供与社保、医保等系统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与它们的接口也需要时间，而且与社保、医保这样的系统谈接口条件，也不是我们单方面能够决定的。因此与外部系统接口的可行性结论为：不可行。