1、63,1,软件需求工程的概念,北京航空航天大学软件工程研究所 罗燕京 2013.2第7版Luo_,63,2,软件需求工程的概念,对软件需求的认识 软件需求工程的基本框架 需求与其他项目过程的联系 需求工程描述,63,3,对软件需求的认识,63,4,1.1 对软件需求的初级认识,需求不是根本问题，编码才是软件开发工作。 给我一个项目，无论需求多么复杂我一定能完成它。需求很重要，但很容易搞清它。 在初级软件开发人员的潜意识中需求不是那么可怕,编程技术才是重要的。 当这些问题与需求管理处理技能不足,缺乏管理工具，出现需求管理混现时才会逐渐引起项目管理者的重视。,1.2 业界的当前状况,根本某软件公司
2、近五年的实践总结, 在软件项目开发中的主要分类10种问题; 总结的10种问题分类中需求过程占了30%; 需求问题占了47%;,63,5,63,6,具体问题实例,我们不了解客户的配合工作执行情况，很难有机会与客户交流项目进度情况，存在沟通理解偏差的情况; 前期需求方面加大力度，明确及确认各项需求边界，做好需求变更控制; xx项目需求变更过大，不能有效控制; 频繁的人员变动及需求变更导致进度不断延迟; 需求没有在实际开发开展之前与客户达成共识;,63,7,具体问题实例,总体感觉项目范围界限没有用需求规格说明书或者需求说明书规范，导致在系统设计、开发的过程中发现问题无据可查。 客户不断的提出修改要求
3、,使最初的有序开发，逐步转变为疲于应付客户新要求 面对需求频繁变更给我们带来的许多不确定性的问题，目前没有太好的办法来解决。 客户方对自己的需求并不清晰，开发项目过程受客户方影响过大，客户方在适用阶段才提出了不少的变更;,63,8,具体问题实例,没有受控的需求,甚至需求还未完成的基础上就已开始了测试工作; 一份与客户达成共识的需求规格说明书很重要！ 售前工作方面提升的空间很大，包括与客户沟通、收集客户需求、编写方案、等等技术技能方面都比较欠缺，对行业领域内的专业知识还需要进一步的积累;,63,9,总结评估,说明大部分软件项目所遇到的问题是基本一致的; 说明软件研发人员对所遇到的问题的认识是基本
4、一致的; 说明大多数软件项目的技术过程瓶颈是基本一致的; 说明软件需求过程问题是当前项目研发中的主要过程技术瓶颈;,63,10,1.3 项目失败的根本原因,需求来源：市场需求主导不足 不完整的需求 缺乏用户介入 不实际的客户期望 需求和规范的变更 缺乏高层的支持 胜任的团队成员大少 缺乏项目管理经验,63,11,63,12,1.4 相对重要的软件问题,一次调查以确定在产业中相对重要的软件问题,根据3800个被调查人的回答,大约半数的被调查者回答的两个最大问题是:1)需求规格说明2)管理客户需求 相对而言编码“不是问题“ 很显然,我们完全可以把需求当作导致软件问题的最根本原因。,63,13,需求
5、错误的频率,缺陷来源 潜在缺陷 排除的效率 提交的缺陷 需求 1.00 77% 0.23 设计 1.25 85% 0.19 编码 1.75 95% 0.09 建档 0.60 80% 0.12 不恰当修复 0.40 70% 0.12 合计 5.00 85% 0.75,63,14,需求错误的频率,需求错误在提交缺陷(用户着到的缺陷)中是最高的,占了大约全部提交缺陷的三分之一。 因此需求错误是系统开发错误中最常见的一类错误。,63,15,1.5 需求错误的高昂代价,如果把编码阶段发现和修复一个错误所需要的努力用1个成本单元表示的话,那么需求阶段的错误修复成本是它的5到10倍。而且,在维护阶段发现和修
6、复一个错误的成本超过20倍。 在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例是200:1,63,16,在生命周期不同阶段修复缺陷的相对成本,20,5,2,1,0.5,0.1,需求,设计,编码,单元测试,验收测试,维护,63,17,结论,需求错误可能是最常见的错误。 需求错误可能是修改花费最昂贵的错误。 需求错误可能消耗整个项目预算的25%到40%。 给定需求错误的频率及其“修改成本”的倍增效果因子,可以预言,需求错误将占去返工成本的70%或更多。 返工通常会消耗项目预算的30%到50%,因此得出:需求错误很容易就消耗掉整个项目预算的25%到40%!,63,18,1.6 软件需
7、求的主要问题,领域知识 需求过程 需求方法 需求技术 需求工具 需求管理经验 高层管理的支持 胜任的团队成员 资金与时间,63,19,软件需求的主要问题,63,20,什么是好的需求,好的需求是正确的、无歧义的、可检验和可验证的并且是可跟踪的。 好的需求集合是完整的、一致的和可修改的。(IEEE软件需求规格说明标准),63,21,对现代软件需求的认识,软件需求是领域知识的学习、经验积累的过程。 软件需求是领域知识的传递过程。 软件需求是在软件开发过程中迭代增量的认识过程。 软件需求是不断变化的,我们要承认和适应这种变化,要学习适应软件变化的技术和方法。 软件需求是软件开发过程中最关键的过程。,6
8、3,22,软件需求工程的基本框架,63,23,软件需求工程的概念,软件需求工程包括了以下主要内容： 对软件需求基本知识的学习和了解 掌握一个基本的需求过程 熟练过程活动的方法和技术,软件需求过程的六个主要活动,软件需求过程包括需求开发和需求管理两大类活动。 需求开发活动 需求获取 需求分析 需求定义 需求管理活动 需求验证和确认 需求跟踪 需求变更控制,63,24,63,25,开发过程产品,软件需求工程的基本框架,63,26,需求处理过程的生命周期,63,27,软件需求过程,软件需求过程包括需求开发和需求管理两大类活动。 需求开发活动 需求获取、需求分析、需求定义 需求管理活动 需求验证和确认
9、、需求跟踪、需求变更控制,63,28,需求开发与需求管理之间的界限,63,29,基本的软件需求过程,63,30,好的过程属性,过程被书面化 过程是灵活的，可变的 每个人都同意遵循这个过程 过程包含度量，该度量用于测量过程的有效性 度量是修改过程的基础 过程被主动管理,63,31,软件需求工程框架,我们把所有与软件需求相关的活动通称为软件需求工程。 需求工程中的活动可分为两大类: 需求开发 需求管理,63,32,需求开发,需求开发包括三个知识和实践要点: 1.需求获取 2.需求分析 3.需求定义,63,33,需求开发,需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”，“需求分析
10、”则贯穿于上述两个阶段。 需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（系统分析员）,63,34,需求管理,需求管理包括三个知识和实践要点 1.需求验证和确认 2.需求跟踪 3.需求变更控制,63,35,什么是需求管理,需求定义了系统必须具有的能力,一个项目的成功与否往往取决于它是否符合一系列的需求。因此,探讨需求的确切含义、把它们写下来、组织起来、跟踪它们的变更就显得非常有意义。 需求管理定义为:为系统的需求进行启发、组织、建档的系统方法,建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。,63,3
11、6,需求管理,任何曾经参与过复杂软件系统的人,无论是作为用户还是开发人员,都知道从用户和风险承担人那里获取需求的能力是非常关键的技能; 与一个系统相关的需求即使没有上千条,也至少有数百条,因此把它们合理地组织起来非常重要。 我们无法记忆太多的信息,因此为需求建档能够有效支持风险承担人之间的沟通。 必须把需求用可访问的介质来记录:文档,模型。,63,37,需求管理,需求管理与项目的大小和复杂度有关 两个人、十条需求的项目,不需要管理需求。但是,如果要验证一个有500-1000条需求的软件产品,我们就面临着必须对这些需求进行组织、划定优先级、控制对它们的访问以及为它们提供存储资源的问题。 可以把需
12、求管理看成处理重要的复杂项目需求的一系列理有组织的、标准化的、系统化的过程和技术。,63,38,软件需求工程的螺旋模型,63,39,过程活动的方法和技术,需求获取的方法和技术 发现(方法：角色、活动、资源、产品) 收集(方法：用例、流程图) 分类(方法：按活动、角色相关度) 评估(方法：风险、原因) 优先级(方法：重要性、价值) 文档(用户需求说明书) 需求分析的方法和技术 结构化分析方法和面向对象的基本方法(基于UML的用例分析技术),63,40,过程活动的方法和技术,需求定义的方法和技术(需求规格说明书) 用例模型建模方法和用例补充规约说明 需求验证和确认的方法和技术 验证与评审和测试方法
13、技术 需求跟踪的方法和技术 需求跟踪矩阵 需求变更控制的方法和技术 需求变更控制流程和变更控制委员会,63,41,需求与其他项目过程的联系,63,42,需求工程描述,63,43,需求工程的用例,63,44,涉众,涉众是所有会受到项目结果重大影响的人。 要有效地解决任何复杂的问题，就会涉及到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。 许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。 了解涉众的组成及其特定需要是开发有效解决方案的关键。,63,45,风险承担者
14、,风险承担者是高层需求的提出者，他们往往对需求细节不是很关心。 系统的主要功能产生的作用及效益是他们关心的重点。 注意系统风险承担者的宏观需求是有效解决问题的关键和项目成功的保证之一。,63,46,客户,客户有两种: 系统的操作者和维护者，他们对系统的界面、易使用性、易维护性、稳定性比较关心。 系统的用户，对系统的功能可以给他们带来的便利程度、舒适度、工作效率、工作满意度比较关心。,63,47,领域专家,领域专家具有丰富的业务领域经验，是系统业务流程、业务规则的提供者。 领域专家是业务建模的主要角色。 但是领域专家一般缺乏将业务模型转化为计算机逻辑模型的经验和能力。 具有领域经验和计算机建模经
15、验的专家是非常少的，两者的结合是需求成功的保证。,63,48,变更控制经理,变更控制经理负责对变更控制过程进行监督。 此角色通常由配置（或变更）控制委员会 (CCB) 来担任，该委员会应该由有关各方（包括客户、开发人员和用户）的代表组成。 在小型项目中，项目经理或软件构架设计师一人即可承担此角色。,63,49,系统分析员,系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。 担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才，但这些知识并不是所有人都必须具备的。,
16、63,50,1.需求获取,需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。,63,51,需求获取,需求获取本质上是一个涉及不同团体的交流过程。可分解为下列活动: 发现(方法：角色、活动、资源、产品) 收集(方法：用例、流程图) 分类(方法：按活动、角色相关度) 评估(方法：风险、原因) 优先级(方法：重要性、价值) 文档：(用户需求说明书),63,52,2. 需求分析,需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。 常用的需求分析方法有 “结构化分析法”和“面向对象分析法”。 面向对象分析法目前常用的方法是基于UML的用例分析技术,产品是用例模型
17、。,63,53,3. 需求定义,需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。 系统设计人员将依据产品需求规格说明书开展系统设计工作。,63,54,需求开发过程产生的主要文档,用户需求说明书。 产品需求规格说明书 用例模型 补充规约说明,63,55,4. 需求验证和确认,需求验证是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,63,56,需求验证和确认,需求验证是确保开发活动不断地符合客户需要的过程,验证主要是通过评审活动来完成的。 需求确认活动是在软件开发后判断软件是否正确地实现了需
18、求,需求确认主要是通过测试和测量活动来完成的。,63,57,需求验证和确认,63,58,5. 需求跟踪,需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。,63,59,6. 需求变更控制,需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。,63,60,需求管理过程的主要文档,需求评审报告 需求跟踪报告 需求变更控制报告,63,61,需求文档之间的关系,用户需求说明书 产品需求规格说明书 需求评审报告 需求跟踪报告 需求变更控制报告,63,62,63,63,END,
