软件需求分析PPT课件

《软件需求分析PPT课件》由会员分享，可在线阅读，更多相关《软件需求分析PPT课件（93页珍藏版）》请在装配图网上搜索。

1、华中科技大学软件学院华中科技大学软件学院 THE SCHOOL OF SOFTWARE ENGINEERING OF HUST高高 级级 软件工程软件工程陈宁江陈宁江2008.102THE SCHOOL OF SOFTWARE ENGINEERING OF HUST2 需求工程概述需求工程概述 需求获取需求获取 需求分析和建模需求分析和建模 需求验证与管理需求验证与管理本章内容本章内容3THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3什么是需求（什么是需求（Requirement） ？ 需求需求用户对目标软件系统在功能、行为、性能、设计约束用户对目标软件系

2、统在功能、行为、性能、设计约束等方面的期望等方面的期望IEEE的定义（的定义（1997年）年）用户解决问题或达到目标所需的条件或能力用户解决问题或达到目标所需的条件或能力系统或系统部件要满足合同、标准、规范或其它正式规定文档系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力所需具有的条件或能力反映以上两条的文档说明反映以上两条的文档说明 软件需求分析的目标：软件需求分析的目标：调查分析，准确理解用户的要求调查分析，准确理解用户的要求撰写需求，将用户的非形式的要求转化为完整的、形撰写需求，将用户的非形式的要求转化为完整的、形式的规格说明式的规格说明4THE SCHOOL

3、OF SOFTWARE ENGINEERING OF HUST4软件需求分析的任务软件需求分析的任务5THE SCHOOL OF SOFTWARE ENGINEERING OF HUST5需求必须描述的基本问题需求必须描述的基本问题n功能功能所设计的软件要做什么；所设计的软件要做什么； n性能性能软件功能在执行过程中的速度、可使用软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；能力、精度、频率等等； n强加给实现的设计限制强加给实现的设计限制在效果、实现的语言在效果、实现的语言、数据库完整性、资源限制、

4、操作环境等等方面、数据库完整性、资源限制、操作环境等等方面所要求的标准；所要求的标准； n属性属性可移植性、正确性、可维护性及安全性可移植性、正确性、可维护性及安全性等方面的考虑因素；等方面的考虑因素； n外部接口外部接口与人、硬件、其他软件和其它硬件与人、硬件、其他软件和其它硬件的相互关系。的相互关系。 6THE SCHOOL OF SOFTWARE ENGINEERING OF HUST6需求的类型需求的类型 业务需求业务需求（business requirement）客户对系统的高层次的目标要求。在项目视图与范围客户对系统的高层次的目标要求。在项目视图与范围文档中予以说明文档中予以说明

5、用户需求用户需求（user requirement）用户使用产品必须要完成的任务用户使用产品必须要完成的任务 功能需求功能需求（functional requirement）开发人员必须实现的软件功能，使得用户能完成他们开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求的任务，满足业务需求 非功能需求非功能需求（non-functional requirement ）对系统提供的服务或者功能提出的约束，包括时间、对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束开发过程、软件质量、标准等约束7THE SCHOOL OF SOFTWARE ENGINEE

6、RING OF HUST7一个例子一个例子 从不同的角度来看，需求具有不同的层次，即业务从不同的角度来看，需求具有不同的层次，即业务需求、用户需求、功能需求和非功能需求等需求、用户需求、功能需求和非功能需求等 例子：字处理程序例子：字处理程序 之之 “ 拼写检查器拼写检查器”业务需求：业务需求：“用户能有效地纠正文档中的拼写错误用户能有效地纠正文档中的拼写错误”用户需求：用户需求：“找出文档中的拼写错误并通过一个提供的替找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词换项列表来供选择替换拼错的词”功能需求：功能需求：“找到并高亮度提示错词的操作找到并高亮度提示错词的操作”；“

7、显示提显示提供替换词的对话框供替换词的对话框”；“实现整个文档范围的替换实现整个文档范围的替换”非功能需求：非功能需求：“替换操作执行速度快替换操作执行速度快”；“异常出现概率异常出现概率小小”8THE SCHOOL OF SOFTWARE ENGINEERING OF HUST8 如一个小型超市需要一个商品的查询系统。如一个小型超市需要一个商品的查询系统。 业务需求：业务需求：进货人员需要查询商品库存以便保进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。便结账；经理需要查询商品的销售及

8、盈利情况。 用户需求用户需求:这三类用户怎样去查询系统，查询这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。哪些信息，还需要哪些操作。9THE SCHOOL OF SOFTWARE ENGINEERING OF HUST9功能需求功能需求 对于功能性的系统需求，应需要详细描述系统中的操对于功能性的系统需求，应需要详细描述系统中的操作功能、输入、输出、作功能、输入、输出、异常异常等等 功能需求的描述应做到：功能需求的描述应做到：严密性严密性全面性全面性一致性一致性10THE SCHOOL OF SOFTWARE ENGINEERING OF HUST10非功能需求非功能需求 与软件系统的

9、总体特性相关，并作用于整个系统与软件系统的总体特性相关，并作用于整个系统；与软件系统的开发过程有关；与软件系统的开发过程有关11THE SCHOOL OF SOFTWARE ENGINEERING OF HUST11非功能需求的度量非功能需求的度量12THE SCHOOL OF SOFTWARE ENGINEERING OF HUST12软件需求各组成部分之间的关系软件需求各组成部分之间的关系 13THE SCHOOL OF SOFTWARE ENGINEERING OF HUST13软件需求的作用软件需求的作用 软件开发的基础和前提软件开发的基础和前提只有在明确了软件需求之后才能开展有针对性

