第一章产品的市场需求分析与设计

第一章产品的市场需求分析与设计

１．１市场及用户

了解市场是开发产品的基本前提，下面，我们从市场的定义和构成出发，给出需求和需求产品的定义，最后说明了上述三者之间的关系。１．市场的定义市场是商品经济的产物，市场概念随着商品经济和社会的发展而变化。在商品交换不发达的时代，市场仅仅是指交换的具体场所。在当前的商品经济环境和电子商务中，市场的性质发生了深刻的变化，买方市场已经形成，市场的主体是消费者，并且，原有的商业作业模式的市场机制，也部分地被基于网络的营销模式所取代．传统经济中的营销单向传递（由卖方向买方）产品信息的模式逐步演变成一种双向的交互式的需求信息传递模式，即在信息源积极地向用户展现自己产品信息的同时，用户也在积极地向信息源提出自己的需求信息。根据市场的变化和当前网络化市场的特点，应该从顾客的角度来定义市场。下面给出市场的定义。

【定义1】市场一个市场是由那些具有特定的需要或欲望，而且愿意并能够通过交换来满足这种需要或欲望的全部潜在顾客所构成。根据菲力普·科特勒对市场的分类，可以给出下面的定义。

【定义2】潜在市场潜在市场就是指那些表明对某个在市场上出售的商品有某种程度兴趣的顾客群体。

【定义3】有效市场有效市场是由一群体对某一产品有兴趣、有收入，并且有一定的购物渠道的潜在市场顾客所组成。

【定义4】目标市场目标市场（又称为服务市场）是公司决定要在有效市场上追求的那部分，其目标是满足用户的需求。

定义目标市场的原因是企业不可能在每个市场经营和满足各种需求，甚至也不可能在一个大的市场内做好工作。企业的目标市场是由消费者市场（ConsumerMarkets）和生产者市场（IndustrialMarkets）组成。消费者市场是由那些购买商品及服务以满足自己的需要和欲望的个人、集团和组织构成，它是目标市场的核心。而生产者市场是由一切购买商品和服务，将它们用于生产其他商品或服务，以供销售、出租或供应给他人的组织所组成。2.市场的构成因素根据市场的定义，对一切既定的商品来说，市场是由消费主体、购买力和购买欲望三个主要因素构成的，其关系可用以下公式来表达：

M=C×P×D其中：C是指市场的消费主体，它是购买商品和服务的消费者和各类社会组织的总和。随着买方市场的形成，特别是知识经济时代、网络时代的到来，消费主体的地位发生了很大的变化，同时消费主体的个体——顾客本身也较之从前有了质的变化。代表当今消费主体趋势的消费者的显性特征为：个性化需求越来越明显，致使商家必须满足其独特的需求；头脑冷静，擅长理性分析，因此，对信息的组织和整理，几乎成了现代营销商的当务之急。企业为了吸引这些顾客，保持持续的竞争力，必须不断地进行新产品的开发。P是指购买力。对大多数企业来讲，研究的重点是可任意支配的收入，因为它是影响消费者需求的最重要因素。

D是指购买欲望。在当代，由于电子技术、因特网以及商业竞争等因素的冲击，人们的购买欲望发生了很大的变化。３．用户概念及其层次

“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（theenduser）和“间接用户”（或称为关系人）。掏钱买产品的用户称为客户，而真正使用产品的用户最终用户。客户与最终用户可能是同一个人也可能不是同一个人。（１）客户是掏钱买产品的人，所以他是“上帝”

某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。与客户打交道的主要目的是：一是获取需求，二是签合同。（２）即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验产品，对最终用户进行培训等等。公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。”（３）重视“间接用户”，千万别“大意失荆州”

间接用户既不掏钱买该产品，也不使用该产品，但是它可能对产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。１．２需求及其层次结构一．需求的基本概念

宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。

需求的重要性FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：开发系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。

二．需求的层次

