软件需求工程的概念.ppt

《软件需求工程的概念.ppt》由会员分享，可在线阅读，更多相关《软件需求工程的概念.ppt（63页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、1.2 业界的当前状况界的当前状况根本某软件公司近五年的实践总结,在软件项目开发中的主要分类10种问题;总结的10种问题分类中需求过程占了30%;需求问题占了47%;635636总结问题总结问题分分类类问题分类问题分类数量数量比例比例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具体具体问题实例例我们不了解客户的配合工作执行情况，很难有机会与客户交流项目进度情况，存在沟通理解偏差沟通理解偏差的情况;前期需求方面加大力度，明确及确认各项需求边界，做好需求

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

4、体具体问题实例例没有受控的需求没有受控的需求,甚至需求还未完成的基础上就已开始了测试工作;一份与客户达成共识的需求需求规格格说明明书很重要很重要！售前工作方面提升的空间很大，包括与客户沟通、收集客户需求、编写方案、等等技术技能方面都比较欠缺，对行业领域内的专业知识还需要进一步的积累;639总结评估估说明大部分软件项目所遇到的问题是基本一致的;说明软件研发人员对所遇到的问题的认识是基本一致的;说明大多数软件项目的技术过程瓶颈是基本一致的;说明软件需求过程问题是当前项目研发中的主要过程技术瓶颈;63101.1.3 项目失目失败的根本原因的根本原因需求来源：市场需求主导不足不完整的需求缺乏用户介入不

5、实际的客户期望需求和规范的变更缺乏高层的支持胜任的团队成员大少缺乏项目管理经验631163121.1.4 相相对重要的重要的软件件问题一次调查以确定在产业中相对重要的软件问题,根据3800个被调查人的回答,大约半数的被调查者回答的两个最大问题是:1)需求规格说明 2)管理客户需求相对而言编码不是问题很显然,我们完全可以把需求当作导致软件问题的最根本原因。6313需求需求错误的的频率率缺陷来源缺陷来源潜在缺陷潜在缺陷排除的效率排除的效率提交的缺陷提交的缺陷需求1.0077%0.230.23设计1.2585%0.19编码1.7595%1.7595%0.09建档0.6080%0.12不恰当修复0.4

6、070%0.12合计5.0085%0.756314需求需求错误的的频率率需求错误在提交缺陷(用户着到的缺陷)中是最高的,占了大约全部提交缺陷的三分之一。因此需求错误是系统开发错误中最常见的一类错误。63151.1.5 需求需求错误的高昂代价的高昂代价 如果把编码阶段发现和修复一个错误所需要的努力用1个成本单元表示的话,那么需求阶段的错误修复成本是它的5到10倍。而且,在维护阶段发现和修复一个错误的成本超过20倍。在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例是200:16316在生命周期不同在生命周期不同阶段修复缺陷的相段修复缺陷的相对成本成本205210.50.1需求设计编

7、码单元测试验收测试维护6317结论需求错误可能是最常见的错误。需求错误可能是修改花费最昂贵的错误。需求错误可能消耗整个项目预算的25%到40%。给定需求错误的频率及其“修改成本”的倍增效果因子,可以预言,需求错误将占去返工成本的70%或更多。返工通常会消耗项目预算的30%到50%,因此得出:需求错误很容易就消耗掉整个项目预算的25%到40%!63181.1.6 软件需求的主要件需求的主要问题领域知域知识需求需求过程程需求方法需求方法需求技需求技术需求工具需求工具需求需求管理管理经验高高层管理的支持管理的支持胜任的任的团队成成员资金与金与时间6319软件需求的主要件需求的主要问题领域域知知识领域

8、域知知识需求需求过程程需求需求方法方法需求需求工具工具需求管理经验高层支持胜任的团队资金与时间需求需求技技术6320什么是好的需求什么是好的需求好的需求是正确的、无歧义的、可检验和可验证的并且是可跟踪的。好的需求集合是完整的、一致的和可修改的。(IEEE软件需求规格说明标准)6321对现代代软件需求的件需求的认识软件需求是领域知识的学习、经验积累的过程。软件需求是领域知识的传递过程。软件需求是在软件开发过程中迭代增量的认识过程。软件需求是不断变化的,我们要承认和适应这种变化,要学习适应软件变化的技术和方法。软件需求是软件开发过程中最关键的过程。6322软件需求工程的基本框架件需求工程的基本框架

9、6323软件需求工程的概念件需求工程的概念软件需求工程包括了以下主要内容：对软件需求基本知需求基本知识的学习和了解掌握一个基本的需求需求过程程熟练过程活动的方法和技方法和技术软件需求件需求过程的六个主要活程的六个主要活动软件需求过程包括需求开需求开发和需求管理需求管理两大类活动。需求开需求开发活活动需求获取需求分析需求定义需求管理活需求管理活动需求验证和确认需求跟踪需求变更控制63246325需求获取、需求分析、需求定义、需求验证变更控制、版本控制、需求跟踪、需求状态跟踪业务需求用户需求功能需求管理过程管理过程开发过程开发过程需求层次软件需求件需求规格格说明明需求属性功能需求非功能需求质量属性

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

11、求变更变更过程过程6329基本的基本的软件需求件需求过程程6330好的好的过程属性程属性过程被书面化过程是灵活的，可变的每个人都同意遵循这个过程过程包含度量，该度量用于测量过程的有效性度量是修改过程的基础过程被主动管理6331软件需求工程框架件需求工程框架我们把所有与软件需求相关的活动通称为软件需求工程件需求工程。需求工程中的活动可分为两大类:需求开需求开发需求管理需求管理6332需求开需求开发需求开需求开发包括三个知包括三个知识和和实践要点践要点:1.1.需求需求获取取2.2.需求分析需求分析3.3.需求定需求定义6333需求开需求开发需求开发可分为两个阶段：“用户需求需求调查阶段”和“产品

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