10、的软件只有在明确了软件需求之后才能开展有针对性的软件开发工作开发工作没有需求无法进行设计和编码没有需求无法进行设计和编码 制定软件开发计划的基础制定软件开发计划的基础只有知道你想做什么，才能知道需要多少工作量，才只有知道你想做什么，才能知道需要多少工作量，才能制定计划能制定计划 最终目标软件系统验收的标准最终目标软件系统验收的标准只有知道你想做什么，才能知道你最终是否做好了只有知道你想做什么，才能知道你最终是否做好了没有定义明确的需求，就不知道最终基于什么进行验没有定义明确的需求，就不知道最终基于什么进行验收收14THE SCHOOL OF SOFTWARE ENGINEERING OF HU

11、ST14需求分析的需求分析的意义意义 软件需求的深入理解是软件开发工作获软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。会令用户失望，给开发带来烦恼。15THE SCHOOL OF SOFTWARE ENGINEERING OF HUST15需求分析的重要性：例子需求分析的重要性：例子3153916% 的项目被终止！平均超出时间的项目被终止！平均超出时间122% 的项目超支，平均超支的项目超支，平均超支 89%！% 的项

12、目按期在预算之内完成！的项目按期在预算之内完成！ (大公司大公司)%的项目按期在预算之内完成！的项目按期在预算之内完成！ (小公司小公司)Standish Group 98 Chaos Report16THE SCHOOL OF SOFTWARE ENGINEERING OF HUST16需求分析的重要性：例子说明需求分析的重要性：例子说明17THE SCHOOL OF SOFTWARE ENGINEERING OF HUST17需求分析的重要性：事实支撑（需求分析的重要性：事实支撑（1/4） 软件生命周期中，一个错误发现得越晚，修复错软件生命周期中，一个错误发现得越晚，修复错误的费用越高误的

13、费用越高18THE SCHOOL OF SOFTWARE ENGINEERING OF HUST18需求分析的重要性：事实支撑（需求分析的重要性：事实支撑（2/4）许多错误是潜伏的，并且在错误产生后很长一段时间许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来才被检查出来在需求过程中会产生很多错误在需求过程中会产生很多错误DeMarco研究报告：被检查出来的错误的研究报告：被检查出来的错误的56产生的根源可产生的根源可以追溯到需求阶段。以追溯到需求阶段。19THE SCHOOL OF SOFTWARE ENGINEERING OF HUST19需求分析的重要性：事实支撑（需求分析的重要

14、性：事实支撑（3/4）在需求阶段，代表性的错误为疏忽、不一致和二义性在需求阶段，代表性的错误为疏忽、不一致和二义性美国海军研究实验室对海军美国海军研究实验室对海军A-7E飞机上的飞行操作程序进行实地飞机上的飞行操作程序进行实地测试，得出的研究数据表明：测试，得出的研究数据表明：A-7E项目中项目中77的需求错误特点是的需求错误特点是不明确：疏忽、不一致和二义性。不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是：按错误类型对这些错误分布进行分析的结果是： 49不正确的事实，31疏忽，l 3不一致，5二义性20THE SCHOOL OF SOFTWARE ENGINEERIN

15、G OF HUST20需求分析的重要性：事实支撑（需求分析的重要性：事实支撑（4/4）需求错误是可以被检查出来的需求错误是可以被检查出来的21THE SCHOOL OF SOFTWARE ENGINEERING OF HUST21需求分析的重要性需求分析的重要性推论推论 在需求过程中会产生很多错误在需求过程中会产生很多错误 许多错误并没有在早期被发现许多错误并没有在早期被发现 这样的错误是能够在产生的初期被检查出来的这样的错误是能够在产生的初期被检查出来的 如果没有及时检查出来这些错误，软件费用会直线上如果没有及时检查出来这些错误，软件费用会直线上升升22THE SCHOOL OF SOFTW

16、ARE ENGINEERING OF HUST22获取软件需求的复杂性获取软件需求的复杂性 系统复杂和庞大系统复杂和庞大如何将软件需求得到？描述清楚？如何将软件需求得到？描述清楚？ 片面片面, 不完全不完全如何保证得到了所有的软件需求？如何保证得到了所有的软件需求？ 模糊模糊, 不准确不准确如何保证把需求说清楚和准确？如何保证把需求说清楚和准确？ 不一致不一致, 歧义歧义如何保证所描述的需求是不矛盾的？如何保证所描述的需求是不矛盾的？ 及时性及时性当需求变更时，如何让相关人员都知道需求已经变更？当需求变更时，如何让相关人员都知道需求已经变更？ 软件需求变动带来的问题软件需求变动带来的问题波动性

17、波动性放大性放大性23THE SCHOOL OF SOFTWARE ENGINEERING OF HUST23需求分析与程序分析的不同需求分析与程序分析的不同24THE SCHOOL OF SOFTWARE ENGINEERING OF HUST24需求分析常见问题需求分析常见问题 误解误解 交流障碍交流障碍 缺乏共同语言缺乏共同语言 “完整性完整性”问题问题 需求永远不会稳定需求永远不会稳定 用户意见不统一用户意见不统一 错误要求错误要求 认识混淆认识混淆25THE SCHOOL OF SOFTWARE ENGINEERING OF HUST25案例分析：中源公司的电信软件项目案例分析：中源

