需求分析最终结果是产生 需求分析的最终产物

决定培训需求起始依据的是什么

任务分析

决定培训需求起始依据的是任务分析，任务分析是具备执行任务所需的条件； 有特定的目标； 有明确的起始和终端； 发生在一定时间内；可能会被另一项任务打断； 可能涉及多人。培训需求分析是指在规划与设计每项培训活动之前，由培训部门采取各种办法和技术，对组织及成员的目标、知识、技能等方面进行系统的鉴别与分析，从而确定培训必要性及培训内容的过程。因此，决定培训需求起始依据的是任务分析。

扩展资料：

在一个人机系统中，任务分析是自上而下进行的，往往作为系统设计的基础阶段，或是为了对运行中的系统进行评价而进行。所谓自上而下，是指任务分析的过程是从一般到具体，即从工作系统目标、工作系统职能和工作系统运行，到已分配给系统内人员的任务与子任务。分析的最终结果是产生一个能完整地描述实现工作系统目标所需的人员、设备及其相互之间联系的信息库。

软件开发过程中的需求分析与开发框架的区别

需求分析奠定了软件工程和项目管理的基础。我们在建造软件系统这座大厦的时候，如果需求分析的基础不够坚实和牢固，那么往往会导致软件系统问题百出，甚至被马上丢弃。在建造软件系统的过程中，如果我们经常习惯地沿用一些不规范的方法，其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。 因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述，以及从开发人员角度对系统内部特性的描述，其关键的一点是“需求”必须文档化。

需求的类型

软件需求包括三个不同的层次──业务需求、用户需求和功能需求。 除此之外，每个系统还有各种非功能需求。

业务需求（BusinessRequirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。 用户需求（UserRequirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

非功能需求（Non-functional Requirement） 定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性（联机帮助、 数据管理、用户管理、软件发布管理、在线升级等）、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。

需求分析的任务

1 解决的问题

1) 齐全、准确地找出目标系统全部的功能、性能、限制； 2) 找出全部的输入流、输出流； 3) 找出所有的加工；

4) 产生完整的分层的DFD、数据字典、加工的描述； 5) 补充的意见。

2 综合要求

确定对系统的综合要求，系统功能要求，系统性能要求，运行要求，将来可能提出的要求。

3 任务

图1为需求分析任务图，需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档（需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书）。这个文档能清晰准确地说明系统将要开发什么，能够规定出详细的技术需求，包括所有面向用户、面向机器和其它软件系统的接口。可以说需求文档在开发过程中一直起指导作用。

为了更好地完成软件开发第一阶段的需求分析任务，提高质量，需求管理是必不可少的。

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更，主要体现在跟踪和控制需求变更管理。需求管理是开发工作有效进行的保证，是一种很高层次的系统行为，涉及整个开发过程和产品本身。

需求分析的方法

需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成，大多数的需求分析方法是由信息驱动的。信息域具有三种属性： 信息流、信息内容和信息结构。

常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向数据结构的Jackson方法（JSD），面向数据结构的结构化数据系统开发方法（DSSD），面向对象的分析方法（OOA）等。选择那种方法要根据哪些资源在什么时间对开发人员有效，不能盲目套用。这里着重阐述面向数据流的结构化分析方法（SA）。

面向数据流的结构化分析方法

面向数据流的结构化分析方法（Structured Analysis，简称SA），是面向数据流进行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一种建模活动，该方法使用简单易读符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。适用于数据处理类型软件的需求分析，这一方法除了简单，容易掌握之外，还能和设计阶段的结构化设计（SD）衔接，从而取得良好的设计结果。

自顶向下逐层分解的分析策略

SA方法的基本手段：“分解”和“抽象”。这是系统开发技术中控制复杂性的两种手段。它先将系统“抽象”成一个模型，此模型是有输入和输出并有系统名称的盒子，然后打开这个盒子，对它进行逐层分解，直到能被理解，可以实现为止。因此分析的策略是自顶向下，逐层加细，由抽象到具体的过程。如图2。

