项目需求识别

　　项目需求识别是项目生命周期的最初阶段。它开始于对需求、问题或机会的识别，结束于项目需求建议书(RequestforProposal，RFP)的发布。如图1所示：

　　图 项目需求识别过程

　　项目需求是整个项目的基础。因此，正确识别并认识项目需求是项目成功的必要条件之一。

　　项目需求如果要得到批准通常必须具有以下一个或多个原因：

　　1.市场需求(例如，某汽车公司针对市场上汽油短缺的情况，批准一个项目，研制更省油的汽车)；

　　2.商业需要(例如，一个培训公司批准开发一个新的课程来增加收人)；

　　3.顾客要求(例如，某电力公司批准一个项目，建立新的变电站向一个新的工业开发区提供电力资源)；

　　4.技术领先需求(例如，一家电子公司在计算机内存不断增加的情况下，批准开发一个新的视频游戏机)；

　　5.法律要求(例如，一家涂料生产商授权一个项目来建立该公司处理有毒物质的指导方针)；

　　6.社会需求(例如，一个发展中国家的某民间组织批准一个项目，向霍乱高发的低收入社区提供饮用水系统、公共厕所和卫生教育)。

　　除了利益相关方明确提出的需求外，还经常会有很多模糊的甚至是隐含的需求。如果不能识别出所有的需求并对这些需求进行甄别、管理，可能会对整个项目的后期工作产生严重的影响。

　　●按照是否能够确定是本项目需求来划分

　　1.待定需求

　　待定需求一般是利益相关方不能确定，或者是虽然能够明确描述但是无法确定是否包含在项目范围中的需求。有时待定需求会随着时间的推移而成为确定需求，但是在还没有确定阶段，待定需求一般不包含在最终的需求建议书中，如果必须包含在需求建议书中，需要作如下处理：

　　(1)对产生“待定”一词的条件进行描述，使得问题能被解决；

　　(2)描述必须干什么事，以删除这个“待定”。

　　包含有“待定”一词的任何需求建议书的项目文件应该注意以下两点：

　　(1)标识与此特定文件有关的版本号或叙述其专门的发布号；

　　(2)拒绝对任何仍标识有“待定”一词的需求建议书章节的许诺。

　　2.确定需求

　　通过与利益相关方的接触，交流、查看利益相关方提供的文档等沟通方式，确定利益相关方关于项目的明确的且应该包含在项目范围内的需求。这些需求需要采用各种方法、明确地用文档的方式描述出来，在经过用户确认后即成为制定项目范围、项目目标以及项目计划的基础。确定的需求一般是主要利益相关方提出、必须在项目中实现的需求，识别及确定需求的方法有多种，可以根据不同的问题采用不同的方法，最终得到清晰明确的需求描述。

　　●按照需求是否具有可执行和可描述特点来划分

　　1.明确需求

　　明确需求是能够清晰描述并能够为项目利益相关方所共同理解的需求。明确需求只是可以明确地描述和提出的需求，不一定就是所有项目利益相关方达成共识要在项目中实现的确定需求。明确需求可能包括确定需求，也可能包括待定需求，

　　2.模糊需求(用户的软性需求)

　　有些时候，利益相关方无法将需求明确描述出来，需要需求调研人员在充分了解利益相关方的环境、相关工作、相关爱好等方面的基础上，理解利益相关方可能的需求，再将需求明确地描述出来。模糊需求是一种含而不露的需求，是一种我们知道确有其事却因其变化不定而无法定义或定位的需求；模糊需求极难定义，也很难研究。在需求识别过程中，识别出利益相关方的模糊需求，并明确表述是一件非常困难的事情，也是优秀的专业人员和平庸的从业者的一个重要区别。

　　例如，如果业主需要设计一座安全且能住人的住宅，许多建筑师可以胜任这份工作。对于住宅建设，建筑规范有明确的规定，安全等级标准也有清楚的界定。但如果业主增加一项要求，如“非常舒适”，也许只有少数建筑师才能胜任此工作。因为“非常舒适”是软性标准，人跟人不同，无法统一界定。

　　3.隐含需求

　　有些时候，分析由确定需求衍生出的隐含需求，并识别利益相关方没有明确提出来的隐含需求(有可能是实现利益相关方需求的前提条件)这一点往往容易被忽略掉，因而经常会因为对隐含需求考虑得不够充分而引起需求变更。隐含需求的存在经常是因为问题提出者认为这些都是调研者理所当然应该知道的，不需要特别说明。这种情况在调研用户业务情况的时候经常发生，一般用户在阐述业务情况的时候会认为调研者对业务比较了解，不需要交流一些工作惯例或规定，这就经常导致调研者对需求的理解趋于片面化，无法掌握利益相关方的隐含需求，也就无法成功地完成需求识别的任务。