18、公司的电信软件项目 思考：思考：为什么需求工作出现了问题？为什么需求工作出现了问题？在需求出现变更时怎么办？在需求出现变更时怎么办？ 如何更好地进行需求管理？下一步可采取什么措施？如何更好地进行需求管理？下一步可采取什么措施？26THE SCHOOL OF SOFTWARE ENGINEERING OF HUST26需求问题的解决方法和手段需求问题的解决方法和手段 技术层面技术层面需求分析方法、技术和工具需求分析方法、技术和工具方法：数据流、面向对象方法：数据流、面向对象技术：抽象、建模、多视点、原型、技术：抽象、建模、多视点、原型、工具：工具：UML，Rose，Word，Excel，Requ

19、isitePro 管理层面管理层面对需求分析中的人、活动和产品进行管理对需求分析中的人、活动和产品进行管理 形成新的研究领域：形成新的研究领域：需求工程需求工程27THE SCHOOL OF SOFTWARE ENGINEERING OF HUST27需求工程（需求工程（Requirement Engineering ）软件工程的子领域。应用已证实有效的技术、方法进行软件工程的子领域。应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定需求分析，确定客户需求，帮助分析人员理解问题并定义和管理目标系统的需求义和管理目标系统的需求 需需 求求 工工 程程需需 求求 开开

20、发发需需 求求 管管 理理需求需求获取获取需求需求 分分析析需求需求 建模建模需求需求 规约规约需求需求 验证验证28THE SCHOOL OF SOFTWARE ENGINEERING OF HUST28软件需求工程：软件需求工程： 需求获取需求获取 需求分析与协商需求分析与协商 需求建模需求建模 需求描述需求描述 需求验证需求验证 需求管理需求管理需求分析和协商需求分析和协商需求描述需求描述需求验证需求验证系统模型系统模型用户需求和系统需用户需求和系统需求求需求规约需求规约需求管理需求管理需求获取需求获取需求建模需求建模29THE SCHOOL OF SOFTWARE ENGINEERIN

21、G OF HUST29（一）需求获取（一）需求获取 系统分析人员通过与用户交流，对系统分析人员通过与用户交流，对现有系统的观察及对任务进行分析现有系统的观察及对任务进行分析：确定系统或产品确定系统或产品范围范围与系统或产品有关的与系统或产品有关的人员人员及特征列表及特征列表系统的技术系统的技术环境环境的描述的描述系统系统功能功能的列表及应用于每个需求的的列表及应用于每个需求的领域限制领域限制一组描述不同运行条件下系统的一组描述不同运行条件下系统的应用应用场景场景为更好地定义需求而开发的为更好地定义需求而开发的原型原型 需求获取工作的产品为进行需求分需求获取工作的产品为进行需求分析提供了基础析提

22、供了基础 问题域问题域 用户用户 需求分析员需求分析员 交流交流 30THE SCHOOL OF SOFTWARE ENGINEERING OF HUST30需求获取方法需求获取方法 工作内容工作内容用耳用耳 聆听用户的需求聆听用户的需求用脑用脑 分析和整理所获取的信息分析和整理所获取的信息用手用手 形成文档化的描述形成文档化的描述 方法方法建立顺畅的通信途径建立顺畅的通信途径 客户访谈和调查客户访谈和调查建立联合分析小组，建立联合分析小组，观察用户操作流程观察用户操作流程 组成联合小组组成联合小组及时整理分析，反馈循环及时整理分析，反馈循环快速原型快速原型31THE SCHOOL OF SO

23、FTWARE ENGINEERING OF HUST31建立顺畅的通信途径建立顺畅的通信途径 n建立分析所需要的通信途径，以保证能建立分析所需要的通信途径，以保证能顺利地对问题进行分析。顺利地对问题进行分析。32THE SCHOOL OF SOFTWARE ENGINEERING OF HUST32访谈与调查访谈与调查 n在具体的实践中，通常采用折衷的方法，即适当地在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开

24、始所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好提问，接下来的问题应有助于对前面的问题更好的理解和细化的理解和细化不要限制用户对问题的回答，这有可能会引出原不要限制用户对问题的回答，这有可能会引出原先没有注意的问题先没有注意的问题提问和回答在汇总后应能够反映用户需求的全貌提问和回答在汇总后应能够反映用户需求的全貌。 33THE SCHOOL OF SOFTWARE ENGINEERING OF HUST33需求分析要需求分析要深入实际深入实际 市场调查市场调查了解市场对待开发软件的要求；市场上有无与待开发软件了解市场对待开发软件的要求；市场上有无与待开发软

25、件类似的系统及其情况类似的系统及其情况 访问用户和用户领域的专家访问用户和用户领域的专家 考察现场考察现场, ,跟踪现场业务流程跟踪现场业务流程 查阅与待开发系统有关的资料查阅与待开发系统有关的资料 34THE SCHOOL OF SOFTWARE ENGINEERING OF HUST34观察用户操作流程观察用户操作流程 n到用户的实际工作环境中对用户的工作流到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细题陈述，对用户需求可

