软件工程-软件需求分析.ppt

软件工程-软件需求分析.ppt

《软件工程-软件需求分析.ppt》由会员分享，可在线阅读，更多相关《软件工程-软件需求分析.ppt（107页珍藏版）》请在冰豆网上搜索。

高级软件工程,陈宁江,2,需求工程概述需求获取需求分析和建模需求验证与管理,本章内容,3,什么是需求（Requirement）？

需求用户对目标软件系统在功能、行为、性能、设计约束等方面的期望IEEE的定义（1997年）用户解决问题或达到目标所需的条件或能力系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力反映以上两条的文档说明软件需求分析的目标：

调查分析，准确理解用户的要求撰写需求，将用户的非形式的要求转化为完整的、形式的规格说明,4,软件需求分析的任务,5,需求的类型,业务需求（businessrequirement）客户对系统的高层次的目标要求。

在项目视图与范围文档中予以说明用户需求（userrequirement）用户使用产品必须要完成的任务功能需求（functionalrequirement）开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求非功能需求（non-functionalrequirement）对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束,6,一个例子,从不同的角度来看，需求具有不同的层次，即业务需求、用户需求、功能需求和非功能需求等例子：

字处理程序之“拼写检查器”业务需求：

“用户能有效地纠正文档中的拼写错误”用户需求：

“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”功能需求：

“找到并高亮度提示错词的操作”；“显示提供替换词的对话框”；“实现整个文档范围的替换”非功能需求：

“替换操作执行速度快”；“异常出现概率小”,7,功能需求,对于功能性的系统需求，应需要详细描述系统中的操作功能、输入、输出、异常等功能需求的描述应做到：

严密性全面性一致性,8,非功能需求,与软件系统的总体特性相关，并作用于整个系统；与软件系统的开发过程有关,9,非功能需求的度量,10,软件需求各组成部分之间的关系,11,软件需求的作用,软件开发的基础和前提只有在明确了软件需求之后才能开展有针对性的软件开发工作没有需求无法进行设计和编码制定软件开发计划的基础只有知道你想做什么，才能知道需要多少工作量，才能制定计划最终目标软件系统验收的标准只有知道你想做什么，才能知道你最终是否做好了没有定义明确的需求，就不知道最终基于什么进行验收,12,需求分析的重要性：

例子,31,53,9,16,%的项目被终止！

平均超出时间122%,%的项目超支，平均超支89%！

%的项目按期在预算之内完成！

（大公司）,%的项目按期在预算之内完成！

（小公司）StandishGroup98ChaosReport,用户参与不足！

不完整的用户需求！

需求不断变化！

13,需求分析的重要性：

例子说明,14,需求分析的重要性：

事实支撑（1/4）,软件生命周期中，一个错误发现得越晚，修复错误的费用越高,15,需求分析的重要性：

事实支撑（2/4）,许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误DeMarco研究报告：

被检查出来的错误的56产生的根源可以追溯到需求阶段。

16,需求分析的重要性：

事实支撑（3/4）,在需求阶段，代表性的错误为疏忽、不一致和二义性美国海军研究实验室对海军A-7E飞机上的飞行操作程序进行实地测试，得出的研究数据表明：

A-7E项目中77的需求错误特点是不明确：

疏忽、不一致和二义性。

按错误类型对这些错误分布进行分析的结果是：

49不正确的事实，31疏忽，l3不一致，5二义性,17,需求分析的重要性：

事实支撑（4/4）,需求错误是可以被检查出来的,18,需求分析的重要性推论,在需求过程中会产生很多错误许多错误并没有在早期被发现这样的错误是能够在产生的初期被检查出来的如果没有及时检查出来这些错误，软件费用会直线上升,19,获取软件需求的复杂性,系统复杂和庞大如何将软件需求得到？

描述清楚？

片面,不完全如何保证得到了所有的软件需求？

模糊,不准确如何保证把需求说清楚和准确？

不一致,歧义如何保证所描述的需求是不矛盾的？

及时性当需求变更时，如何让相关人员都知道需求已经变更？

软件需求变动带来的问题波动性放大性,20,需求分析与程序分析的不同,21,需求分析常见问题,误解交流障碍缺乏共同语言“完整性”问题需求永远不会稳定用户意见不统一错误要求认识混淆,22,案例分析：

中源公司的电信软件项目,思考：

为什么需求工作出现了问题？

在需求出现变更时怎么办？

如何更好地进行需求管理？

下一步可采取什么措施？

23,需求问题的解决方法和手段,技术层面需求分析方法、技术和工具方法：

数据流、面向对象技术：

抽象、建模、多视点、原型、工具：

UML，Rose，Word，Excel，RequisitePro管理层面对需求分析中的人、活动和产品进行管理形成新的研究领域：