　　●按项目需求的时效性区分

　　1.现在需求

　　现在需求是在项目进行时就已经具备实现条件的需求。这些需求可能是确定的，也可能是待定的，但最终项目需要实现的确定需求一定是现在需求。

　　2.未来需求

　　与待定需求不同，未来需求是利益相关方能够明确描述，但是由于在项目需求识别时还不需要，或者是在需求识别时还不具备满足利益相关方期望的条件等原因，而不必包含在项目需求范围中的利益相关方需求。未来需求虽然不用马上实现，但是在项目识别时需要对此类需求进行记录和管理，以此作为项目在制定解决方案时的参照。优秀的项目解决方案一般都会考虑到项目成果未来的发展，为项目成果未来的发展提供开放的、可兼容和可扩展的接口，以便当未来需求变为当前需求时，当前项目成果还可以继续利用。

　　总之，在需求识别的过程中，不仅仅要描述确定需求，还要识别出利益相关方的模糊需求和隐含需求，将模糊需求和隐含需求明确化，使之成为确定需求。识别待定需求和未来需求对项目的发展也是极其重要的。对识别出来的需求分类，并进行有效管理，是对成功的项目需求识别的基本要求。

　　项目利益相关方是积极参与项目或者其利益在项目执行过程中或完成后受到积极或消极影响的个人或组织，一般包括项目经理、项目团队成员、顾客、执行组织、项目发起人等，除了这些，还有很多不同名称和种类的项目利益相关方：内部的和外部的利益相关方、业主和资金提供者、供应商和承包商、项目团队成员及其家庭成员、政府代理和媒体、市民个人、临时性的或永久性的游说组织以及整个社会。

　　下面我们先以房地产开发项目为例，来看看如何识别并确认项目利益相关方的需求。

　　对于不同的项目利益相关方，需要识别的需求类型也不同；对于房地产开发项目的项目利益相关方来说，不同的利益相关方的需求不同。

　　承包商的需求可能包括：

　　合理的价格；

　　按合同及时验收付款；

　　有效的沟通；

　　受到尊重；

　　范围及验收标准明确。

　　业主的需求可能包括：

　　房屋结构设计合理，实用性好(可能包括房屋朝向、层高、使用面积等)；

　　生活配套设施完备(例如小区内或小区附近需要有车库、商场、学校等)；

　　小区环境建设(例如需要绿化面积达到40％等)；

　　工程质量符合相关部门要求；

　　工程按时交付；

　　工程造价尽可能降低。

　　对于房地产项目来说，主要有下述方面的需求识别：

　　项目发起人的项目需求识别；

　　项目经理实施项目的组织的需求识别；

　　合作的承包商的项目需求识别；

　　业主的项目需求识别；

　　项目所在地政府的项目需求识别；

　　其他诸如项目所在地层民、商业企业等的项目需求识别。

　　以上几个方面的需求识别完成后，经过相关的确认步骤，将形成项目目标。

　　虽然我们拿房地产项目来试图解释项目需求识别，但事实上对于大多数项目来说，项目需求识别的第一个步骤是识别项目利益相关方。确定哪些个人或组织是项目的主要利益相关方是比较困难的过程；同时利益相关方的角色和职责可能会有交叉，因此识别项目需求的过程就更加复杂。

　　项目需求识别的过程主要是确定主要项目利益相关方的要求和期望。一般来说，项目需求识别对象应该是所有项目利益相关方，但是因为不同项目利益相关方在项目中的作用不同，所以一般会主要识别主要项目利益相关方(如客户)的要求和期望。

　　我们下面以IT项目为例，详细描述项目需求的识别方法。

　　●组成表法

　　组成表是最基本和常用的需求识别方法，也常用来描述项目的某一方面的属性，一般是根据分类对目标进行罗列。

　　例如新产品开发者需要设法把某一类产品能够满足的需求全部列出来，但在罗列这些需求时他们常常会发现许多以前所未知的需求。组成表是一张包含了产品满足需求的所有方式的表格，它能使我们看到现有产品的各种变动是如何更有效地满足这些需求的。组成表中所获得的用户需求往往是千差万别的，为此，进行新产品构思时需要对这些需求进行相应的核查与分析。这一工作可以采用“需求分析核查表”的形式进行（见表1）。