26、以有更全面、更细致的认识。致的认识。 35THE SCHOOL OF SOFTWARE ENGINEERING OF HUST35组成联合小组组成联合小组 n便利的应用规约技术便利的应用规约技术( (Facilitated Application Facilitated Application Specification Techniques , FASTSpecification Techniques , FAST) ) ：打破用户（需方）和开发者（供方）的界限，共打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负同组成一个联合小组，发挥各自的长处，共同负责

27、项目的推进，这样有助于发挥各自优势并增进责项目的推进，这样有助于发挥各自优势并增进解和协调解和协调 鼓励建立客户和系统分析员之间的合作，由他们鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求议不同的方法以及刻画出初步的解决方案需求n加强联系加强联系n促进交流促进交流n增进合作增进合作36THE SCHOOL OF SOFTWARE ENGINEERING OF HUST36FASTFAST基本原则基本原则 在中立的地点举行由开发者和用户出席的会议；在中立的地点举行由开发者和用户

28、出席的会议；建立准备和参与会议的规则；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的交流；建议一个足够正式的议程以便可以进行自由的交流；一个一个“协调者协调者”( (他可以是用户、开发者或其他外人他可以是用户、开发者或其他外人) )来控制会议；来控制会议；使用一种使用一种“定义机制定义机制”( (它可以是工作表、图表、墙它可以是工作表、图表、墙上胶黏纸或墙板上胶黏纸或墙板) )；目标是标识问题、提出解决方案的要素、商议不同的目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的方法、以及在有利于完成目标的氛围中刻画出初步的需求。需求。3

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

30、遵循先整体后部分、先抽象后具体的原则原则 帮助用户发现帮助用户发现潜在的潜在的需求需求38THE SCHOOL OF SOFTWARE ENGINEERING OF HUST38（二）需求分析（二）需求分析 需求获取结束后，分析活动对需求进行需求获取结束后，分析活动对需求进行分类分类组织组织，分析每个需求与其它需求的关系，检查需求的，分析每个需求与其它需求的关系，检查需求的一致性一致性、重叠重叠和和遗漏遗漏的情况，并对需求进行的情况，并对需求进行排序排序 在需求获取阶段，经常出现以下问题：在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现用户提出的要求超出软件系

31、统可以实现的范围或实现能力能力 不同的用户提出了相互冲突的需求不同的用户提出了相互冲突的需求 39THE SCHOOL OF SOFTWARE ENGINEERING OF HUST39需求协商需求协商 n协商的过程就是讨论需求冲突，找出每协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案个人都满意的折衷方案 n协商不是简单的逻辑或技术上的争论，协商不是简单的逻辑或技术上的争论，要注意要注意组织和行政组织和行政方面的因素方面的因素 不一致的目标不一致的目标 责任的丧失或转移责任的丧失或转移 组织文化组织文化 组织管理态度和士气组织管理态度和士气 部门差异部门差异 40THE SCHOOL

32、OF SOFTWARE ENGINEERING OF HUST40n参加者应该包括发现冲突、遗漏或重叠参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的的分析员，以及可以解决发现的问题的项目相关人员项目相关人员 n会议应该讨论那些非正式讨论不能解决会议应该讨论那些非正式讨论不能解决的问题的问题 通常会议是解决冲突最快的方式通常会议是解决冲突最快的方式41THE SCHOOL OF SOFTWARE ENGINEERING OF HUST41（三）需求建模（三）需求建模 为什么需要对软件需求进行建模？为什么需要对软件需求进行建模？需求调查所获取和文档化（文字）的软件需求需求调查

33、所获取和文档化（文字）的软件需求不能有效地描述软件需求不能有效地描述软件需求文字描述的局限性文字描述的局限性(不准确、二义、歧义、不能直观揭不准确、二义、歧义、不能直观揭示关联示关联)不准确不准确不一致不一致不全面不全面.42THE SCHOOL OF SOFTWARE ENGINEERING OF HUST42建模技术建模技术 建模工具的使用在用户和系统分析人员之间建立了统建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不技术对获取的需求信息进行分析，排除错误

34、和弥补不足，确保需求文档正确反映用户的真实意图足，确保需求文档正确反映用户的真实意图 常用的建模方法常用的建模方法面向数据流方法面向数据流方法面向对象的方法面向对象的方法 43THE SCHOOL OF SOFTWARE ENGINEERING OF HUST43结构化分析方法结构化分析方法数据建模数据建模的基础，的基础，描述数据描述数据对象及其对象及其关系关系功能建模的基功能建模的基础，描述数据础，描述数据怎样转换以及怎样转换以及转换的功能转换的功能行为建模的基础，表示系统的各种行行为建模的基础，表示系统的各种行为状态以及状态间的转换方式为状态以及状态间的转换方式适用于适用于数据处理类型软件

35、的需求分析数据处理类型软件的需求分析44THE SCHOOL OF SOFTWARE ENGINEERING OF HUST44数据建模：实体关系图（数据建模：实体关系图（ERD） 数据模型的基本元素数据模型的基本元素数据对象数据对象描述对象的属性描述对象的属性描述对象间相互连接的关系描述对象间相互连接的关系 数据对象之间的关联数据对象之间的关联一对一（一对一（1:1）一对多（一对多（1:N）多对多（多对多（M:N）45THE SCHOOL OF SOFTWARE ENGINEERING OF HUST45数据流图数据流图 描述了信息流和数据转换，表达系统内数据的运动情描述了信息流和数据转换，

