软件需求工程的概念

1、编辑课件1软件需求工程的概念软件需求工程的概念2013.22013.2第7版 编辑课件2软件需求工程的概念软件需求工程的概念 对软件需求的认识 软件需求工程的基本框架 需求与其他项目过程的联系 需求工程描述编辑课件3对软件需求的认识对软件需求的认识编辑课件41.1 1.1 对软件需求的初级认识对软件需求的初级认识 需求不是根本问题，编码才是软件开发工作。 给我一个项目，无论需求多么复杂我一定能完成它。需求很重要，但很容易搞清它。 在初级软件开发人员的潜意识中需求不是那么可怕,编程技术才是重要的。 当这些问题与需求管理处理技能不足,缺乏管理工具，出现需求管理混现时才会逐渐引起项目管理者的重视。编

2、辑课件51.1.2 2 业界的当前状况业界的当前状况 根本某软件公司近五年的实践总结, 在软件项目开发中的主要分类10种问题; 总结的10种问题分类中需求过程占了30%30%; 需求问题占了47%47%;编辑课件6总结问题分类总结问题分类问题分类问题分类数量数量比例比例1需求获取447%47%2需求变更83需求控制44过程规范617.6%5项目管理26%6重用构件48.8%7售前12.9%8风险评估12.9%9技术风险12.9%10团队建设411.7%35编辑课件7具体问题实例具体问题实例 我们不了解客户的配合工作执行情况，很难有机会与客户交流项目进度情况，存在沟通理解偏差沟通理解偏差的情况;

3、 前期需求方面加大力度，明确及确认各项需求边界，做好需求变更控制需求变更控制; xx项目需求变更过大，不能有效控制不能有效控制; 频繁的人员变动及需求变更导致进度不断延迟; 需求没有在实际开发开展之前与客户需求没有在实际开发开展之前与客户达成共识达成共识; ;编辑课件8具体问题实例具体问题实例 总体感觉项目范围界限没有用需求规格说明书或者需求说明书规范，导致在系统设计、开发的过程中发现发现问题无据可查问题无据可查。 客户不断的提出修改要求,使最初的有序开发，逐步转变为疲于应付疲于应付客户新要求 面对需求频繁变更需求频繁变更给我们带来的许多不确定性的问题，目前没有太好的办法来解决。 客户方对自己

4、的需求并不清晰客户方对自己的需求并不清晰，开发项目过程受客户方影响过大，客户方在适用阶段才提出了不少的变更;编辑课件9具体问题实例具体问题实例 没有受控的需求没有受控的需求,甚至需求还未完成的基础上就已开始了测试工作; 一份与客户达成共识的需求规格说明书很重要需求规格说明书很重要！ 售前工作方面提升的空间很大，包括与客户沟通、收集客户需求、编写方案、等等技术技能方面都比较欠缺，对行业领域内的专业知识还需要进一步的积累;编辑课件10总结评估总结评估 说明大部分软件项目所遇到的问题是基本一致的; 说明软件研发人员对所遇到的问题的认识是基本一致的; 说明大多数软件项目的技术过程瓶颈是基本一致的; 说

5、明软件需求过程问题是当前项目研发中的主要过程技术瓶颈;编辑课件111.1.3 3 项目失败的根本原因项目失败的根本原因 需求来源：市场需求主导不足 不完整的需求 缺乏用户介入 不实际的客户期望 需求和规范的变更 缺乏高层的支持 胜任的团队成员大少 缺乏项目管理经验编辑课件121.1.4 4 相对重要的软件问题相对重要的软件问题 一次调查以确定在产业中相对重要的软件问题,根据3800个被调查人的回答,大约半数的被调查者回答的两个最大问题是: 1)需求规格说明 2)管理客户需求 相对而言编码不是问题 很显然,我们完全可以把需求当作导致软件问题的最根本原因。 编辑课件13需求错误的频率需求错误的频率

6、 缺陷来源缺陷来源 潜在缺陷潜在缺陷 排除的效率排除的效率 提交的缺陷提交的缺陷 需求 1.00 77% 0.230.23 设计 1.25 85% 0.19 编码 1.75 95%1.75 95% 0.09 建档 0.60 80% 0.12 不恰当修复 0.40 70% 0.12 合计 5.00 85% 0.75 编辑课件14需求错误的频率需求错误的频率 需求错误在提交缺陷(用户着到的缺陷)中是最高的,占了大约全部提交缺陷的三分之一。 因此需求错误是系统开发错误中最常见的一类错误。 编辑课件151.1.5 5 需求错误的高昂代价需求错误的高昂代价 如果把编码阶段发现和修复一个错误所需要的努力用