　　如果有两个以上低X分值和两个以上低Y分值，那么面临的需求很可能是待定需求；

　　如果有两个以上高X分值和两个以上高Y分值，那么面临的需求很可能是模糊需求；

　　如果有两个以上低X分值和两个以上高Y分值，那么面临的需求很可能是确定需求；

　　如果有两个以上高X分值和两个以上低Y分值，那么面临的需求很可能是未来需求。

　　●问题分析法PAM(Problem Analysis Method)

　　PAM是通过分析研究用户和专家提出的意见而进行构思的方法，它一方面要收集用户意见；另一方面要将收集到的意见中的问题抽出来，进行分类统计，以确定问题的严重程度、出场频繁程度，针对问题进行分析，寻找适当的解决方法。问题包含不满意，也就是隐含着改进，孕育着新构思，可以激发创新思维。

　　例如，在计算机软件开发方法中的PAM的基本思想是：考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综合。这一方法的具体步骤是：从输入、输出数据结构导出基本处理框，分析这些处理框之间的先后关系，按先后关系逐步综合处理框，直到画出整个系统的PAD图。从上述步骤中可以看出，这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。这一方法在日本较为流行，软件开发的成功率也很高。

　　●差异分析法

　　差异分析法是通过分析现有产品与项目需求目标在哪些地方存在相同和差异来更好地获知需求的方法。使用差异分析法的前提条件一般是已经有现有产品或参照系统，并且利益相关方对现有产品或参照系统具有足够的了解，可以将现有产品或参照系统的属性作为比较条件。通过差异分析，项目利益相关方将对需求有更好的理解，同时可以对项目结果有更清晰的认识，从而可以查找出需求中的不足，提出更符合项目要求的新的需求。

　　●原型法(Prototyping)

　　原型法的使用过程是建立模型的过程，该模型能够示范目标产品、服务或系统的特征。使用原型法可以帮助确定需求，证明系统在技术上是可行的，推广目标系统的思想。使用原型法的步骤一般是：

　　确定基本需求；

　　根据基本需求设计、开发模型；

　　项目利益相关方使用、评价模型；

　　使用原型作为最终系统的技术蓝图，不断修改、完善模型。

　　原型法的主要优点在于：它是一种支持用户的方法，使得用户在系统生存周期的设计阶段起到积极的作用；它能减少系统开发的风险，特别是在大型项目的开发中，由于对项目需求的分析难以一次完成，应用原型法效果更为明显。原型法的概念既适用于系统的重新开发，也适用于对系统的修改；原型法不仅可以用于对开发项目中的计算机方面进行设计，也可用于制作系统的工作模型。近年来，原型法的思想被应用于很多产品的开发活动中。

　　●其他方法

　　在特定的项目领域还可以采用其他特定的方法，例如在信息系统开发项目中采用面向对象方法、系统用例法、生命周期法等。

　　需求识别分析过程根据采用的需求识别分析方法不同而不同，我们还是以IT项目为例，描述需求的分析过程：

　　●使用绘制关联图等方法描述项目需求

　　在需求识别的过程中，对于初步整理的需求需要不断采用各种方法进行归纳、整理，关联图就是整理项目需求的一个方法。所谓关联图，是把若于个存在的问题及其因素间的因果关系用箭头连接起来的一种图示工具，是一种关联分析说明图。通过关联图可以找出因素之间的因果关系，便于统观全局，分析并拟定解决问题的措施和计划。

　　项目人员针对不同方面的需求可以采用不同的方法进行描述，以清晰、明确地描述所有需求。需求描述可以采用文档、原型等多种方式。

　　●分析需求的可行性

　　在允许的成本、性能、进度要求下，分析每项需求实现的可行性，明确与每项需求实现相联系的风险，与其他需求的冲突，对项目环境、项目团队的要求以及技术要求等。

　　●确定需求优先级

　　以利益相关方要求、每项需求对项目整体影响等为基础，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求，并制定出对不同优先级别的需求的实现方案。当允许需求变更时，应在特定的版本中加人每一项变更，并在那个版本计划中作出需要的变更。

　　●建立需求模型

　　如果需要，应为需求建立模型。建立需求的图形分析模型通常是对需求规格说明极好的补充。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。在软件项目中，这样的模型包括数据流图、实体关系图、状态变换图、对象类及交互作用图等。

　　●编写数据字典