36、表达系统内数据的运动情况况 系统的功能体现在核心的数据变换中系统的功能体现在核心的数据变换中 系统的输入源于用方框表示的外部实体，这种输入引系统的输入源于用方框表示的外部实体，这种输入引发系统的数据变换，产生传递给外部实体的输出发系统的数据变换，产生传递给外部实体的输出 基本元素基本元素46THE SCHOOL OF SOFTWARE ENGINEERING OF HUST46数据流图的基本组成数据流图的基本组成47THE SCHOOL OF SOFTWARE ENGINEERING OF HUST47数据字典数据字典 数据字典描述数据流图的数据存储、数据加工（数据字典描述数据流图的数据存储、

37、数据加工（最底层加工）和数据流。它记录的主要内容有：最底层加工）和数据流。它记录的主要内容有： 基本信息：名字、别名、描述基本信息：名字、别名、描述 定义：数据长度、数据类型、数据结构定义：数据长度、数据类型、数据结构 使用特点：取值范围、使用频率、使用方式等使用特点：取值范围、使用频率、使用方式等 控制信息：来源、用户、引用程序、读写权限等控制信息：来源、用户、引用程序、读写权限等其它其它48THE SCHOOL OF SOFTWARE ENGINEERING OF HUST48行为建模行为建模 状态状态迁移图迁移图/表表描述系统或对象的状态，以及导致系统或对象的状态描述系统或对象的状态，以

38、及导致系统或对象的状态改变的事件，从而描述系统的行为改变的事件，从而描述系统的行为 49THE SCHOOL OF SOFTWARE ENGINEERING OF HUST49（四）需求规约（四）需求规约 需求规约是分析任务的最终产物，通过建立完整的信需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种束的说明、合适的验收标准，给出对目标软件的各种需求需求 需求规约作为用户和开发者之间的一个协议，在之后需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶

39、段发挥重要作用的软件工程各个阶段发挥重要作用 签字不是万能的签字不是万能的但没有签字是万万不能！但没有签字是万万不能！50THE SCHOOL OF SOFTWARE ENGINEERING OF HUST50需求的描述需求的描述 不宜使用自然语言描述系统需求不宜使用自然语言描述系统需求原因：理解的二义性，随意性大，难以模块化原因：理解的二义性，随意性大，难以模块化 书写需求的一些原则书写需求的一些原则设计一个标准的格式，保证需求定义按格式书写设计一个标准的格式，保证需求定义按格式书写使用一致的语言使用一致的语言突出显示关键性需求突出显示关键性需求尽量避免使用计算机专业术语尽量避免使用计算机专

40、业术语51THE SCHOOL OF SOFTWARE ENGINEERING OF HUST51需求描述方法需求描述方法 结构化语言描述结构化语言描述依赖于定义标准格式或模板来表达需求描述依赖于定义标准格式或模板来表达需求描述 程序描述语言（程序描述语言（PDLPDL）使用一种类似于程序设计语言的语言，但是具有更多使用一种类似于程序设计语言的语言，但是具有更多抽象特征，通过定义系统的操作模型来定义需求抽象特征，通过定义系统的操作模型来定义需求 图形化符号图形化符号图形语言辅之以文本注释来定义系统的功能需求图形语言辅之以文本注释来定义系统的功能需求 数学描述数学描述基于数学概念的符号基于数学概

41、念的符号 （如有限状态机、集合等）（如有限状态机、集合等）52THE SCHOOL OF SOFTWARE ENGINEERING OF HUST52结构化语言描述结构化语言描述模块标识模块标识：Eclipse/Workstation/Tools/DE/FS/3.5.1Eclipse/Workstation/Tools/DE/FS/3.5.1功能功能添加节点添加节点描述描述添加一个节点到一个已经存在的设计中。添加一个节点到一个已经存在的设计中。输入输入节点类型，节点位置和设计标识符节点类型，节点位置和设计标识符来源来源节点类型和节点位置由用户输入，设计标识符来节点类型和节点位置由用户输入，设计

42、标识符来自数据库自数据库输出输出设计标识符设计标识符前条件前条件设计处于打开状态设计处于打开状态后条件后条件在相应位置添加一个节点，其余无改变在相应位置添加一个节点，其余无改变副作用副作用无无异常异常无设计标识符无设计标识符53THE SCHOOL OF SOFTWARE ENGINEERING OF HUST53程序描述语言（程序描述语言（PDL） 好处：好处：可以用软件工具进行语法和语义可以用软件工具进行语法和语义检查检查可检查需求遗漏和不一致可检查需求遗漏和不一致便于描述比较复杂的操作，如循便于描述比较复杂的操作，如循环、选择等环、选择等可定义接口可定义接口便于实现需求到设计的过渡便于实

43、现需求到设计的过渡 缺点：缺点：表达功能的能力不够充分表达功能的能力不够充分需要具有程序语言知识的人容易需要具有程序语言知识的人容易提前进入设计阶段，偏离需求分提前进入设计阶段，偏离需求分析的目标析的目标54THE SCHOOL OF SOFTWARE ENGINEERING OF HUST54图形化符号描述图形化符号描述 结构化分析结构化分析 用例分析用例分析55THE SCHOOL OF SOFTWARE ENGINEERING OF HUST55需求的描述（续需求的描述（续1） 需求说明语句需求说明语句保持语句和段落的简短保持语句和段落的简短采用主动语态的表达方式采用主动语态的表达方式编