产品需求包含着多个层次，不同层次的需求从不同角度和不同程度反映着需求的细节问题。产品需求应该包括下面三个层次。（1）企业需求（EnterpriseRequirment）。从企业预测角度考虑，企业需求是指在一定的战略目标和规划下，估计经过一定的营销努力所能占领的最大市场份额。影响企业需求的因素主要是在一定市场总需求条件下的市场需求份额，它是由企业的产品、服务、价格、与竞争者的关系等因素决定的。（2）用户需求（UserRequirment）。从用户角度考虑，用户需求是指特定顾客群体为了满足自己的有能力的欲望，而要求产品具有的功能。它描述了使用产品可以满足用户要求的基本功能。这些需求通常描述的是产品使用性能的主要特征，或者说明了产品应该具有的性能状态和一些特征基本结构。（3）技术需求（TechnologyRequirment）。技术需求是指启动一个新产品开发工作所应具备的条件和能力，它们是通过一定的特性（feature）描述的。技术需求对应于需求设计过程中的T阶段，它一方面描述了如何通过技术条件来达到那些满足用户需求的产品功能；另一方面，还描述了在企业需求中制定产品开发总纲所需要的条件和能力。技术需求保存在产品的技术文档中。技术需求中的特性是指在逻辑上相互关联的技术条件或者能力的集合，它提供了处理产品需求的能力。由以上对产品需求过程从不同角度的分析可以看出，产品的企业需求是由企业高层管理人员或市场分析人员来确定的，详细的企业需求可以使公司运作目标明确、高效并具有很强的市场竞争力；用户需求使需求分析者能从中总结出用户对产品的要求，从而完成其市场分析任务；而开发人员和企业决策人员则根据技术需求来设计需求产品，以实现其必须具有的功能，并占有一定的市场份额。产品ID：产品名称：需求特征:能量:能量类型（热、冷、电等）；能量状态；输出；输入；转换；存储；消耗；效率.材料:材料类型（汽体、流体、固体）；材料状态；相位；输入；输出；流动；储存；转换；性能（强度、韧性、弹性等）.信号:信号类型（视觉：光；听觉：声音；嗅觉和味觉：味道；触觉：温度等；知觉：湿度、压力等）；输入；输出；转换；控制.特性:尺寸（高度、宽度、长度、厚度、位置、直径、间隙、公差、表面粗糙度、装配）；排列；连接；布局.性能:性能类型（快：速度和加速度；消耗；精确性；高；可靠）；功能；实现程度；寿命：疲劳和耐久性运动类型（线形运动、旋转运动、直线运动）；运动学；动力学；动态（位移、速度、加速度、猛动）；共振载荷类型（力、扭矩、弯曲、剪切、摩擦）；载荷方向；载荷大小；载荷频率；变形.安全性:类型（直接保护、间接保护、警告信号和标志）；环境安全；可靠性保证；规章制度.人机工程:操作（类型、姿势、位置、状态、安全、平滑、安静、舒适、方便、特殊用途）；人机界面；人体测量学.制造:类型（车、铣、刨、磨、钳、热处理等）；工厂设施（限制、能力、加工过程、加工方法、加工刀具）；废料；润滑；质量；装配（过程、特定规则、刀具、周期、地基）.质量:控制；保证（测试、检验、范围、方法、设施）.维护:方便；快捷；服务周期；检测；清洁；维修；替换；工具.利润:投资；费用（制造费用、工具费用）；减价；单位价格.计划:日期（开发周期、设计、生产、包装、运输）.运输:类型；方法；限制；提升齿轮；运输状况.美学:类型；形状；光亮度；颜色；表面形状.环境:类型；受限制材料；限制状态；回收.上市时间：评语:责任人：主管：需求内容１．３需求产品的定义

在市场经济的条件下，市场是企业生产和经营产品活动的出发点和归宿。企业的使命之一在于研究市场需求、适应市场需求、满足市场需求和创造市场需求。在产品的广义定义中，一种产品的功能和用途，就是这种产品的使用价值，产品的使用价值体现在实质产品层次上，该层次虽然是无形的，该层次中体现的产品使用价值正是决定市场需求的一个关键因素。新产品的开发不仅是技术上的创新，而且要根据企业的生产能力，体现在功能的创新、品牌的创新、质量的创新、价格的创新和商标的延续等诸多方面。事实证明，大多数新产品的开发建立在企业对现有产品进行改进的基础之上，其创新更多地体现在品质的改进、式样的更新、商标的开拓和包装的精美上，而这些创新无一不是建立在对市场需求充分调查基础上的。而顾客对产品的选择，主要体现在对产品延伸要素的关注：现代竞争并不在于各家公司在其工厂中能生产什么，而在于它们为顾客提供了什么服务。

