G-需求开发指南

需求开发指南文档编号：COSHIP-CMMI-GDL-RD密级：机密版本信息：V1.0批准日期：编辑软件：MS Office W ord2003 SP2，MS Office Visio2003 SP2文档修订记录目录文档修订记录 (2)目录 (3)1 简介 (4)1.1 文档目的 (4)1.2 适用范围 (4)1.3 术语 (4)1.4 参考资料 (4)2 需求开发基本概念 (5)2.1 需求工程 (5)2.2 需求的层次 (5)2.3 需求开发的内容 (6)2.4 优秀需求具有的特性 (6)3 需求获取 (7)3.1 需求获取原则 (8)3.2 需求获取任务 (8)3.3 需求获取方法 (9)3.3.1 问卷调查法 (9)3.3.2 会议讨论法 (10)3.3.3 用例模型 (10)4 需求分析 (11)4.1 需求分析内容 (12)4.2 需求分析方法 (12)4.2.1 结构化分析法 (12)4.2.2 面向对象分析法 (12)5 需求定义 (13)5.1 需求规格说明书 (13)5.2 优秀需求规格说明的特点 (13)6 需求验证 (14)6.1 需求评审 (14)6.2 需求验证方法 (14)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.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会议讨论法会议讨论法是指开发方和客户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。

这种方法适合于开发方不清楚项目需求（新产品的开发一般如此）但客户方清楚项目需求的情况。

因为客户清楚项目的需求，则客户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对客户提供的需求一般都能准确地描述和把握。

这种方法的一般操作步骤有：●开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；●会后开发方整理出《需求调研记录》提交给客户方确认；●如果此主题还有未明确的问题则再次沟通，否则开始下一主题；●所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《客户需求列表》，提交给客户方确认签字。

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