结构化分析方法使用工具

SA方法利用图形等半形式化的描述方式表达需求，简明易懂，用它们形成需求规格说明书中的主要部分。描述工具是

1) 数据流图：描述系统由哪几部分组成，各部分之间有什么联系等等。 2) 数据字典：定义了数据流图中每一个图形元素。

3) 描述加工逻辑的结构化语言、判定表、判定树：详细描述数据流图中不能被再分解的每一个加工。

由于分析中的主要依据是数据传递及数据变换所形成的数据流，所以结构化分析一般采用的方法是使用数据流图的分析方法，最终结果是产生需求规格说明书，该文档包括一套数据流图，对数据流图中的成分进行定义的一本数据字典及对加工逻辑的描述。

结构化分析步骤

用结构化分析方法进行系统需求分析的具体步骤是： 1) 了解当前系统的工作流程，获得当前系统的物理模型。通过对当前系统的详细调查，了解当前系统的工作过程，同时收集资料、文件、数据、报表等，将看到的、听到的、收集到的信息和情况用图形描述出来。也就是用一个模型来反映自己对当前系统的理解，如画系统流程图。

2) 抽象出当前系统的逻辑模型。物理模型反映了系统“怎么做”的具体实现，去掉物理模型中非本质的因素，抽取出本质的因素，构造出当前系统的逻辑模型，反映了当前系统“做什么”的功能。

3) 建立目标系统的逻辑模型。分析、比较目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，从而从当前系统的逻辑模型导出目标系统的逻辑模型。

4) 作进一步补充和优化。为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充。

需求分析最终结果是产生 需求分析的最终产物

说明目标系统的人机界面。

说明至今尚未详细考虑的细节（包括出错处理、系统的启动与结束、系统的输入/输出和系统性能方面的需求等）。

其他（系统特有的其他必须满足的性能和限制，也需要用适当的形式做出书面记录。 分析阶段结束时，系统分析员必须和用户再次认真地审查系统文件，争取在系统开始设计之前，尽可能地发现其中存在的一些错误并及时纠正，直至用户确认这个模型表达了他们的要求后，系统文件（软件需求规格说明书等）才作为用户和软件开发人员之间的“合同”而最后得到确定。

结构化分析方法的优缺点

1) 优点： 结构化分析方法是软件需求分析中公认的、有成效的、技术成熟的、使用广泛的一种方法，它较适合于开发数据处理类型软件的需求分析，该方法利用图形等半形式化工具表达需求，简明易读，也易于使用，为后一阶段的设计、测试、评价提供了有利条件。 2) 缺点：① 传统的SA方法主要用于数据处理方面的问题，主要工具DFD体现了系统“做什么”的功能，但它仅是一个静态模型，没有反映处理的顺序，即控制流程。因此，不适合描述实时控制系统。② 上世纪60年代末出现的数据库技术，使许多大型数据处理系统中的数据都组织成数据库的形式，SA方法使用DFD在分析与描述“数据要求”方面是有局限的，DFD应与数据库技术中的实体联系图(ER图)结合起来(如同IDEF0功能模型与IDEF1信息模型相结合一样)。ER图能增加对数据存储的细节以及数据与数据之间，数据与处理过程之间关系的理解，还解决了在DD中所包含的数据内容表示问题，这样才能较完整的描述用户对系统的需求。③ 对于一些频繁的人机交互的软件系统，如飞机订票、银行管理等系统，用户最关系的是如何使用它，输入命令、操作方式、系统响应方式、输出格式等都是用户需求的重要方面，DFD不适合描述人机界面系统的需求，SA方法往往对这一部分用自然语言作补充。④ 描述软件需求的精确性有待提高。 5 需求的变更