44、写具有正确的语法和标点的完整句子编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样，例如需求陈述应该具有一致的式样，例如“系统必须系统必须”，或者，或者“用户必须用户必须”，并紧跟一个行为动作，并紧跟一个行为动作和可观察的结果和可观察的结果例如：例如：“仓库管理子系统必须实现一张在所请求的仓库中有仓库管理子系统必须实现一张在所请求的仓库中有存货的药品名单存货的药品名单。”56THE SCHOOL OF SOFTWARE ENGINEERING OF HUST56需求的描述（续需求的描述（续2）为了减少不确定性，避免采

45、用模糊的、主观的术语为了减少不确定性，避免采用模糊的、主观的术语例如：用户友好、容易、简单、迅速、有例如：用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接效、支持、许多、最新技术、优越的、可接受的、健壮的受的、健壮的避免使用比较性的词汇避免使用比较性的词汇例如：提高，最大化，最小化和最佳化例如：提高，最大化，最小化和最佳化定量定量地说明所需要提高的程度或者说清一地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值些参数可接受的最大值和最小值57THE SCHOOL OF SOFTWARE ENGINEERING OF HUST57需求说明的质量特性需求说明的质量特性

46、正确性正确性完整性完整性一致性一致性无二义性无二义性可修改性可修改性可跟踪性可跟踪性可验证性可验证性58THE SCHOOL OF SOFTWARE ENGINEERING OF HUST58其它需求分析阶段的文档其它需求分析阶段的文档 初步的用户手册初步的用户手册：着重反映目标软件的用户功能界面：着重反映目标软件的用户功能界面和用户使用的具体要求。和用户使用的具体要求。 测试计划测试计划 修改和完善修改和完善软件开发计划软件开发计划59THE SCHOOL OF SOFTWARE ENGINEERING OF HUST59（五）需求验证（五）需求验证 作为需求开发阶段工作的复查手段，需求验证

47、对功能作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。人员负责，并按规程严格进行。 60THE SCHOOL OF SOFTWARE ENGINEERING OF HUST60需求验证方法需求验证方法 需求评审需求评审 原型建立原型建立 测试用例生成测试用例生成 自动的一致性分析自动的一致性分析 编写用户手册编写用户手册61THE SCHOOL OF SOFTWARE ENGINEERI

48、NG OF HUST61需求评审需求评审 n 需求审查是需求分析阶段工作的最后一步，需求审查是需求分析阶段工作的最后一步，是由软件工程师和客户一起进行并完成的是由软件工程师和客户一起进行并完成的n目的是发现软件需求规格说明中的目的是发现软件需求规格说明中的错误、二义错误、二义性和遗漏的需求性和遗漏的需求n 复审首先在宏观的级别上进行，复审者试图复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确保证软件需求规格说明是完整的、一致的、精确的，然后更详细地关注软件需求规格说明中的措的，然后更详细地关注软件需求规格说明中的措词词62THE SCHOOL OF SOFTWA

49、RE ENGINEERING OF HUST62评审实施评审实施(1/2) 高级管理者定期参与对软件需求管理活动进行的高级管理者定期参与对软件需求管理活动进行的评审评审 高级管理者参与定期评审的主要目的是在合适的抽象高级管理者参与定期评审的主要目的是在合适的抽象层次上及时地了解和洞察软件过程。层次上及时地了解和洞察软件过程。评审间隔时间应该满足组织的需要，如果存在异常情评审间隔时间应该满足组织的需要，如果存在异常情况报告机制，间隔时间可以长些况报告机制，间隔时间可以长些 项目负责人可定期或者事件驱动地参与对软件需项目负责人可定期或者事件驱动地参与对软件需求管理活动的评审求管理活动的评审63TH

50、E SCHOOL OF SOFTWARE ENGINEERING OF HUST63评审实施评审实施(2/2) 软件质量保证组对软件需求管理活动和工作产品软件质量保证组对软件需求管理活动和工作产品进行评审和进行评审和( (或或) )审计，并报告其结果审计，并报告其结果 软件需求已评审，且有关问题在软件工程组开发软件软件需求已评审，且有关问题在软件工程组开发软件之前已得到解决之前已得到解决当软件需求更动时，软件计划、工作产品和活动已经当软件需求更动时，软件计划、工作产品和活动已经适当地更动适当地更动由软件需求的更动所导致的对承诺的更动已与受影响由软件需求的更动所导致的对承诺的更动已与受影响组进行

51、协商组进行协商64THE SCHOOL OF SOFTWARE ENGINEERING OF HUST64评审人员往往需要检查以下内容：评审人员往往需要检查以下内容：1.1.系统定义的目标是否与用户的要求一致；系统定义的目标是否与用户的要求一致；2.2.系统需求分析阶段提供的文档资料是否齐全；文档系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求中的描述是否完整、清晰、准确地反映了用户要求3.3.被开发项目的数据流与数据结构是否确定且充足被开发项目的数据流与数据结构是否确定且充足4.4.主要功能是否已包括在规定的软件范围之内，是否主要功能是否已包括在规定的

