需求工程概述.ppt

《需求工程概述.ppt》由会员分享，可在线阅读，更多相关《需求工程概述.ppt（49页珍藏版）》请在三一办公上搜索。

1、软件需求工程,讲授人：游静课时：48学时,参考教材,毋国庆等，软件需求工程（第2版），机械工业出版社，2013黄国兴等，软件需求工程，清华大学出版社，2008于向东等，软件需求开发最佳实践，清华大学出版社，2014霍雁等，软件需求工程，科学出版社，2012,软件开发的目标,软件开发的目标，简单而言，就是满足用户的需要。谁能准确地说出用户需要什么？客户？用户？开发者？,一些基本概念,用户（user）。利用计算机系统所提供的服务的人（们）；直接操作计算机系统的人（们），简单地说，就是直接使用软件系统的人（们）。客户（customer）。掌握经费的人（们），通常由他（们）决定软件需求，客户可以是用户

2、，也可以不是用户。正式接收新开发或修改后的硬件和软件系统的某个（些）人或组织。,一些基本概念,软件开发人员（supplier）。为客户开发软件系统的人。项目相关人员（stakeholder）。指与提出和定义软件需求相关的人，其包括所有的用户、客户、系统分析人员和软件开发人员。这些人都是软件需求的来源，只是他们站在不同的立场看待将要开发的软件系统。,0 软件开发过程模型（回顾）,瀑布式模型快速原型模型 渐增式模型 螺旋式模型 面向对象的开发模型,瀑布式模型,要求用户一开始就提出清晰完整的需求,用户的参与程度不够,瀑布式模型不足,（1）由于开发模型是线性的，要求用户一开始就提出清晰完整的需求；（早

3、期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果）（2）段间移交信息（文档）的过程中，由于个人的理解不同，容易产生误解；（3）用户的参与程度不够。,快速原型模型,明确并完善需求,快速原型模型优点和不足,优点：（1）能弥补瀑布模型中用户参与程度不够等不足；用户可以充分地参与到软件开发中；（2）能减少用户需求的遗漏以及（在软件开发后期）用户频繁修改需求的可能性；（4）快速。减少开发周期，降低成本。不足：（1）用户易于视原型为正式产品；（2）快速原型系统对于软件系统的开发环境要求较多，在一定程度上也影响了其使用的范围和实用价值。（3）对于难以被模块化的系统不适用。,渐增式模型,必须在

4、实现各个构件之前就全部完成需求分析和概要设计工作。,螺旋式模型,将瀑布式模型与快速原型模型结合到一起，并加上风险分析。理解这种模型的一个简便方法是把它看作在每个阶段之前都增加风险分析。,复杂,螺旋式模型,成本高,经验要求高,面向对象的开发模型,所谓面向对象就是应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作为运行机制的一种问题求解方法。,面向对象的开发模型,特点（1）有一部分分析工作必须在设计之前进行，而另外一些分析工作则需与其他部分的设计与实现工作并行地进行，因而呈现出非线性的工作

5、方式。（2）软件系统的表达形式在整个开发模型中都是相同的，即面向对象方法中把类及其结构作为系统的表达单元，无论哪一个阶段都以渐增的方式不断地进化或细化这些表达单元。（3）开发模型支持软件的重用。,客户,开发人员,我们要建立一套完整的商业管理软件系统。,ok,详细谈谈您想要它做什么？,可以完成商品的进、销、存管理，是总店/门店的连锁经营模式。实现门店自动订货、供应商自动结算、卖场扫描条形码进行销售，管理人员可查询销售情况和库存。,好的。我已经明白这个项目的大体框架，但在制订计划之前，我们必须先来收集一些需求。,我不是刚告诉你我的需求了吗？,您只说明了项目的概念和目标。我们需要和使用系统的业务人员

6、进行讨论，才能了解真正的功能要求。,业务人员都很忙！他们没有时间！你们可以先开发一个系统或说明一下你们现有的系统。,如果我们凭空猜想用户的需求来开发系统，结果不会让人满意。我们不是采购专家和财务专家，并不真正明白您企业内部运营需要做什么。,行了行了，我没有那么多时间。按我告诉你的需求开发吧，马上开始，并随时将进展情况告诉我。,需求是制定项目计划的基础,冰山模型,美国著名心理学家麦克利兰于1973年提出了一个著名的素质冰山模型。所谓“冰山模型”，就是将人员个体素质的不同表现形式划分为表面的“冰山以上部分”和深藏的“冰山以下部分”。其中，“冰山以上部分”包括基本知识、基本技能，是外在表现，是容易了