定义：需求产品是企业用需求详细规格说明书定义的产品，主要描述了产品应具有的使用价值和服务承诺的总和。它的定义过程与定义的基本原则为：企业从自身的根本市场利益出发，为了满足特定人群需求，在产品开发全生命周期过程中的最前端的需求层次上，考虑到企业可开发性的条件下，用需求详细说明书描述的企业目标需求的载体。根据需求产品的定义，它也应该包含下面的三个层次：（１）实质层次。这里产品的使用价值并没有得到体现，但是针对市场空间中的特定人群，提出满足其需求的产品功能组成，以及考虑产品总体成本控制问题。（２）形式层次。需求产品包含的不是产品的实体，而是对产品形式各属性的总体方案要求的描述。（３）延伸层次。包含对企业历史上提供服务的评价和企业对新产品服务的承诺。根据描述需求产品的需求规格详细说明书中涉及的内容，产品需求可以分为三个层次：企业需求、用户需求和技术需求。对应这三种产品需求，可以定义不同的需求产品视图，下面给出了它们的定义。（1）企业需求产品。在需求产品的企业视图（EnterpriseView）中，企业需求产品是指，企业为了占领最大的市场分额，而制定了一系列战略目标和产品规划，在此基础上完成的需求产品总和。需求产品的最终目标是为了使企业获得最大利润，因此，企业视图中的需求产品是整个产品设计的总纲，决定了产品设计的规划和发展方向。（2）用户需求产品。在需求产品的用户视图（UserView）中，用户需求产品是指，满足用户需求的，由特定产品提供的使用价值和服务承诺的总和。企业生产产品的最终归宿是满足市场需求，而市场是由用户组成的，从某种意义上讲，市场需求就是用户需求，因此，在用户视图中的需求产品描述了用户对产品的要求。用户需求产品对产品的设计方案和技术有很深的影响。（3）技术需求产品。在需求产品的技术视图（TechnologyView）中，技术需求产品是指生产者为了满足用户需求，根据其能够提供的技术手段和设备，所生产出的具有一定的使用价值和服务承诺的产品实体（即从产品的形式层次上和延伸层次上予以实现）。在产品设计过程中，不仅需要企业从其目标市场的角度进行决策，需求分析者对市场进行详尽的市场分析，而且在完成对用户需求的分析后，还要根据本企业现有的技术条件，对产品进行可行性的技术分析。技术需求产品是在技术上对最终实现产品实体进行保证。１．４需求产品、概念产品和详细产品的关系

根据需求产品、概念产品和详细设计的产品的定义，它们作为产品的子集，可以从产品的三个层次分别进行比较：在产品的实质层次，需求产品、概念产品和详细产品（即详细设计出的产品）都是描述产品的使用价值，但在它们的模型中描述的属性是不同的。在需求产品模型中，对产品的实质层次描述是从用户的角度来考虑的，根据不同特定的用户组变化而变化，因此具有较大的弹性空间；在概念设计阶段，考虑了为满足上述需求，产品应该具有的功能和行为与总体成本控制；而在详细产品阶段，则是对产品实现上述功能行为系统特征所需的工程详尽描述。在产品的形式层次，需求产品主要根据市场的需求描述，考虑企业对需求产品的生产能力、产品形式层次各属性的改进方案、品牌和商标的延续等；在概念设计阶段，侧重于产品的方案设计，以及作为功能载体的产品结构的描述；而在详细设计产品阶段，则在于解决所定义的概念产品的具体实施所要求的技术细节的工程设计、实现产品形式层次各属性的方案等。在产品的延伸层次，需求产品主要描述企业对产品服务的承诺要求；在概念设计阶段，体现在对产品服务的制定和计划，也可以通过产品的行为来表现；而在详细产品阶段，企业在产品的详细设计上，要具体体现出产品的生命周期的可维护与服务支持的工程技术的解决措施，以便使企业得以拓展服务空间，争取更大的顾客满意度，获取更多顾客的重视。总之：需求产品是产品在市场上表现出的总体系统性特征期望的技术定义。它包括了：目标市场对产品的功能与效应要求，企业对产品开发目标市场的可行要求、可生产与成本控制要求，以及产品能提供目标市场的服务承诺要求。概念产品是满足需求产品期望设定的总体、系统性技术参数与特征结构的产品。详细产品是实现概念产品总体、系统性技术参数与特征结构而定义的，用于生产、销售及全生命期服务的产品。实质层形式层延伸层功能定义功能描述功能实现形式方案形式设计形式实现服务承诺服务安排服务体现１.５需求产品的设计过程