在开发项目过程中，用户随时会提出一些新的需求，要求开发方解决，这些需求的提出，有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中，或者在迭代周期的需求分析中，后一段或周期的需求分析结果与前一次不一致，我们把这种不一致称为需求变更。产生需求变更的原因主要有以下几个方面：1) 在需求分析阶段，开发方与用户的沟通不够。在需求分析阶段，开发方与用户没有很好的交流，开发方就根据用户提供的大概信息，自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远，导致用户提出更改需求。2) 项目的实施周期过长。随着时间的推移，用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。3) 技术更新过快。由于技术的快速更新， 企业可能引进一些新的设备， 而这些设备可能就会与我们的目标系统有直接的关系， 由于这一变化可能发生在解决用户原先问题之前或者之中，那么开发方不得不加入这一新的需求。[3]

为了尽可能地避免发生需求变更，以及保证需求分析的高稳定性，可以采用以下方法：1) 分工明确，系统分析员和程序员各有不同的职责。系统分析员处在用户和程序员之间，沟通用户和开发人员的认识和见解。系统分析员一方面要协助用户对所开发的软件提出需求，另一方面还要和程序员充分交换意见，探讨其合理性和实现的可能性。如图3所示，系统分析员在需求分析阶段起着重要的作用。

2) 开发方与用户进行协作和交流。在用户提出需求变更时系统分析员应该认真听取用户的要求并加以整理和分析。分析需求变更的原因并提出可行的替代方案；同时向用户说明这些需求变更会对整个项目的开发带来的不良后果。3) 合同约束。由于需求变更可能会对整个项目产生影响，所以，开发方和用户在签定项目合同时，可以对需求变更增加一些相关的合同条款。4) 建立需求文档并进行版本控制。需求分析的最终成果是一份客户和开发方对所开发的产品达成共识的系统文档。有了这份文档， 即使开发方人员的角色有所变动，也不会对需求分析的前期工作有所影响。对每次的需求变更都用一个新的版本来标识。5) 需求评审和设立需求基线。为了让开发方详细了解用户的需求，让不同人员从不同的角度对需求进行验证，作为需求的提出者（用户方），在需求评审过程中，往往能提出许多有价值的意见，同时，也是对需求进行最后确认的机会，可以有效减少需求变更的发生。需求在通过正式评审和批准之后，应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。

软件架构（software

architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系

统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向

对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw

认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结

构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

但构架不仅是结构；IEEE Working Group

on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注

重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管

理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑

和流程。

一般而言，软件系统的架构（Architecture）有两个要素：

它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和

联结器完成某一项需求。

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

对于较大的通常应用应该使用框架，可能节省不少时间.。能使你很轻松的开发出一款软件来。

（软件开发一般比较会关注设计模式而不是架构设计）

需求分析的任务是什么

需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。

需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。

进行需求分析需要做到以下几点：

（一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。

（二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。

（三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。

（四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。

（五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。

（六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。

以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。

大话软件工程：需求分析与软件设计（五）

需求工程，是构建管理信息系统的第一步工作，是对客户的现状和需求进行调研，并按照工程化的方法和标准完整、准确地记录和分析客户的需求，它的成果是进行后续设计工程的基础。

1．定义

需求工程，是指采用工程化的方法和标准，收集、记录和分析客户对信息化的需求，并最终确定系统需要实现的功能以及功能的相关特征和约束。需求工程包含三个主要的部分：需求调研、需求分析、需求管理。

注：关于需求管理

需求管理是需求工程中非常重要的内容，包含对需求的跟踪、控制、变更、版本管理等内容，它是保证系统的内容、质量、进度的重要手段，需求管理的内容更加偏重于软件的过程管理。

2．作用

需求工程的作用归集为一句话就是：收集客户想要做什么，最终确定实际做什么。

对于一个应用软件的开发来说，需求工程成果的质量极大地影响着这个软件的设计结果，是决定成败的主要环节，从客户那里完整地获取、记录、分析与确认需求，并正确地传递给后续的工程是一个需求分析师的必备能力。需求工程的分析成果形成的需求规格说明书不但是后续设计与开发的依据，同时也是客户对完成系统评估、验收的依据。