　　数据字典是软件项目中常用的名词，也是软件项目中必须完成的一个文档。在其他类型的项目中，编写完善的数据字典也是项目需求的一个良好补充。数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求识别阶段，数据字典至少应定义客户数据项以确保客户与开发小组使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

　　●应用质量功能调配

　　质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意的需求；普通需求；兴奋需求，即实现了会给客户带来惊喜，但若没有实现也不会受到责备的需求。

　　●需求变更

　　在需求识别过程中，甚至是在需求识别阶段结束后，经常会遇到利益相关方要求对需求进行变更的情况。从这一角度来看，可以说需求识别贯穿了项目建设过程的始终。在项目结束前的任何阶段中，都有可能进行需求变更。但是，对需求的变更不能是随意的，应该进行严格的管理。(1)要求对变更的代价进行真实可靠的评估。有时，当人们面临更好也更昂贵的方案时，会作出不同的选择，而这时对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，项目利益相关方有权利要求项目人员通过分析给出一个真实可信的评估，包括影响、成本和得失等评估。项目人员不能由于不想实施变更而随意夸大评估成本。(2)对需求变更进行有效控制：将变更的需求描述文档作为需求文档的升级或补充文档进行管理，同时对需求形成后的项目开发按照项目规定程序进行管理，例如制定各种实施计划，安排资源，进行有效开发，并对实施结果进行评估等，

　　●需求确认

　　需求确认前，项目利益相关方要对需求进行评审。需求文档的评审是一项精益求精的技术，可以发现二义性或不确定的需求，那些定义不清的需求不能作为后期项目开展的依据。一般需求评审需要项目利益相关方组成评审小组，通过评审会议，甚至通过对需求的测试而最终被项目利益相关方认可。这种需求评审经常不会一次通过，可能需要经过项目人员对未通过的需求文档进行修改完善、再提交给评审小组、再次召开评审会议等几次反复过程才能最终完成。评审的结果一般是在“需求分析报告”上签字确认，这通常被认为是利益相关方同意需求分析的标志行为。然而实际操作中，项目利益相关方往往认为不可能在项目的早期就了解所有的需求，而且毫无疑问需求将会出现变更。但是在“需求分析报告”上签字确认是终止早期需求分析过程的正确方法。需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定坚实的基础。

　　需求识别过程的结果是一份正式的需求建议书。正式的需求建议书一般包括以下内容：

　　工作表述，主要是客户当前工作描述，涉及确定工作范围；

　　客户要求的详细描述，必要的时候可以采用流程图等方式详细说明；

　　客户期望的结果或产品描述；

　　客户对结果或产品其他方面的描述，例如安全性等；

　　客户对需求的确认；

　　客户要求的合同类型以及合同内容等；

　　客户要求的付款方式；令客户要求的进度计划以及项目实施方式；

　　客户要求的建议书的具体格式；

　　客户要求的提交建议书的最后日期；

　　客户要求的评价建议书的标准。

　　上述内容，根据具体项目的要求以及特点确定，并不是每个项目建议书都必须包括以上内容。一般来说，上述前五项是必须的，其他可以根据客户的要求和项目特点确定是否包含在需求建议书中。

　　许多组织一开始都采用标准描述的需求规格说明书模板，但是模板不是万能的，有时要根据项目特点对模板进行适当的改动。案例模板一一列出了软件需求说明书需要包含的内容。

　　不管项目来自于何种渠道，都需要作好用户需求的识别，否则，项目风险会大大增加。

　　从客户所在的角度而言，识别需求是项目启动过程和整个项目生命期的最初活动，客户通过识别商业或市场需求、机会，确定投资方向和项目机会。在这个过程中，将为项目的目标确定、可行性分析和项目立项提供直接、有效的依据。例如，一个企业发现其资源利用率很低、财务浪费严重、管理比较混乱，准备启动ERP系统。但是，在这之前，必须要调查清楚当前企业资源利用的实际情况，以及对企业管理和成本造成的影响程度，尽量确定问题的数量和等级，看是否真的需要建立ERP系统。一旦已经确定了相关问题和需求，并证实了上ERP系统将会获得很大的收益后，才可以开始准备需求建议书。

　　从开发方的角度而言，识别需求是得到客户需求建议书后，项目团队从技术实现、项目实施的角度识别客户的实际存在的问题、基本意图和真实想法，从而与客户有效地沟通，准确分析需求和问题，为制定可行、合理、正确的技术及实施解决方案提供依据。

　　如果是软件企业自行选择开发的面向特定市场的项目，更需要认真分析其实际需求。

• 项目需求