如图下所示，需求设计过程可以进一步分为：需求获取、评估和管理、功能需求分解、实例化需求模型四个阶段。上述四个子项包括产品需求获取、评价、编写文档和验证等所有活动。需求设计活动包括以下几个方面：确定产品所期望的用户类；获取每个用户类的需求；分析源于用户的信息，充分了解用户需求，并且帮助确定满足用户需求所要求的企业需求。根据需求的权重因子，制定需求实施优先级的划分；根据需求模型，将所收集的用户需求编写成需求规格详细说明书；评价需求规格详细说明书，确保对用户需求达到共同的理解和认识。需求处理系统需求开发需求管理需求获取需求分析编写需求详细说明书需求验证需求变更控制分析影响作出决策测量需求的稳定性需求版本控制确定需求文档版本确定单个需求文档版本

需求跟踪定义与其他需求的链接定义与其他产品元素的链接版本需求状态跟踪定义需求状态跟踪需求每一个状态作为产品设计系统模型的子过程模型，需求产品设计过程集R可以描述为从目标市场的需求到生成需求产品解的过程。而针对需求设计不同视图中的需求产品，也具有自己的需求产品设计过程子元素：Ri={需求获取、评估和管理，功能需求分解，实例化需求模型}={Ri1，Ri2，Ri3}其中：i=E,U,T，分别对应于企业需求、用户需求和技术需求三个视图。由需求产品设计过程集R得出的需求产品设计状态集PR是产品设计的状态集Q的元素。和不同视图中的需求设计过程相对应，PR的子状态元素为：PRi={需求描述，需求解集，需求产品}={PR1，PR2，PR3}其中：i=E,U,T，分别对应于企业需求、用户需求和技术需求三个视图中的需求产品。与PR相对应，需求产品设计映射集Φ是产品设计映射集的元素，Φ的子映射元素如下：Φi={Φi1，Φi2，Φi3}其中：i=E,U,T。分别对应于企业需求、用户需求和技术需求三个视图中的映射过程。PR1是由{CAs}组成的特征变量描述的；PR2是由{FRs}组成的特征变量描述的；PR3是由{DPs}组成的特征变量描述的。下式表示需求设计的过程、状态及映射关系如下：

R=PRiPRi+1

需求产品设计过程R模型可以用式表示：

R=RE∩RU∩RT

根据公理化设计理论的信息化最小公理，最终需求产品设计方为：

P=I×R 其中，I为信息内容（InformationContent）。PR1PR2PR3Φi1Φi2Φi3Ri1Ri2Ri3Φij1.6需求产品的信息模型需求产品信息模型包括物理描述层、逻辑描述层和应用描述层三个方面。在需求产品信息模型的物理描述层，详细描述了需求产品设计过程所涉及的所有功能及其组织管理，包括信息的获取、组织、显示和存储结构以及其相关的管理方法，直接支持产品信息的集成管理；在逻辑描述层，建立了需求产品设计的过程逻辑模型，即从用户需求到形成需求产品数据的一系列技术处理和管理过程活动与相互间关系；在应用描述层，反映了不同需求产品设计应用的具体可软件实现的信息模型，即与某一需求产品设计有关的信息模型。需求产品设计需求产品设计过程活动视图模型活动1活动2活动3活动n存储数据成分显示获取过程建模数据建模支持逻辑描述层物理描述层应用描述层需求产品设计存储存储数据成份显示存储活动n活动1活动2活动3需求产品设计过程活动视图模型1.7需求层次模型的实现