另外一方面，需求工程的内容也极大地影响着软件开发的成本、技术、周期、资源、质量以及最终客户的满意度等诸多方面。需求工程的成果不但会影响客户最后获得的效果，也会影响到软件开发者的最终利益。

需求工程的核心工作是需求调研和需求分析，最终的主要交付物有两个。

1）需求调研成果（需求调研资料汇总）

从客户现场通过面对面的调研收集到的第一手需求资料，包括用图形、文字和表格等方式记录的原始资料，形成需求调研资料汇总。

2）需求分析成果（需求规格说明书）

基于前述的调研资料进行分析，识别出最终需要进行开发的全部内容，并且通过客户确认，最终形成需求规格说明书，这是后续设计、开发过程的依据。

1．需求的收集与确认

从客户不清晰的原始需求到可以进行编码开发的过程中，对收敛贡献最大的部分是②需求工程，而比较容易进行规范化、标准化作业的是③～⑤的部分。②将①的复杂内容梳理并形成了清晰的需求说明规格书。③将②的成果再进一步抽提、转换成为架构、功能和数据的设计成果。④将③的成果再进一步抽提、转换为组件、机制的构成方式。⑤将④的成果用编码的形式开发成为最终的软件。

从图形的推进变化上可以看出，需求工程②担负着将原始需求①的内容理出头绪并形成一份清晰明了、可以确认的需求规格说明书的任务；而③～⑤的一系列工作，越靠后的部分就越单纯，复杂度降的越低，要做的事就越收敛。②需求工程是开拓者，它担负了最为杂、乱、累的工作，从客户原始需求到编码的5个步骤中对收敛起的作用最大。②部分图形的收敛越大（梯形的坡度大），③以后的设计开发的图形就越接近于正矩形，工作就越顺利，否则②～⑤都是大坡度的梯形时就说明需求工程做的不到位，在后续的设计和开发中会不断地发现前期的需求有问题而造成返工。

注：关于“收敛”的含义

收敛，指的是将复杂的原始需求，归集成为可以进行标准化作业的过程。标准化的作业内容是不受需求影响的，不论需求是否复杂其内容都是固定的。

2．需求，并非都是来自于客户调研

构建信息系统的需求是否都是从客户那里获得的呢？这个问题反映出了完成的系统中有多少内容是经过软件工程师（包括咨询、需求、设计、开发、实施等）提案的，这些提案往往包含更多的高级需求、更多的附加价值，需求的来源有多个。

1）基本需求

基本需求来自于对客户进行的“调研”，这类需求以功能需求为主，基本上按客户意愿进行设计和开发，内容大部分在需求调研、需求分析阶段内确定。

2）中级需求

中级需求不是客户直接提出来的功能需求，而是在需求分析阶段、业务设计阶段通过对客户提出来的业务需求进行转换、优化、补缺、提升的过程中产生的需求，也就是为完善业务而产生的需求。

3）高级需求

高级需求主要来自于软件工程师根据本次客户的目标需求、新的设计理念、新技术等而提出，也就是说，高级需求是软件工程师设计出来的需求，例如，“事找人流程设计（架构）”“按照任务设计组件（功能）”“数据的复用（数据）”等。“设计需求”需要软件工程师有足够的知识和能力。

上述三个需求来源的获取难度顺序为高级需求＞中级需求＞基本需求。

软件工程师要认识到，需求工程（调研与分析）完成了，并非是需求获取的工作全部完成了，只是由客户直接提出来的需求完成了，而通过设计工程的需求发掘尚未开始。

注：高级需求会影响开发成本这里只考虑如何发掘有价值需求的方法，不考虑新需求带来的开发成本问题。

需求通常分为两大类，即功能性需求和非功能性需求。

