1简介

1.1文档目的

本指南的目的在于指导公司所有产品和项目的需求开发活动，确保需求开发活动能够遵循有效的工作方式和方法。

1.2适用范围

本文档的适用范围为同洲电子股份有限公司的需求开发。

1.3术语

需求：系统必须符合的条件或具备的功能，并通过文档进行说明。

干系人：指所有可能受到项目结果重大影响的人，如客户（或客户代表）、用户（或用户代表）、投资者、项目经理、系统分析员、设计师、测试工程师 、PPQA等。干系人即可能是项目的受益者，也是项目的风险承担者，甚至有可能是项目的受害者。

业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求：描述了用户使用产品必须要完成的任务，这在用例(use case)文档或方案脚本说明中予以说明。

产品需求：定义了开发人员必须实现的产品功能，使得用户能完成他们的任务，从而满足业务需求。

特性：是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

1.4参考资料

《PRC-需求开发过程》

《PRC-需求管理过程》

《PRC-评审管理过程》

《PRD-技术评审规范》

《G-项目管理指南：项目分类管理》

《PRD-集成测试规范》

《PRC-集成产品开发过程》

《PRD-集成产品开发组织角色定义规范》

《PRD-项目组织定义规范》

2需求开发基本概念

2.1需求工程

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程分为需求开发过程和需求管理过程。以下是需求工程的构成：

图一 需求工程构成

2.2需求的层次

需求开发将分为三个不同的层次：业务需求、用户需求、系统需求并最终形成系统需求规格说明书，它们之间的关系层次如下图所示：

图二 需求层次

2.3需求开发的内容

需求开发活动包括的内容主要有：

●确定产品所期望的用户类。

●获取每个用户类的需求。

●了解实际用户任务和目标以及这些任务所支持的业务需求。

●分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

●将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

●了解相关质量属性的重要性。

●商讨实施优先级的划分。

●将所收集的用户需求编写成规格说明和模型。

●评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。

2.4优秀需求具有的特性

优秀需求的特性主要体现在需求说明和需求规格说明的特征，下面是针对优秀需求说明应具有的特征，后续章节会对优秀需求规格说明的特征进行描述。

需求说明的特征：

●完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

●正确性

每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。

●可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位项目开发组的成员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

●必要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

●划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

●无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

●可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

3需求获取

需求获取是一个确定和理解不同客户和用户的需要和约束的过程。需求获取主要通过与客户和用户的交流开发、捕获和修订客户和用户的需求。

项目任务书下达后，项目经理组织进行有目标的需求获取活动。需求获取主要通过调研活动完成，需求获取的工作产品可能有调研报告、调研备忘录或非正式的邮件等。调研活动要求制定计划，按计划进行。

3.1需求获取原则

定义客户的需求就是指通过与客户的长期沟通，对客户购买产品的欲望、用途、功能、款式进行逐渐发掘，将客户心里模糊的认识以精确的方式描述并展示出来的过程。

当然，在进行客户需求定义是要注意从不同的角度和侧面来分析，具体为遵循以下几个原则：

●全面性原则　对于任何已被列入客户范畴的消费者，我们要全面的定义其几乎所有的需求，全面掌握客户在应用中对于各种产品的需求强度和满足状况。之所以要全 面了解，是要让客户应用中的需要完整地体现出来，而且根据客户的全面需要分析其使用习惯、消费偏好、购买能力等相关因素。

●突出性原则　项目的目标是帮助客户满足需求，为公司赢得利润。所以，要突出产品和客户需求的结合点，清晰的定义出客户的需求，从而实现双赢。

●深入性原则　沟通不能肤浅，否则只能是空谈。对客户需求的定义同样如此，只有 深入的了解客户应用的各个环节，才会发现其对产品拥有的真正需求。也就是说，要对客户的需求做出清晰的定义，事前工作的深入性是必不可少的。

●广泛性原则　广泛性原则不是对某一个特定客户需求定义时的要求，而是要求销售人员在于客户沟通是要了解所有接触客户的需求状况，学会对比分析，差异化的准备自己的相关工具和说服方法。

●建议性原则　客户不是我们的下属，所以命令他们是不会接受的，当然我们也不可能这么做。在客户需求的定义过程中同样如此，客户所认同的观念跟我们或多或少的存在一些差异，所以对客户的需求要进行定义只能是“我们认为您的需求是……，您认同吗？”

3.2需求获取任务

需求获取主要的任务有：

●编写项目视图和范围文档。项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。具体操作中可在立项报告中体现。