52、软件范围之内，是否都已充分说明都已充分说明5.5.设计的约束条件或限制条件是否符合实际设计的约束条件或限制条件是否符合实际6.6.开发的技术风险是什么开发的技术风险是什么7.7.是否详细制定了检验标准，它们能否对系统定义是是否详细制定了检验标准，它们能否对系统定义是否成功进行确认否成功进行确认 65THE SCHOOL OF SOFTWARE ENGINEERING OF HUST65自动化工具自动化工具 需求分析工具帮助分析员制定需求规格说明。 软件需求能够用一种规格说明语言来描述，这种语言把关键字指示符与自然语言(例如英语)描述结合起来。规格说明语言被送进一个处理机，它产生出一份需求规格说

53、明，更为重要的是，它同时还产生出一组有关规格说明的一致性和组织的诊断报告。66THE SCHOOL OF SOFTWARE ENGINEERING OF HUST66自动化工具的手段自动化工具的手段67THE SCHOOL OF SOFTWARE ENGINEERING OF HUST6768THE SCHOOL OF SOFTWARE ENGINEERING OF HUST68 小结小结1：需求开发活动需求开发活动不会是线性地、顺序地完成不会是线性地、顺序地完成。实际上，这些活动是。实际上，这些活动是交叉的交叉的、递增的递增的和和反复的反复的领域了解领域了解需求收集需求收集需求描述需求描述需

54、求文档需求文档过程入口过程入口分类分类冲突解决冲突解决优先排序优先排序需求检查需求检查(1)(2)(3(3) )(4(4) )(5(5) )(6(6) )(7(7) )(8(8) )(9(9) )(10)(10)(11)(11)(12)(12)(13)(13)(14)(15)(15)69THE SCHOOL OF SOFTWARE ENGINEERING OF HUST69小结小结2：软件需求分析人员应该具备的素质软件需求分析人员应该具备的素质 善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法 善于从各种相互冲突或混淆的原始资料中吸取恰当的论据 能够

55、理解用户的环境及领域知识 具备把系统的硬件和软件部分应用于用户环境的能力 具备良好的书面和口头形式进行讨论和交换意见的能力 具有“既能看到树木，又能看到森林”的能力70THE SCHOOL OF SOFTWARE ENGINEERING OF HUST70（六）需求管理（六）需求管理 为什么要需求管理？为什么要需求管理？软件需求肯定是不完全的软件需求肯定是不完全的需求变动，软件演化需求变动，软件演化 需求管理是对系统需求变更了解和控制的过程，是需求管理是对系统需求变更了解和控制的过程，是一组用于帮助项目组在项目进展中的任何时候去标一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的

56、活动识、控制和跟踪需求的活动 从演化的角度看，需求分为：从演化的角度看，需求分为：持久的需求持久的需求易变的需求易变的需求71THE SCHOOL OF SOFTWARE ENGINEERING OF HUST71需求管理常见的问题需求管理常见的问题n软件开发所基于的需求往往软件开发所基于的需求往往不完整不完整不准确不准确模棱两可模棱两可n需求定义没有生成文档，或文档未及时更新需求定义没有生成文档，或文档未及时更新n即使已采用一个个孤立的文档来管理需求，但是即使已采用一个个孤立的文档来管理需求，但是文档散布各处，没人知道哪个是最新版本文档散布各处，没人知道哪个是最新版本文档对信息分析、优先级别

57、划分和跟踪效率不高文档对信息分析、优先级别划分和跟踪效率不高很难从需求文档中提取与项目有关的状态信息很难从需求文档中提取与项目有关的状态信息n对需求没有达成共识对需求没有达成共识n随着情况的改变需求产生变更，但无法有效地管理随着情况的改变需求产生变更，但无法有效地管理和跟踪和跟踪72THE SCHOOL OF SOFTWARE ENGINEERING OF HUST72导致问题的原因导致问题的原因n缺乏用户参与缺乏用户参与n忽略了用户分类忽略了用户分类n在需求阶段，项目的范围尚未很好的定义在需求阶段，项目的范围尚未很好的定义n忽视了运行、操作、法规等方面的约束忽视了运行、操作、法规等方面的约束

58、n“张三张三”不知道怎么写需求说明不知道怎么写需求说明n对需求过程不够了解对需求过程不够了解n管理层不重视管理层不重视n开发过程中修补原始需求的缺陷开发过程中修补原始需求的缺陷n不可控制的外因不可控制的外因73THE SCHOOL OF SOFTWARE ENGINEERING OF HUST73需求管理的内容需求管理的内容74THE SCHOOL OF SOFTWARE ENGINEERING OF HUST74需求管理的方法需求管理的方法 确定需求确定需求变更变更控制过程控制过程 进行需求进行需求变更变更影响分析影响分析 维护需求维护需求变更变更的历史记录的历史记录 建立需求基准版本和需求

59、控制版本文档建立需求基准版本和需求控制版本文档 跟踪跟踪每项需求的状态每项需求的状态 衡量需求稳定性衡量需求稳定性75THE SCHOOL OF SOFTWARE ENGINEERING OF HUST75需求变更管理需求变更管理问题分析和问题分析和变更描述变更描述变更分析和变更分析和成本计算成本计算识别出的问题识别出的问题修正后的需求修正后的需求变更实现变更实现 需求变更管理的要求需求变更管理的要求仔细评估已建议的变更仔细评估已建议的变更制定合适的变更处理制定合适的变更处理变更及时通知所有涉及的人员变更及时通知所有涉及的人员76THE SCHOOL OF SOFTWARE ENGINEERI