（1）需求商机模型（RequirementMarketabilityModel:RMM）。

商机由两方面因素决定，一方面是可能被开发的市场，另一方面是企业自身目标能力。需求商机模型因而描述了顾客自身信息及未满足顾客需求信息的数据结构，以及构成这些未满足需求的市场商机和企业决策结果的数据结构，它们是由结构化表达的产品市场属性数据组成的。需求获取和评估以及对需求产品决策过程中，涉及到的数据信息构成需求商机模型RMM，商机是在企业可能获得一定利润的基础上，由未满足的市场需求（由某种或某系列产品组成）和该产品的市场属性（提供的功能和服务等）组成。因此需求商机模型RMM是由市场商机预测模型MMCM和需求产品评估模型RPEM包含的信息组成的。另外，为了保存和操作市场调查得到的数据，还应该在RMM中包括市场调查数据模型MRDM。需求商机模型RMM、市场商机预测模型MMCM、需求产品评估模型RPEM、市场调查数据模型MRDM(2)需求参考模型（RequirementReferenceModel:RRM）

需求设计的过程，在商机确定之后，将通过商机的分析给出需求产品的总体要求，以作为具体定义需求产品的框架。需求产品总体要求框架的模型，称作需求参考模型。需求参考模型用一个数据结构来描述。其中input属性保存的是从需求商机模型得到的功能信息，而output属性保存的是输出到需求定义模型的功能单元信息，这些功能单元信息都可以映射到需求特征上。RRM包括两个方法，GenFunctionEle()方法用于生成功能单元，而DefFunctionEle()用于定义功能单元。FunctionEleType:StringCarrier:StringWeigh:IntegerRelation:StringRRMinput:FunctionEleoutput:FunctionEleDefFunctionEle()111..*<<Include>>BelongTo(3)需求定义模型（RequirementDefinitionModel:RDM）

根据需求参考模型所给出的需求产品总体框架，加以具体化解释与定义，而得到最终需求产品的模型。需求定义模型同样也是一个用数据结构描述的最终需求设计结果。需求产品是由需求规格详细说明书（ProductRequirementSpecification，PRS）描述的，这些规格应该描述产品的属性、对产品属性的评价和新产品开发中的约束（如成本、上市时间和创新性等）。为了尽可能地保持需求信息的完整性，在前面给出了15项需求特征，而需求详细说明书中对需求产品的描述正是建立在这15项需求特征的基础上。需求定义模型中各对象和需求特征的对应关系如下：图中符号表示为：Energy：能量；Material：材料；Signal：信号；Feature：特征；Performance：性能；Safety：安全性；Fabricate：制造；Quality：质量；Maintain：维护；Profit：利润；Plan：计划；Transport：运输；Ergonomics：人机工程；Esthetics：美学；Environment：环境。１.８需求工程（１）什么是需求工程把所有与需求开发直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图

（2）需求开发过程

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。（３）需求管理过程

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。需求工程的基本认识：不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种只有后两种才有可能开发出成功的产品。“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。（４）需求开发的主要困难与对策(A)知识技能问题

应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有。其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂开发又懂应用域知识的行家来帮忙。

(B)态度问题

相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发产品，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。

用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个产品开发过程，产生太多的后患。产品研发企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。

(C)合作关系如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧

……。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。(D)用户在需求工程中的“权利”1.有权要求开发方派遣资质合格的需求分析员和相关人员。2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂的需求文档。3.有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户在需求工程中的“义务”1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿(E)用户说不清楚需求用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧。有些用户虽然心里明白想要什么，但却说不清楚需求。

比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。

(F)双方误解需求人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了：有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避免：有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。

(G)开发人员写不好需求文档需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。古时候，一书生在考试前补习“写文章”，成天愁眉苦脸。其夫人甚为不解，问：“相公，你写文章比我生小孩还难吗？”书生长叹一声：“娘子你哪里知道我的难处啊！你生小孩时肚子里有东西，可我写文章时肚子里没东西啊。”所以要想写出好的需求文档，前提条件是把需求调查工作做好。开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。可以毫不夸张地说，国内90％以上的产品开发人员，他们的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。

(H)用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。

其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。