13、系、建档的系统方法方法,建立和建立和维护客客户和和项目目团队之之间关于关于变更系更系统需求所达成的一致性的需求所达成的一致性的过程程。6336需求管理需求管理任何曾经参与过复杂软件系统的人,无论是作为用户还是开发人员,都知道从用从用户和和风险承承担人那里担人那里获取需求的能力是非常关取需求的能力是非常关键的技能的技能;与一个系统相关的需求即使没有上千条,也至少有数百条,因此把它们合理地组织起来非常重要。我们无法记忆太多的信息,因此为需求建档能够有效支持风险承担人之间的沟通。必须把需求用可访问的介质来记录:文档,模型。6337需求管理需求管理需求管理与项目的大小和复杂度有关两个人、十条需求的项目

14、,不需要管理需求。但是,如果要验证一个有500-1000条需求的软件产品,我们就面临着必须对这些需求进行组织、划定优先级、控制对它们的访问以及为它们提供存储资源的问题。可以把需求管理看成处理重要的复杂项目需求的一系列理有组织的、标准化的、系统化的过程和技术。6338需求需求获取取需求分析需求分析需求定需求定义需求需求验证 需求跟踪需求跟踪设计编码测试变更控制更控制需求开需求开发需求管理需求管理软件需求工程的螺旋模型件需求工程的螺旋模型6339过程活程活动的方法和技的方法和技术需求获取的方法和技术发现(方法：角色、活动、资源、产品)收集(方法：用例、流程图)分类(方法：按活动、角色相关度)评估(

15、方法：风险、原因)优先级(方法：重要性、价值)文档(用户需求说明书)需求分析的方法和技术结构化分析方法和面向对象的基本方法(基于UML的用例分析技术)6340过程活程活动的方法和技的方法和技术需求定义的方法和技术(需求规格说明书)用例模型建模方法和用例补充规约说明需求验证和确认的方法和技术验证与评审和测试方法技术需求跟踪的方法和技术需求跟踪矩阵需求变更控制的方法和技术需求变更控制流程和变更控制委员会6341需求与其他需求与其他项目目过程的程的联系系 需求需求构造构造用用户编制文档制文档项目跟踪目跟踪和控制和控制制定制定项目目计划划系系统测试变更控制更控制状态范围基础参考估算基线6342需求工程

16、描述需求工程描述6343需求工程的用例需求工程的用例6344涉众涉众涉众是所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题，就会涉及到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。了解涉众的组成及其特定需要是开发有效解决方案的关键。6345风险承担者承担者风险承担者是高层需求的提出者，他们往往对需求细节不是很关心。系统的主要功能产生的作用及效益是他们关心的重点。注意系统风险承担者的宏观需求是有效解决问题

17、的关键和项目成功的保证之一。6346客客户客户有两种:系统的操作者和维护者，他们对系统的界面、易使用性、易维护性、稳定性比较关心。系统的用户，对系统的功能可以给他们带来的便利程度、舒适度、工作效率、工作满意度比较关心。6347领域域专家家领域专家具有丰富的业务领域经验，是系统业务流程、业务规则的提供者。领域专家是业务建模的主要角色。但是领域专家一般缺乏将业务模型转化为计算机逻辑模型的经验和能力。具有领域经验和计算机建模经验的专家是非常少的，两者的结合是需求成功的保证。6348变更控制更控制经理理变更控制经理负责对变更控制过程进行监督。此角色通常由配置（或变更）控制委员会(CCB)来担任，该委员

18、会应该由有关各方（包括客户、开发人员和用户）的代表组成。在小型项目中，项目经理或软件构架设计师一人即可承担此角色。6349系系统分析分析员系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才，但这些知识并不是所有人都必须具备的。63501.需求需求获取取需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。6351需求需求获取取需求获取本质上是一个涉及不同团体的交流过程。可分解为下列活动:

19、发现(方法：角色、活动、资源、产品)收集(方法：用例、流程图)分类(方法：按活动、角色相关度)评估(方法：风险、原因)优先级(方法：重要性、价值)文档：(用户需求说明书)63522.需求分析需求分析需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常用的需求分析方法有“结构化分析法”和“面向对象分析法”。面向对象分析法目前常用的方法是基于UML的用例分析技术,产品是用例模型。63533.需求定需求定义需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。6354需求开需求开发过程程产

20、生的主要文档生的主要文档用户需求说明书。产品需求规格说明书用例模型补充规约说明63554.需求需求验证和确和确认需求验证是指开发方和客户共同对需求文档进行评审，双方对需求达成共共识后做出书面承承诺，使需求文档具有商业合同效果。6356需求需求验证和确和确认需求验证是确保开发活动不断地符合客户需要的过程,验证主要是通过评审活动来完成的。需求确认活动是在软件开发后判断软件是否正确地实现了需求,需求确认主要是通过测试和测量活动来完成的。6357需求需求验证和确和确认63585.需求跟踪需求跟踪需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。63596.需求需求变更控制更控制需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。6360需求管理需求管理过程的主要文档程的主要文档需求评审报告需求跟踪报告需求变更控制报告6361需求文档之需求文档之间的关系的关系用户需求说明书产品需求规格说明书需求评审报告需求跟踪报告需求变更控制报告63626363END