60、NG OF HUST76控制需求的变更控制需求的变更(1/3) 需求变更不可避免需求变更不可避免软件需求本身是变化的软件需求本身是变化的在需求分析阶段对软件需求的描述和分析不全面、不准确在需求分析阶段对软件需求的描述和分析不全面、不准确等等 需求变更对软件项目的开发会产生巨大的影响需求变更对软件项目的开发会产生巨大的影响产品功能产品功能开发成本开发成本开发进度开发进度产品质量产品质量77THE SCHOOL OF SOFTWARE ENGINEERING OF HUST77控制需求的变更控制需求的变更(2/3) 需求变更的权衡，需要和用户协商，并对计划进需求变更的权衡，需要和用户协商，并对计划

61、进行变更行变更需求需求成本成本进度进度78THE SCHOOL OF SOFTWARE ENGINEERING OF HUST78控制需求的变更控制需求的变更(3/3) 如何控制需求的变更如何控制需求的变更提出软件需求变更请求提出软件需求变更请求对软件需求变更进行评审对软件需求变更进行评审变更软件需求说明书（变更软件需求说明书（SRS）将变更后的将变更后的SRS纳入配置纳入配置通知受影响小组和人员通知受影响小组和人员变更其他产品变更其他产品(软件设计文档、测试文档软件设计文档、测试文档)和计划和计划(软件开发软件开发计划计划)79THE SCHOOL OF SOFTWARE ENGINEERI

62、NG OF HUST798 .3 软件需求的变更控制软件需求的变更控制需求变更处理流程需求变更处理流程80THE SCHOOL OF SOFTWARE ENGINEERING OF HUST80需求文档的版本控制需求文档的版本控制 统一统一确定版本确定版本 变更必须变更必须文档化文档化，及时通知有关人员，及时通知有关人员 指定专人更新需求指定专人更新需求 文档应包括文档应包括版本修正历史版本修正历史 需求管理工具的数据库存储需求需求管理工具的数据库存储需求 使用专门的版本管理工具及数据库使用专门的版本管理工具及数据库81THE SCHOOL OF SOFTWARE ENGINEERING OF

63、 HUST81需求跟踪需求跟踪 当某项业务需求发生变当某项业务需求发生变化时，可能会影响到系化时，可能会影响到系统需求和功能需求的变统需求和功能需求的变化，并且连带地影响到化，并且连带地影响到设计、测试、实现、项设计、测试、实现、项目计划等各方面的变化目计划等各方面的变化 需求跟踪：应编制每个需求跟踪：应编制每个需求同系统元素之间的需求同系统元素之间的联系文档联系文档82THE SCHOOL OF SOFTWARE ENGINEERING OF HUST82需求跟踪的方式需求跟踪的方式n正向跟踪：正向跟踪：以用户需求为切入点，检查以用户需求为切入点，检查需求规约需求规约中的每中的每个需求是否都

64、能在后继工作产品中找到对应点个需求是否都能在后继工作产品中找到对应点n逆向跟踪：逆向跟踪：检查设计文档、代码、测试用况等工作产品是否检查设计文档、代码、测试用况等工作产品是否都能在都能在需求规约需求规约中找到出处中找到出处83THE SCHOOL OF SOFTWARE ENGINEERING OF HUST83需求跟踪能力矩阵需求跟踪能力矩阵 例子：例子： 大量的需求跟踪信息可以使用特定的工具进行管大量的需求跟踪信息可以使用特定的工具进行管理理 84THE SCHOOL OF SOFTWARE ENGINEERING OF HUST84小结：需求阶段的常见问题小结：需求阶段的常见问题 需求的

65、沟通与理解需求的沟通与理解缺乏足够的用户参与缺乏足够的用户参与添加不必要的特性添加不必要的特性忽略了用户分类忽略了用户分类 需求的变化与控制需求的变化与控制用户需求不断增加用户需求不断增加 需求说明的明确与完整需求说明的明确与完整需求模棱两可需求模棱两可需求说明过于简单需求说明过于简单用户积极参与，用户积极参与，各方和谐合作各方和谐合作有效管理与评审有效管理与评审准确、无二义性的准确、无二义性的高质量需求文档高质量需求文档85THE SCHOOL OF SOFTWARE ENGINEERING OF HUST85CMM对需求管理的要求对需求管理的要求(1/3) 需求管理是CMM 2级的一个关键

66、过程域 CMM对需求管理的理解和定义需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立对“分配给软件的系统需求”的共同理解，由软件工程组对“分配给软件的系统需求”进行分析、精化，按照规范详细描述“分配给软件的系统需求”，形成“软件需求规格说明”文档，并对该文档进行评审 86THE SCHOOL OF SOFTWARE ENGINEERING OF HUST86确保需求管理的必备条件确保需求管理的必备条件(1/4) 建立和明确系统需求分析和分配的人员及其职责建立和明确系统需求分析和分配的人员及其职责 ，明确：明确：在整个项目生存期内，管理和分配系统需求，并将它们写在整个项目生存期内，管理和分配系统需求，并将它们写成文档成文档实施对系统需求及其分配的更动，当系统需求发生更动时实施对系统需求及其分配的更动，当系统需求发生更动时，应及时更动软件需求，应及时更动软件需求87THE SCHOOL OF SOFTWARE ENGINEERING OF HUST87确保需求管理的必备条件确保需求管理的必备条件(2/4) 将软件需求规范化将软件需求规范化技术需求，如软件功能、性能、设