7、解与测量的部分，相对而言也比较容易通过培训来改变和发展。而“冰山以下部分”包括社会角色、自我形象、特质和动机，是人内在的、难以测量的部分。它们不太容易通过外界的影响而得到改变，但却对人员的行为与表现起着关键性的作用。,第一章需求工程概述,1.1什么是软件需求1.2软件需求的分类1.3需求分析的重要性1.4需求规格说明1.5需求工程1.6需求工程面临的困难,1.1什么是软件需求,软件需求的各种定义（1）A.Davis认为：软件需求是从软件外部能发现的，软件所具有的，满足于用户的特点、功能及属性等的集合。（2）I.Sommerville认为：需求是问题信息和系统行为、特性、设计和实现约束的描述的集

8、合。（3）M.Jackson等人认为：需求是客户希望在问题域内产生的效果。,1.1什么是软件需求,IEEE关于软件需求的定义（1）用户解决问题或达到目标所需的条件或能力；（用户的角度）（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（软件系统的角度）,软件需求是指软件系统必须满足的所有功能、性质和限制。,1.2软件需求的分类,软件需求的分类（1）目标需求；（2）业务需求；（3）功能需求；（4）性能需求（非功能需求）；（5）约束与限制。,反映组织或客户对系统和产品提出的高层次的目标要求，其限定了项目的范围和应达到的目标。,描述软件系统完成的任务、实际业务或工作流

9、程等,指开发人员必须实现的软件功能或软件系统应具体的外部行为,实现的软件系统功能应达到的技术指标，如计算效率和精度、可靠性、可维护性和可扩展性等,软件开发人员在设计和实现软件系统时的限制，如开发语言、使用的数据库等,1.2软件需求的分类,软件需求间的层次关系,1.2软件需求的分类,示例：文字处理系统相关需求,用户使用系统能有效地纠正文档中的拼写错误，并且系统能满足用户的业务要求以及提高用户的工作效率。,目标需求,当找到文档中的拼写错误时，通过一个可供选择的单词表，并在选择单词表中的某一个单词后替换掉原来的单词。,业务需求,查找文档中的单词，并高亮度地显示出错的单词。用对话框显示可供选择的单词表

10、。实现整个文档范围内的替换。,功能需求,检查单词的速度快，准确率要求达到99，系统的有效性和可靠性要高等。,非功能需求,文件内部格式要与word系统一致。开发平台为Linux系统，以及使用C语言等。,约束与限制,1.3需求分析的重要性,系统分析员在项目中的作用,1.3需求分析的重要性,1.3需求分析的重要性,1994年：31.1%的项目完成之前被取消；52.7的项目实际花费超预算189%。1999年：26%的项目成功，28%的项目是彻底失败，46%的项目存在费用超支、超出工期的问题。2003年：在被调查的1.35万个项目中，34%成功，15%失败，51%受到质疑。,Standish集团公司的研

11、究报告：,1.3需求分析的重要性,项目失败或严重超支的8个最重要原因中有5个都与需求相关：不完整的需求；缺乏用户的参与；不实际的客户期望；需求和需求规格说明的变更；提供许多不必要的功能。,三种最经常使项目遇到困难的因素,需求错误的代价,在生命周期的不同阶段修复缺陷的相对成本,Davis A.M.研究发现，在需求阶段检查和修复一个错误所需的费用只有编码阶段的1/5到1/10，而在维护阶段做同样的工作所需付出的代价却是编码阶段的20倍,必须极早有效地发现和解决与需求相关的问题,需求缺陷造成的成本增加,重新进行需求规格说明重新设计、重新编码、重新测试改变订单告诉用户将以一个修正后的版本来替代有缺陷的

12、版本。纠正活动消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。报废包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。收回有缺陷的软件产品以及相关的用户手册。产品赔偿或保修的成本。重新安装新版本的成本。重新建档的成本。,高质量的需求过程带来的好处,在开发后期和整个维护阶段的重做的工作大大减少了。让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系。用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。有效的变更控制也能

13、降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量。,1.4需求规格说明,需求规格说明需求规格说明是软件所应满足的全部需求，并可以文档的方式完整和精确陈述这些需求。重要性需求规格说明是项目相关人员对将要开发的软件系统所达成的共识，是进行系统设计、实现、测试和验收的基本依据，也是整个软件开发过程中最重要的文档。,1.4需求规格说明,内容需求规格说明应精确地描述一个软件系统必须提供的功能和性能，以及所要考虑的约束条件与限制。编写方法需求规格说明也可以说是在1.2节中所定义的所有软件需求的集成，并使用某种描述语言如自然语言按照规定的书写格式编写的文档。