需求工程,24,需求工程（RequirementEngineering）,软件工程的子领域。

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义和管理目标系统的需求,需求工程,需求获取,需求分析,需求建模,需求规约,需求验证,25,软件需求工程：

需求获取需求分析与协商需求建模需求描述需求验证需求管理,需求分析和协商,需求描述,需求验证,系统模型,用户需求和系统需求,需求规约,需求管理,需求获取,需求建模,26,

（一）需求获取,系统分析人员通过与用户交流，对现有系统的观察及对任务进行分析：

确定系统或产品范围与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下系统的应用场景为更好地定义需求而开发的原型需求获取工作的产品为进行需求分析提供了基础,27,需求获取方法,工作内容用耳聆听用户的需求用脑分析和整理所获取的信息用手形成文档化的描述方法建立顺畅的通信途径客户访谈和调查建立联合分析小组，观察用户操作流程组成联合小组及时整理分析，反馈循环快速原型,28,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析。

29,访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。

一般按照如下原则进行准备：

所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化不要限制用户对问题的回答，这有可能会引出原先没有注意的问题提问和回答在汇总后应能够反映用户需求的全貌。

30,需求分析要深入实际,市场调查了解市场对待开发软件的要求；市场上有无与待开发软件类似的系统及其情况访问用户和用户领域的专家考察现场,跟踪现场业务流程查阅与待开发系统有关的资料,31,例子：

“围棋比赛成绩计算系统”的第一次面谈的准备计划,32,观察用户操作流程,到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

33,组成联合小组,便利的应用规约技术（FacilitatedApplicationSpecificationTechniques,FAST）：

打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求,加强联系促进交流增进合作,34,FAST基本原则,在中立的地点举行由开发者和用户出席的会议；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的交流；一个“协调者”（他可以是用户、开发者或其他外人）来控制会议；使用一种“定义机制”（它可以是工作表、图表、墙上胶黏纸或墙板）；目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。

35,需求收集的注意事项,如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总一定要和用户进行充分的交流，发现问题要及时沟通要和用户打成一片，建立起良好的合作关系如果发现多个软件需求相互矛盾，要能找到仲裁人或者决策人需求调查应遵循先整体后部分、先抽象后具体的原则帮助用户发现潜在的需求,36,

（二）需求分析,需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并对需求进行排序在需求获取阶段，经常出现以下问题：

用户提出的要求超出软件系统可以实现的范围或实现能力不同的用户提出了相互冲突的需求,37,需求协商,协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论，要注意组织和行政方面的因素不一致的目标责任的丧失或转移组织文化组织管理态度和士气部门差异,38,参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题,通常会议是解决冲突最快的方式,39,（三）需求建模,为什么需要对软件需求进行建模？

需求调查所获取和文档化（文字）的软件需求不能有效地描述软件需求文字描述的局限性（不准确、二义、歧义、不能直观揭示关联）不准确不一致不全面.,40,建模技术,建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图常用的建模方法面向数据流方法面向对象的方法,41,结构化分析方法,数据建模的基础，描述数据对象及其关系,功能建模的基础，描述数据怎样转换以及转换的功能,行为建模的基础，表示系统的各种行为状态以及状态间的转换方式,适用于数据处理类型软件的需求分析,42,数据流图DFD-DataFlowDiagram,图形化技术，描绘信息流和数据从输入移动到输出的过程中所经受的变换。

在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。

设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。

43,数据建模：

实体关系图（ERD）,数据模型的基本元素数据对象描述对象的属性描述对象间相互连接的关系数据对象之间的关联一对一（1:

1）一对多（1:

N）多对多（M:

N）,44,数据流图,描述了信息流和数据转换，表达系统内数据的运动情况系统的功能体现在核心的数据变换中系统的输入源于用方框表示的外部实体，这种输入引发系统的数据变换，产生传递给外部实体的输出,45,-系统逻辑模型,46,数据流图的基本组成,47,数据流图的层次结构,为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。

按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。

在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。

它的输入流是该系统的输入数据，输出流是系统所输出数据。

底层流图是指其加工不需再做分解的数据流图，它处在最底层。

中间层流图则表示对其上层父图的细化。

它的每一加工可能继续细化，形成子图。

48,分层的数据流图,49,对数据流图进行分层,GeorgeMiller在著名的论文“神奇的数字7加减2：

我们处理信息的能力的某种限制”中指出：

人们在一段时间内的短期记忆似乎限制在59件事情之内根据自顶向下逐层分解的思想将数据流图画成层次结构每个层次画在独立的数据流图中，加工个数可大致控制在“7加减2”的范围中,50,数据字典,数据字典描述数据流图的数据存储、数据加工（最底层加工）和数据流数据字典的任务是:

对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

数据流图和数据字典共同构成系统的逻辑模型没有数据字典数据流图就不严格，没有数据流