功能性需求是系统必须要提供的业务处理功能，也是软件需求的主体。通常所说的需求前面没有形容词时指的都是功能性需求。

获取的需求可以分为三类，它们之间存在着转换关系，按照转换的顺序分为： 目标需求、业务需求以及功能需求。

目标需求：客户提出的信息化的目标、理念、希望、价值。

业务需求：客户提出的系统要对应业务的内容、过程、规则等。

功能需求：确定系统必须提供的处理业务需求的功能及功能的具体描述。

非功能性需求是指建立一些指标性的条件来判断系统运行情况，而不是针对某个业务处理的具体功能需求，它们被用来判断运行的系统是否可以满足以下的条件：安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等。

售前咨询的结果中包含着很多对需求分析、业务设计而言非常重要的输入，特别是很多的“目标需求”来源于此，目标需求对后续信息系统整体规划、顶层设计有着非常重要的影响

1．售前咨询的内容

在进入到设计工程之前的阶段，与客户的所有交流和沟通的目的都是在获取需求，特别是对大型项目来说，签订合同之前通常会有一个售前咨询阶段，在这个阶段一般软件商会派出经验比较丰富的咨询师（如专家型咨询师）来与客户进行交流，探讨根据客户的需求可以提供什么样的解决方案，这个阶段的咨询具有以下几个特点。

●　合同尚未签订，具体信息系统做什么内容尚未确定，能否签约取决于咨询的结果。

●　此时客户方面的参与者多为企业高层，如经营者、高级管理者以及信息化主管等。

●　客户的需求多为目标需求、业务需求甚至是难度痛点等内容，较少谈及功能需求。

●　需求会涉及企业的发展战略、现存的主要问题及公司对信息化的期待等内容。

●　交流中谈到的内容可能会比较抽象，需求也多为隐性需求，是否能够成为真实需求需要咨询师去引导、判别、确认等。售前咨询通常谈到的都是相对高端的需求，它们是后续需求分析中“目标需求”的主要来源，是企业经营管理者对信息系统的价值期望（尽管可能是用隐性方式提出的），在后续所谓的“需求调研”阶段中，往往可能就没有机会再去直接听取企业高管的需求了，所以这个部分的内容要作为非常重要的需求记录下来，作为后续需求分析的重要参考素材。

2．售前咨询与需求工程

售前咨询的方式非常依赖于咨询师个人的能力和魅力，它并没有特别规范和标准的交付物以及模板，因此没有将咨询工作明确地列入到需求工程中（软件商不同可能划分方法不一样），这两者的重点不同。

（1）售前咨询：重点是通过售前咨询活动，提出解决方案，协助销售部门签下合同。

（2）需求工程：重点是进入客户现场，对已经确定的合同内容进行详细的调研。虽然咨询的主要目的是促成签订合同，但是咨询阶段收集到的信息是非常重要的需求工程分析对象，尤其是“目标需求”。

3．咨询师的作用

（1）咨询师，代表的是软件企业的最高专业水准，他应该是软件商的名片。

（2）咨询师是全面阐释软件商的理念与主张的传道士。

（3）咨询师建立的起点高，则整个项目的起点高，总价值也会高（对软件商与客户双方）。

（4）咨询师要能够利用储备的知识和经验，为客户的决策者充当顾问、参谋。

（5）咨询师的工作重点是要与客户项目的决策人进行沟通，获取客户的目的、期望等目标需求。

4．咨询师的能力要求

对于从事售前咨询的专家型咨询师来说，对他的要求就比较高了，主要体现在以下几个方面（不限于此）。

1）沟通能力沟通的对象有客户的决策层，生产、财务等中间管理层，对能力的要求较高，例如，

●　理解：是否能够理解高层的谈话要旨、隐含的需求？

●　展示：能否充分地展示出软件企业的服务能力、产品能力？

●　说服：能否说服客户，例如，导入系统后要在组织或管理制度上做相应的改变？等等。