14、,1.4需求规格说明,一个好的需求规格说明应该具有的特征：,完整性,正确性,可行性,必要性,划分优先级,无二义性,可验证性,可跟踪性,确定性,1.5需求工程,需求工程 需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需求。目的要获取高质量的软件需求。,最终产物需求规格说明,1.5需求工程,任务 确定待开发的软件系统的用户类，并获取他们的需求信息。分析用户的需求信息，并按软件需求的类型分类这些需求信息，同时也区别出不是需求的信息。根据软件需求信息建立软件系统的逻辑模型或需求模型，并确认非功能需求和约束条件及限制。根据收集的需求信息和逻辑模型编写需求规格说明及其文档。评审需求规格说明。当

15、需求发生变更时，对需求规格说明及需求变更实施进行管理。,软件需求的开发和管理过程,软件需求的开发和管理过程是由导出、确认和维护软件系统需求规格说明的一系列活动组成的。根据需求工程开发和管理过程可大致划分需求开发和需求管理两个阶段。其中需求开发主要产生正式的需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。,软件需求的开发和管理过程,软件需求的开发和管理过程,需求工程过程可进一步划分为若干阶段。,需求开发过程的主要任务,（1）需求获取：确定和收集与软件系统相关的、来自不同来源和对象的用户需求信息。（2）需求分析：对获得的用户需求信息进行分析和综合，即提炼、分析和仔细审

16、查已收集到的用户需求信息，并找出其中的错误、遗漏或其它不足的地方，以获得用户对软件系统的真正需求，建立软件系统的逻辑模型（或需求模型）。（3）需求定义：使用适当的描述语言，按标准的格式描述软件系统的需求，并产生需求规格说明及其相应文档。（4）需求验证：审查和验证需求规格说明是否正确和完整地表达了用户对软件系统的需求。,需求管理过程的任务,有效地管理软件系统的需求规格说明及其相应文档，评估需求变更带来的潜在影响及可能的成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。,需求工程的内容,1.6 需求工程面临的困难,需求获取与需求分析的困难性（1）有些需求可能用户也不是很清楚；（2）需要用户与

17、开发人间进行充分的交流和协商；（3）需求间的冲突和矛盾的检查以及解决；（4）需求是否完整和确定；（5）合适的需求建模的方法和技术。,1.6 需求工程面临的困难,需求描述语言和规范化的困难性（1）怎样规范化用户需求；（2）规范化哪些用户需求；（3）非形式化和形式化描述语言的使用。,1.6 需求工程面临的困难,需求验证的困难性（1）需求规格说明正确性的确认和验证；（2）验证的方法和技术；（3）如何进行自动验证。,1.6 需求工程面临的困难,需求管理的困难性（1）需求规格说明书的质量保证；（2）需求规格说明书的版本管理；（3）需求变更的控制。,The Standish Group,美国专门从事跟踪I

18、T项目成功或失败的权威机构，它每年发布CHAOS Report。报告中给出全美IT项目相关调查数据结果。从历年的Standish Group报告分析看,导致项目失败的最重要原因与需求有关.Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理,也就是项目的范围管理,特别是管理好项目的变更.,歧义示例：,需求：系统只允许保留5个有效的相关记录和保障计划，它必须包括最新的。,最新的相关记录？,最新的保障计划？,总数5个？各5个？,修改为：系统只允许5个有效的相关记录最新的相关记录一定包含在上述相关记录中每个保障计划都被放在其相关记录中,不确定需求示例,需

19、求：系统1应该每隔5分钟向系统2发送一次新记录。,5分钟内没有收到新记录怎么办？,修改为：如果自上次向系统2发送消息以来，5分钟内收到了新消息，则系统1向系统2发送新记录。,如果在上述5分钟内没有收到了新消息，则系统1什么都不做。,完整性：应将所有要实现的需求都描述清楚。需求的遗漏更多地由于用户的原因，而后的修正却给开发人员带来极大的困难。（注重用户的任务而不是系统的功能将有助于避免不完整性）正确性：准确地描述系统必须提供的功能。由用户确定，需要将用户需求有效地映入到软件需求。可行性：每一项需求必须在已知系统和环境的限制范围内可以实施。（在获取需求过程中始终有一位软件开发小组的技术人员参与）。必要性：每项需求都是真正来源于用户的实际需要。都能回溯至某项客户的输入。划分优先级：不能把所有需求看做同等重要，会在调度中丧失自由度。无二义性：尽量把每项需求用简洁明了的语言表达出来。（审查、测试用例、开发原型等消除歧义）可验证性：可以通过设计测试用例或其他方法如检测或演示等进行验证。可跟踪性：每条需求都可以从一个需求层次跟踪到另一个需求层次。被唯一标识，以便在设计、实现、测试过程中进行跟踪。有助于确保需求的实现和后期的系统维护。确定性：明确在所有条件下系统应该做什么。,