●将用户群分类并归纳各自特点。为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。

●选择每类客户/用户的产品代表。为每类客户/用户至少选择一位能真正代表他们需求的人作为那一类客户/用户的代表并能作出决策。他们必须一直参与项目的开发而且有权作出决策。

●让客户/用户代表确定使用实例。从客户/用户代表处收集他们使用系统完成所需任务的描述——使用实例，讨论用户与系统间的交互方式和对话要求。

●召开系统开发讨论会议。系统开发讨论会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。

●确定质量属性和其它非功能需求。在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。这些特点包括性能、有效性、可靠性、可用性等，而在这些质量属性上客户提供的信息相对来说就非常重要了。

●通过检查当前系统的问题报告来进一步完善需求。客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。

●跨项目重用需求。如果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的系统组件。

3.3需求获取方法

以下三种方法是需求获取最常用的方法，对于不同的项目或产品的需求获取可以用到其中的一种或几种，也可能用到其它的方法，总的目标是确定和理解客户或用户的原始需求，为后续的需求分析、定义、验证及实现奠定基础。其中，问卷调查法常用于对业务有一定理解（如已有最初版本的产品）的项目或产品；会议讨论法常用于新业务（如新产品或客户化需求）的项目或产品；用例模型法对需求获取人员要求比较高，必须掌握好用例建模技术，可用于各种项目或产品。

3.3.1问卷调查法

所谓“问卷调查法”，是指开发方就客户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向客户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。

这种方法适合于开发方和客户方都清楚项目需求的情况。因为开发方和客户方都清楚项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。

这种方法的一般操作步骤有：

●开发方先根据合同和以往类似项目的经验，整理出一份《问卷调查表》提交给客户；

●客户回答《问卷调查表》中提出的问题；

●开发方拿到客户返回的《问卷调查表》进行分析，如仍然有问题，则重复第二步，否则执行下一步；

●开发方整理出《客户需求列表》，提交给客户方确认签字。

由于这种方法比较简单、侧重点明确，因此能大大缩短需求获取的时间、减少需求获取的成本、提高工作效率。

3.3.2会议讨论法

会议讨论法是指开发方和客户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。

这种方法适合于开发方不清楚项目需求（新产品的开发一般如此）但客户方清楚项目需求的情况。因为客户清楚项目的需求，则客户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对客户提供的需求一般都能准确地描述和把握。

这种方法的一般操作步骤有：

●开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；

●会后开发方整理出《需求调研记录》提交给客户方确认；

●如果此主题还有未明确的问题则再次沟通，否则开始下一主题；

●所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《客户需求列表》，提交给客户方确认签字。

由于开发方不清楚项目需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。

3.3.3用例模型

用例模型是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。参与者(Actor)和用例(Use Case)是用例模型中的主要元素。

下图显示了自动取款机系统用例模型的一部分：

图三 用例模型示例

用例图用于显示包含参与者和用例的用例模型示例。系统建模有许多种方法，每种建模方法可以满足不同的目的。然而，用例模型最重要的作用是将系统行为传达给客户或最终用户。可能与该系统交互的用户和任何其他系统都是参与者。由于参与者代表了系统用户，它们协助界定系统并提供十分明确的系统用途说明。编写用例依据参与者的需求来进行。这样就确保该系统成为用户期望得到的系统。

参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的。找到这些用例和参与者后，应对它们作简要说明。在详细说明这些用例之前，客户应复审该用例模型以核实所有的用例和参与者都已经找到，并且它们可以提供客户所需要的东西。

最后，对已完成的用例模型（包括用例说明）进行复审，开发人员和客户使用该模型对系统应执行的操作达成一致意见。

4需求分析

需求分析（requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和系统需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样就能作出实用的项目估算并可以进行设计、构造和测试。

通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

4.1需求分析内容

需求分析的内容主要包括以下几个方面：

●绘制系统上下文范围关系图：主要用于定义系统与系统外部实体间的界限和接口的简单模型，可以为需求确定一个范围。

●分析需求的可行性：这个需求我们应该用什么技术解决，他实现后的性能怎么样，是否与其它需求相重合或是矛盾，这里一定要注意不要把系统的这个需求怎么用代码实现想进去。在需求分析时应多注意需求本身是否有用而不必考虑怎么实现。

●确定需求的优先级：可采用满意度/不满意度指标来说明。

●为需求建立模型—物理模型和逻辑模型。

4.2需求分析方法