7、1个成本单元表示的话,那么需求阶段的错误修复成本是它的5到10倍。而且,在维护阶段发现和修复一个错误的成本超过20倍。 在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例是200:1 编辑课件16在生命周期不同阶段修复缺陷的相对成本在生命周期不同阶段修复缺陷的相对成本205210.50.1需求设计编码单元测试验收测试维护编辑课件17结论结论 需求错误可能是最常见的错误。 需求错误可能是修改花费最昂贵的错误。 需求错误可能消耗整个项目预算的25%到40%。 给定需求错误的频率及其“修改成本”的倍增效果因子,可以预言,需求错误将占去返工成本的70%或更多。 返工通常会消耗项目预算的3

8、0%到50%,因此得出:需求错误很容易就消耗掉整个项目预算的25%到40%! 编辑课件181.1.6 6 软件需求的主要问题软件需求的主要问题 领域知识领域知识 需求过程需求过程 需求方法需求方法 需求技术需求技术 需求工具需求工具 需求需求管理经验管理经验 高层管理的支持高层管理的支持 胜任的团队成员胜任的团队成员 资金与时间资金与时间编辑课件19软件需求的主要问题软件需求的主要问题领域领域知识知识领域领域知识知识需求需求过程过程需求需求方法方法需求需求工具工具需求管理经验高层支持胜任的团队资金与时间需求需求技术技术编辑课件20什么是好的需求什么是好的需求 好的需求是正确的、无歧义的、可检验

9、和可验证的并且是可跟踪的。 好的需求集合是完整的、一致的和可修改的。(IEEE软件需求规格说明标准)编辑课件21对现代软件需求的认识对现代软件需求的认识 软件需求是领域知识的学习、经验积累的过程。 软件需求是领域知识的传递过程。 软件需求是在软件开发过程中迭代增量的认识过程。 软件需求是不断变化的,我们要承认和适应这种变化,要学习适应软件变化的技术和方法。 软件需求是软件开发过程中最关键的过程。编辑课件22软件需求工程的基本框架软件需求工程的基本框架编辑课件23软件需求工程的概念软件需求工程的概念 软件需求工程包括了以下主要内容： 对软件需求基本知识需求基本知识的学习和了解 掌握一个基本的需求

10、过程需求过程 熟练过程活动的方法和技术方法和技术编辑课件24软件需求过程的六个主要活动软件需求过程的六个主要活动 软件需求过程包括需求开发需求开发和需求管理需求管理两大类活动。 需求开发活动需求开发活动 需求获取 需求分析 需求定义 需求管理活动需求管理活动 需求验证和确认 需求跟踪 需求变更控制编辑课件25需求获取、需求分析、需求定义、需求验证变更控制、版本控制、需求跟踪、需求状态跟踪业务需求 用户需求 功能需求管理过程管理过程开发过程开发过程需求层次软件需求规格说明软件需求规格说明需求属性 功能需求 非功能需求 质量属性管理过程产品开发过程产品软件需求工程的基本框架软件需求工程的基本框架编

11、辑课件26需求处理过程的生命周期需求处理过程的生命周期 需求处理过程系统分析产品设计构建实现产品使用需求规格需求规格说明书说明书风险承担者的 想法与需要目标操作环境反馈反馈编辑课件27软件需求过程软件需求过程 软件需求过程包括需求开发和需求管理两大类活动。 需求开发活动需求开发活动需求获取、需求分析、需求定义 需求管理活动需求管理活动 需求验证和确认、需求跟踪、需求变更控制编辑课件28需求开发与需求管理之间的界限需求开发与需求管理之间的界限 需求规格说明基线需求规格说明基线 需求开发需求开发需求管理需求管理获取获取分析分析定义定义变更变更 当前基线修正后基线修正后基线需求需求变更变更过程过程编

12、辑课件29基本的软件需求过程基本的软件需求过程 编辑课件30好的过程属性好的过程属性 过程被书面化 过程是灵活的，可变的 每个人都同意遵循这个过程 过程包含度量，该度量用于测量过程的有效性 度量是修改过程的基础 过程被主动管理编辑课件31软件需求工程框架软件需求工程框架 我们把所有与软件需求相关的活动通称为软件需求工程软件需求工程。 需求工程中的活动可分为两大类: 需求开发需求开发 需求管理需求管理 编辑课件32需求开发需求开发 需求开发包括三个知需求开发包括三个知识和实践要点识和实践要点: :1.1.需求获取需求获取2.2.需求分析需求分析3.3.需求定义需求定义编辑课件33需求开发需求开发

13、 需求开发可分为两个阶段：“用户需求需求调查调查阶段”和“产品需求定义需求定义阶段”，“需求分析需求分析”则贯穿于上述两个阶段。 需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（系统分析员） 编辑课件34需求管理需求管理 需求管理包括三个知需求管理包括三个知识和实践要点识和实践要点1.需求验证和确认2.需求跟踪3.需求变更控制编辑课件35什么是需求管理什么是需求管理 需求定义了系统必须具有的能力,一个项目的成功与否往往取决于它是否符合一系列的需求。因此,探讨需求的确切含义、把它们写下来、组织起来、跟踪它们的变更就显得非