1.10如何开展需求调查(1)准备调查

首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。

其次，需求分析员应当确定需求调查的方式，例如：与用户交谈，向用户提问题。向用户群体发调查问卷。参观用户的工作流程，观察用户的操作。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。从Internet上搜查相关资料。最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。

(2)执行调查准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息。需求分析员与用户面谈时应当注意以下事项：如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，有些大企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤了。需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。避免片面地听取某些用户的需求而忽视其它用户的需求。(3)《用户需求说明书》与《产品需求规格说明书》的主要区别与联系前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是产品系统设计的直接依据。两者之间可能并不存在一一影射关系，因为产品开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到产品开发的数个版本中。产品开发人员应当依据《产品需求规格说明书》来开发当前产品。(4)撰写《用户需求说明书》

1.11如何进行需求分析(1)基本概念

为了得到用户的合同，企业必须坚持：用户就是上帝，用户永远是正确的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。

需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数产品开发工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用，很有实用价值。“问答分析法”比较适合于用户需求调查阶段“建模分析法”比较适合于产品需求定义阶段。

(2)问答分析方法问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。其它常见的问题有：

需求存在二义性吗？

需求文档的上下文有矛盾吗？

需求完备吗？

需求是必要的吗？

需求可实现吗？

需求可验证吗？

需求的优先级确定了吗？

(3)建模分析法人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。恰当地使用图形符号：现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。(4)作出决策当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达成共识的需求而言，经常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢？如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验，最保险的办法是：先听权威人士或威望高的，如果大家的职位和威望都差不多，那么采用“少数服从大多数”的原则。如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出资金最多就先满足他们的需求，以后再做那些获利相对较少的需求。当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正明显不合理的客户需求。如果产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造产品的虚拟原型，双方看着产品原型再分析需求。1.12什么是好的需求规格说明书(1)正确

需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。(2)清楚

清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：文档的结构、段落是否乱七八糟？上下文是否不连贯？

文档的语句是否含糊其词、罗里罗嗦？

看了半天是否还不明白需求究竟是什么？

(3)无二义性

“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。(4)一致

“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。(5)必要

《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。(6)完备“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的《产品需求规格说明书》将导致开发出功能不完整的产品，用户在使用该产品时可能无法完成预期的任务。(7)可实现

《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。(8)可验证

《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。(9)确定优先级

为什么要确定需求的“优先级”？理论上讲，产品的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。(10)阐述“做什么”而不是“怎么做”《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。国内的很多产品研发公司里，开发人员常常身兼数职，可能把需求开发、系统设计、详细设计等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。１．１３如何定义产品需求1．规程

第一步：细化并分析用户需求

需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。第二步：撰写产品需求规格说明书

需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。第三步：进行需求确认项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。2．软件需求规格说明书的参考模板１．１４

需求管理：确认、跟踪、变更控制1．需求确认（评审和承诺）需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。

2．需求评审面临的困难需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。

需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。

开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。

3．需求承诺需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺，该承诺具有商业合同的效果。需求承诺的“八股文”如下：本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。甲方签字乙方签字人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。4．需求跟踪需求跟踪的目的是建立与维护“需求－设计－修改－测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪。检查设计文档、代码、图纸、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。

5．需求变更控制需求发生变更的起因主要有：随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。需求变更控制的目的：如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。１.1５产品需求设计综合实例

需求产品的进化是分阶段完成的。最早可以称为掌上电脑的“计算器”是由一个处理器加上按键、只读存储器组成；后来逐渐为其固化电子词典，使用闪存为其提供存储功能；又根据用户需求，逐渐丰富其功能，提供播放MP3、游戏、VCD播放等功能。由此可见，需求产品的设计过程也应该满足可逐渐变化的用户需求，把目标市场中的用户需求及变化映射为使用需求详细说明书描述的需求产品。在这个设计过程中，目标市场中的用户需求是使用需求商机模型描述的，需求商机模型虽然包括很多对象和属性，但是其最主要的对象应该是ProductInfo，它是围绕着需求产品的定义所描述的用户需求。并且，在需求商机模型的其他对象中，提供了对用户需求的评估，需求产品最终通过规范化的需求特征表达出来，形成描述需求