2）专业能力对咨询师而言，对他的专业能力要求是综合的。

●　是否掌握行业咨询的基本知识？

●　是否熟悉客户的主营业务和辅营业务知识？

●　是否基本清楚软件行业的最新技术、匹配的案例、解决方案等。

需求工程的工程分解分为两个阶段，即需求调研阶段和需求分析阶段

需求调研阶段的主要工作有两个：需求调研，资料汇总。

（1）需求调研：利用问卷、现状构成图、访谈记录、既存表单的方式收集客户的需求。

（2）资料汇总：将调研过程中收集到的资料进行汇总，形成需求调研资料汇总，作为需求分析阶段的分析依据。

需求分析阶段的主要工作有两个：需求分析，资料汇总。

（1）需求分析：基于需求调研资料分析客户的需求，最终确认系统需要实现的功能。

（2）资料汇总：将分析成果资料进行汇总，形成需求规格说明书，作为后续的各个设计阶段的输入。

1．需求调研

目的主要是收集、记录客户对信息化的需求，重点是对内容的“记录”，而不是“分析”或是“设计”，避免因为分析与设计融入了需求分析师个人的见解，需求调研阶段的资料一定要保持其“原始性”（使用需求模板是为了使记录内容标准化、格式化）。

需求分析最终结果是产生 需求分析的最终产物

2．需求分析

在对需求调研资料的理解基础之上，进行了抽提、归类、梳理，同时根据分析补全了调研时的断点，并且采用比较规范的方式进行了表述，重要的是：需求分析师通过对目标需求、业务需求等高端需求的分析加入了个人的理解，以及对企业信息化提升有价值的意见，所以需求分析的结果与原始记录之间会发生不同，需求分析师的理解代表了软件开发团队的理解，并以此为基础向客户进行确认，最终稿就形成了向下一个设计环节的输入资料。

所以说，需求分析师的能力会最终影响到信息系统的内容、技术、成本和周期等。

3．二者的关系

两者都采用非技术设计用语描述，需求调研采用“客户用语”进行记录，需求分析采用“业务设计用语”表达分析的结果。在工作目的上两者有所不同，例如：需求分析做的业务流程图必须具有业务的完整性，且符合业务流程的标准表达方式；而需求调研收集到的业务流程图可能是片段的、不连续的流水账。需求分析对需求实体的内容进行了抽提、分类，建立了需求体系表；需求调研阶段不要求这个梳理，只进行原始的收集和记录即可（要保留原始状态）。需求分析成果的作用有两个：向前端的客户确认，向后端输出设计依据；需求调研的成果仅仅是向需求分析提供资料。两者最大的区别如下。

（1）需求调研：着眼于对原始需求的收集、记录。

（2）需求分析：着眼于从整体上理解、归集、确认，需求分析不是对需求调研的重复。

需求工程阶段完成的资料对后续的各个设计阶段的影响

（1）需求调研：收集、梳理客户的原始需求。

（2）需求分析：调研资料只提供给需求分析，不能被设计所直接引用（可以参考）。

（3）概要设计：要完整地对需求分析的结果全面覆盖，给出规划。

（4）详细设计：原则上是针对概要设计的成果进行细节设计。

（5）应用设计：对需求分析中关于应用方面的要求给出系统实现的方法。

（6）技术设计：对需求分析成果中的非功能性需求、技术需求做出响应。

（7）、（8）开发～测试：不能将需求分析的成果作为开发与测试的依据（可以参考）。

（X）系统验收：客户对系统的最终验收是依据需求规格说明书进行的。

需求调研并不是按照工作的顺序或是调研内容之间的关系去进行的，因此不存在严格意义上的工作分解，它是按照需求表达形态的不同进行划分的，需求表达的形态分为三个类型。

（1）图形类：包括表达客户业务现状的图形、用界面表达的需求等。

（2）文字类：通过问卷、访谈记录形式收集的用文字表达的需求。

