CMMI需求开发指南

CMMI需求开发指南 文档编号：COSHIP-CMMI-GDL-RD 密级：机密 版本信息：V1.0 批准日期： 编辑软件：MS Office Word2003 SP2，MS Office Visio2003 SP2 同洲电子股份有限公司    版权所有 内部资料 注意保密 文档修订记录 序号 版本号 变化状态 变更（+/-）说明 作者 日期 1 0.1 C 创建 蒋小东 2007-7-18 2 0.2 A、M 增强与完善内容 蒋小东 2007-7-26 3 1.0 A、M 根据评审意见和建议修订 蒋小东 2007-8-2                                                                         *变化状态：C――创建，A——增加，M——修改，D——删除 文档审批信息 版本 过程改进组（EPG）审核 会签 批 准 备 注 1.0                             目 录 文档修订记录    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)文档或 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 脚本说明中予以说明。 产品需求：定义了开发人员必须实现的产品功能，使得用户能完成他们的任务，从而满足业务需求。 特性：是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 1.4 参考资料 《PRC-需求开发过程》 《PRC-需求管理过程》 《PRC-评审管理过程》 《PRD-技术评审 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 》 《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）需求(收集需求)过程中始终有一位项目开发组的成员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。 ● 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。 ● 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。 ● 无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 ● 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。 3 需求获取 需求获取是一个确定和理解不同客户和用户的需要和约束的过程。需求获取主要通过与客户和用户的交流开发、捕获和修订客户和用户的需求。 项目任务书下达后，项目经理组织进行有目标的需求获取活动。需求获取主要通过调研活动完成，需求获取的工作产品可能有调研报告、调研备忘录或非正式的邮件等。调研活动要求制定 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 ，按计划进行。 3.1 需求获取原则 定义客户的需求就是指通过与客户的长期沟通，对客户购买产品的欲望、用途、功能、款式进行逐渐发掘，将客户心里模糊的认识以精确的方式描述并展示出来的过程。 当然，在进行客户需求定义是要注意从不同的角度和侧面来分析，具体为遵循以下几个原则： ● 全面性原则　对于任何已被列入客户范畴的消费者，我们要全面的定义其几乎所有的需求，全面掌握客户在应用中对于各种产品的需求强度和满足状况。之所以要全 面了解，是要让客户应用中的需要完整地体现出来，而且根据客户的全面需要分析其使用习惯、消费偏好、购买能力等相关因素。 ● 突出性原则　项目的目标是帮助客户满足需求，为公司赢得利润。所以，要突出产品和客户需求的结合点，清晰的定义出客户的需求，从而实现双赢。 ● 深入性原则　沟通不能肤浅，否则只能是空谈。对客户需求的定义同样如此，只有 深入的了解客户应用的各个环节，才会发现其对产品拥有的真正需求。也就是说，要对客户的需求做出清晰的定义，事前工作的深入性是必不可少的。 ● 广泛性原则　广泛性原则不是对某一个特定客户需求定义时的要求，而是要求销售人员在于客户沟通是要了解所有接触客户的需求状况，学会对比分析，差异化的准备自己的相关工具和说服方法。 ● 建议性原则　客户不是我们的下属，所以命令他们是不会接受的，当然我们也不可能这么做。在客户需求的定义过程中同样如此，客户所认同的观念跟我们或多或少的存在一些差异，所以对客户的需求要进行定义只能是“我们认为您的需求是……，您认同吗？” 3.2 需求获取任务 需求获取主要的任务有： ● 编写项目视图和范围文档。项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。具体操作中可在立项报告中体现。