4.2.1结构化分析法

结构化分析方法是面向数据流进行需求分析的方法。结构化分析方法使用数据流图DFD（Data Flow Diagram）与数据字典DD（Data Dictionary）来描述，面向数据流问题的需求分析适合于数据处理类型系统的需求描述。其基本思想是分解化解问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。具体来说，结构化分析方法就是用抽象模型的概念，按照系统内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。这种方法由于利用图形来表达需求，清晰、简明，易于学习和掌握。但其不足之处是不能表达复合逻辑的需求分析问题，不能详细描述加工。

数据流图是从数据传递和加工的角度，以图形的方式描述数据流从输入到输出的传输变换过程。数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。数据字典是关于数据的信息的集合，对数据流图中的各个元素做完整的定义与说明，是数据流程图的补充工具。数据流图和数据字典共同构成系统的逻辑模型。它的用途主要是用作分析阶段的工具。

4.2.2面向对象分析法

面向对象分析法指用面向对象的方法进行需求分析，其根本要点在于，利用“对象”的概念模型建立一个针对于问题域的模型，客户和分析师通过该模型进行交流。通过在这么一个基于“对象”的问题域模型的基础上形成需求规格说明书。

面向对象分析法具体做法如下：

●通过查看相关资料并与客户（用户）广泛地接触，自己对问题域有一个大致的了解。在这个基础上，将问题域中与系统和问题有关的对象提取出来。这就是标识对象的工作。

●将抽象出来的对象(类)的之间的关系考虑清楚；如整体与部分、从属关系等；

●为“类”提取与系统问题域有关的属性、服务等；

●由于要完成一项任务，肯定是有不同的对象互相协作完成的。同时一个对象的属性，服务也是在与相关对象的协作中体现出来的。将问题域中所有任务的对象的协作关系搞清楚，是面向对象需求分析的关键一环。即将问题域中的“剧情”搞清楚，是需求分析的主要工作之一。

以上四个方面并不是单独的而是互有联系，可以同时进行的。通过，对以上工作的反复执行我们就可以建立一个基于对象的问题域的模型。基于该模型的基础上，可以比较容易地产生一个符合客户和用户需求的需求规格说明书成为后续工作的基础。

5需求定义

5.1需求规格说明书

需求定义就是把需求分析的内容系统的文档化，形成需求规格说明书，而需求规格说明书就是对需求分析中确定的需求进行清晰准确地描述。

需求规格说明书是系统设计、开发、测试等项目活动的基础和根据。每个项目必须提供《系统需求规格说明书》，对硬件和结构有要求的同时提供《硬件需求规格说明书》和《结构需求规格说明书》，需求规格说明书具体内容请查看相关模板。

5.2优秀需求规格说明的特点

●完整性

不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于避免不完整性。如果知道缺少某项信息，用“待确定”作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的“待确定”项。

●一致性

一致性是指与其它软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。

●可修改性

在必要时或为维护每一需求变更历史记录时，应该修订需求规格说明书。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在需求规格说明书中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

●可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段的叙述。

6需求验证

6.1需求评审

需求开发的工作结果是系统设计开发的重要基础，大量统计数字表明，产品中15%的错误起源于错误的需求。因此，需求规格说明书完成以后，需要认真进行技术评审和修改。作为需求开发工作的复查手段，在需求开发的最后一步，应该对功能需求的正确性、完整性和清晰性，以及其他非功能性需求给予评价。

需求验证通过正式的技术评审“需求评审”进行，具体评审过程、组织、要求可参见《PRC-评审管理过程》和《PRD-技术评审规范》。

6.2需求验证方法

需求验证必须从一致性、完整性、现实性和有效性等四个不同角度验证需求的正确性。验证的角度不同，验证的方法也不同，下面是针对不同验证的验证方法：

●验证需求的一致性

当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证需求规格说明书的正确性之外，目前还没有其他更好的测试方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致设计开发工作不能在正确的基础上顺利进行。

为了克服上述困难，人们提出了形式化的描述软件需求的方法。当需求规格说明书是用形式化的需求陈述语言书写的时候，可以用工具验证需求的一致性。

●验证需求的现实性

为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析需求规格说明书的现实性。

●验证需求的完整性和有效性

为验证需求建立评审检查单，评审成员根据检查单系统的验证需求的完整性和有效性。同时使用适当的原形系统提高验证的效率和质量。

• 上一篇：系统需求变更确认书(模板)
• 下一篇：谈谈新产品开发项目中的需求问题