（3）表单类：客户提供的实际报表、单据形式的需求。

这三种类型的资料相互之间没有必然的关联关系或是顺序，可以同时进行收集。

需求调研的结果经过梳理，将非功能性需求分离后剩下的都是功能性需求，可以按照功能性需求的定义将它们分为：目标需求、业务需求和功能需求，这三者存在着目标需求→业务需求→功能需求的转换关系。严格地讲，它们不是三种类型的需求而是需求的三个层次，最终只有成为第三层的功能需求才能在系统中实现。分析阶段的工作分解就是按照这个顺序确定的。

（1）第一层工作：对目标需求的分析、向业务需求的转换。

（2）第二层工作：对业务需求的分析、向功能需求的转换。

（3）第三层工作：对功能需求的分析和确定。

建立相应的需求体系，没有这个需求体系，就是用个人的经验来解决客户的问题，有了这个体系，就可以做到用集体的经验和智慧来解决客户的问题。这里需求体系主要指的是建立“业务需求”。

建立了需求体系可以带来很多的价值，试举几例如下。

1．体系化的知识积累

（1）研究与实践的成果可以有条理地进行积累，包括：理念、方法、标准、规范等。

（2）客户价值的积累，包括：不同业务领域、行业、板块、系统、模块、功能等。

2．商业规模化的需要

（1）提升软件企业的价值，可以为客户提供体系化的解决方案。

（2）抽提、规划、建立新的商业模式，对客户的需求进行快速响应。

3．降低成本提高效率

（1）积累的知识可以得到有效的复用、共享，降低成本。

需求分析最终结果是产生 需求分析的最终产物

（2）可以大幅度地缩短开发周期，同时可以帮助减少“需求失真”现象。

4．规避风险的首要措施

（1）规避风险的最佳方式是让每个人事先知道该如何做，有了体系支持就可以做到。

（2）人的能力不足、调研分析时间短的问题，可以用知识库帮助解决。

5．快速培养人才的捷径作为需求分析师，被要求具有很多的能力，例如“业务能力”“沟通能力”“抽象能力”“表现能力”等，但这太抽象，难以理解，而且非一日之功。建立一个可以提供大多数人直接参考和共享的知识库，可以让需要者“有序可循”，它像一个“业务平台”，可以让大家提供经验、分享知识，并由大家共同维护。

需求工程可以说对每个从事软件行业的人员来说都是基础知识。因为它的核心内容是：

（1）如何与他人交流，如何快速地理解他人的想法，如何向他人传递想法等？

（2）对一个复杂的、不熟悉的研究对象如何快速找到切入点？

（3）如何将一个不清晰的对象，用简单的语言、图形或是表格的方式表达出来？

（4）如何将客户用语（知识、经验）表达的需求转换为业务设计用语的表达方式？等等。

管理信息系统的需求数量多少、需求的附加价值高低，取决于客户对信息化的目的和需求分析师的能力，需求分析师的位置通常是夹在前面的“咨询师”和后面的“业务设计师”之间，当软件企业具有这两个岗位或是该项目配置有这两个岗位时，需求分析师自身能力对项目的影响可以在某种程度上得到控制，如果软件企业没有其他两个岗位或是本项目没有配置这两个岗位，那么需求分析师就决定了这个项目的最高水平（企业管理型项目的最高水平通常是由业务设计师决定的），因此他就必须要掌握一定的咨询和业务设计知识。

需求工程，以设计输入为要求标准

需求工程不但是一门“知识”，同时也是一门可以定性定量执行的“技术”，它有模板、有流程、有标准，更重要的是它与后续的设计有着严格的传递与继承关系，由于有了设计的范围、内容、格式等作为需求工程的产出标准，所以需求工程要做的内容就非常具体、规范，作为一门“技术”的需求工程的可操作性大为提升。建立以设计输入为需求工程标准的方法，可以提升设计质量、产品质量以及工作效率。