14、常有意义。 需求管理定义为需求管理定义为: :为系统的需求进行启发、组为系统的需求进行启发、组织、建档的系统方法织、建档的系统方法, ,建立和维护客户和项目建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的团队之间关于变更系统需求所达成的一致性的过程过程。 编辑课件36需求管理需求管理 任何曾经参与过复杂软件系统的人,无论是作为用户还是开发人员,都知道从用户和风险承从用户和风险承担人那里获取需求的能力是非常关键的技能担人那里获取需求的能力是非常关键的技能; ; 与一个系统相关的需求即使没有上千条,也至少有数百条,因此把它们合理地组织起来非常重要。 我们无法记忆太多的信息,因此为需求建

15、档能够有效支持风险承担人之间的沟通。 必须把需求用可访问的介质来记录:文档,模型。 编辑课件37需求管理需求管理 需求管理与项目的大小和复杂度有关 两个人、十条需求的项目,不需要管理需求。但是,如果要验证一个有500-1000条需求的软件产品,我们就面临着必须对这些需求进行组织、划定优先级、控制对它们的访问以及为它们提供存储资源的问题。 可以把需求管理看成处理重要的复杂项目需求的一系列理有组织的、标准化的、系统化的过程和技术。 编辑课件38需求获取需求获取需求分析需求分析需求定义需求定义需求验证需求验证 需求跟踪需求跟踪设计编码测试设计编码测试变更控制变更控制需求开发需求开发需求管理需求管理软

16、件需求工程的螺旋模型软件需求工程的螺旋模型编辑课件39过程活动的方法和技术过程活动的方法和技术 需求获取的方法和技术 发现(方法：角色、活动、资源、产品) 收集(方法：用例、流程图) 分类(方法：按活动、角色相关度) 评估(方法：风险、原因) 优先级(方法：重要性、价值) 文档(用户需求说明书) 需求分析的方法和技术 结构化分析方法和面向对象的基本方法(基于UML的用例分析技术)编辑课件40过程活动的方法和技术过程活动的方法和技术 需求定义的方法和技术(需求规格说明书) 用例模型建模方法和用例补充规约说明 需求验证和确认的方法和技术 验证与评审和测试方法技术 需求跟踪的方法和技术 需求跟踪矩阵

17、 需求变更控制的方法和技术 需求变更控制流程和变更控制委员会编辑课件41需求与其他项目过程的联系需求与其他项目过程的联系 需求需求构造构造用户编用户编制文档制文档项目跟踪项目跟踪和控制和控制制定项制定项目计划目计划系统测试系统测试变更控制变更控制状态范围基础参考估算基线编辑课件42需求工程描述需求工程描述编辑课件43需求工程的用例需求工程的用例编辑课件44涉众涉众 涉众是所有会受到项目结果重大影响的人。 要有效地解决任何复杂的问题，就会涉及到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。 许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，

18、或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。 了解涉众的组成及其特定需要是开发有效解决方案的关键。编辑课件45风险承担者风险承担者 风险承担者是高层需求的提出者，他们往往对需求细节不是很关心。 系统的主要功能产生的作用及效益是他们关心的重点。 注意系统风险承担者的宏观需求是有效解决问题的关键和项目成功的保证之一。编辑课件46客户客户 客户有两种: 系统的操作者和维护者，他们对系统的界面、易使用性、易维护性、稳定性比较关心。 系统的用户，对系统的功能可以给他们带来的便利程度、舒适度、工作效率、工作满意度比较关心。编辑课件47领域专家领域专家 领域专家具有丰富的业

19、务领域经验，是系统业务流程、业务规则的提供者。 领域专家是业务建模的主要角色。 但是领域专家一般缺乏将业务模型转化为计算机逻辑模型的经验和能力。 具有领域经验和计算机建模经验的专家是非常少的，两者的结合是需求成功的保证。编辑课件48变更控制经理变更控制经理 变更控制经理负责对变更控制过程进行监督。 此角色通常由配置（或变更）控制委员会 (CCB) 来担任，该委员会应该由有关各方（包括客户、开发人员和用户）的代表组成。 在小型项目中，项目经理或软件构架设计师一人即可承担此角色。 编辑课件49系统分析员系统分析员 系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在

20、哪些主角和用例，以及他们之间如何交互。 担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才，但这些知识并不是所有人都必须具备的。 编辑课件501.1.需求获取需求获取 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。编辑课件51需求获取需求获取 需求获取本质上是一个涉及不同团体的交流过程。可分解为下列活动: 发现(方法：角色、活动、资源、产品) 收集(方法：用例、流程图) 分类(方法：按活动、角色相关度) 评估(方法：风险、原因) 优先级(方法：重要性、价值) 文档：(用户需求说明书)编辑课件522. 2. 需求分析需求分析 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。 常用的需求分析方法有 “结构化分析法”和“面向对象分析法”。 面向对象分析法目前常用的方法是基于UML的用例分析技术,产品是用例模型