《软件需求分析》由会员分享，可在线阅读，更多相关《软件需求分析（93页珍藏版）》请在金锄头文库上搜索。
1、高 级 软件工程陈宁江 2008.101n需求工程概述n需求获取n需求分析和建模n需求验证与管理本章内容2什么是需求（Requirement） ？n需求用户对目标软件系统在功能、行为、性能、设计约束等 方面的期望 IEEE的定义（1997年）n用户解决问题或达到目标所需的条件或能力n系统或系统部件要满足合同、标准、规范或其它正式规定文档 所需具有的条件或能力n反映以上两条的文档说明n软件需求分析的目标：调查分析，准确理解用户的要求撰写需求，将用户的非形式的要求转化为完整的、形式 的规格说明3软件需求分析的任务4需求必须描述的基本问题n功能所设计的软件要做什么； n性能软件功能在执行过程中的速
2、度、可使用 性、响应时间、各种软件功能的恢复时间、吞吐 能力、精度、频率等等； n强加给实现的设计限制在效果、实现的语言 、数据库完整性、资源限制、操作环境等等方面 所要求的标准； n属性可移植性、正确性、可维护性及安全性 等方面的考虑因素； n外部接口与人、硬件、其他软件和其它硬件 的相互关系。 5需求的类型n 业务需求（business requirement）客户对系统的高层次的目标要求。在项目视图与范围 文档中予以说明n用户需求（user requirement）用户使用产品必须要完成的任务n功能需求（functional requirement）开发人员必须实现的软件功能，使得用户能
3、完成他们 的任务，满足业务需求n非功能需求（non-functional requirement ）对系统提供的服务或者功能提出的约束，包括时间、 开发过程、软件质量、标准等约束6一个例子n从不同的角度来看，需求具有不同的层次，即业务 需求、用户需求、功能需求和非功能需求等n例子：字处理程序 之 “ 拼写检查器”业务需求：“用户能有效地纠正文档中的拼写错误”用户需求：“找出文档中的拼写错误并通过一个提供的替换 项列表来供选择替换拼错的词”功能需求：“找到并高亮度提示错词的操作”；“显示提供替 换词的对话框”；“实现整个文档范围的替换”非功能需求：“替换操作执行速度快”；“异常出现概率小”7如一
4、个小型超市需要一个商品的查询系统。业务需求：进货人员需要查询商品库存 以便保证及时进货；收款员需要查询商品 的销售价格以便结账；经理需要查询商品 的销售及盈利情况。用户需求:这三类用户怎样去查询系统， 查询哪些信息，还需要哪些操作。8功能需求n对于功能性的系统需求，应需要详细描述 系统中的操作功能、输入、输出、异常等n功能需求的描述应做到：严密性全面性一致性9非功能需求n与软件系统的总体特性相关，并作用于整 个系统；与软件系统的开发过程有关10非功能需求的度量11软件需求各组成部分之间的关系 12软件需求的作用n软件开发的基础和前提只有在明确了软件需求之后才能开展有针对性的软件 开发工作没有需
5、求无法进行设计和编码n制定软件开发计划的基础只有知道你想做什么，才能知道需要多少工作量，才 能制定计划n最终目标软件系统验收的标准只有知道你想做什么，才能知道你最终是否做好了没有定义明确的需求，就不知道最终基于什么进行验 收13需求分析的意义软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。14需求分析的重要性：例子 3153916% 的项目被终止！平均超出时间122% 的项目超支，平均超支 89%！% 的项目按期在预算之内完成！ (大公司)%的项目按期在预算之内完成！ (小公司)Standish G
6、roup 98 Chaos Report15需求分析的重要性：例子说明16需求分析的重要性：事实支撑（1/4 ） n软件生命周期中，一个错误发现得越晚， 修复错误的费用越高17需求分析的重要性：事实支撑（2/4 ）许多错误是潜伏的，并且在错误产生后很长一 段时间才被检查出来在需求过程中会产生很多错误nDeMarco研究报告：被检查出来的错误的56产生 的根源可以追溯到需求阶段。18需求分析的重要性：事实支撑（3/4 ）在需求阶段，代表性的错误为疏忽、不一致和 二义性n美国海军研究实验室对海军A-7E飞机上的飞行操作 程序进行实地测试，得出的研究数据表明：A-7E项 目中77的需求错误特点是不明
7、确：疏忽、不一致 和二义性。n按错误类型对这些错误分布进行分析的结果是：49不正确的事实，31疏忽，l 3不一致，5二义性19需求分析的重要性：事实支撑（4/4 ）需求错误是可以被检查出来的20需求分析的重要性推论n在需求过程中会产生很多错误n许多错误并没有在早期被发现n这样的错误是能够在产生的初期被检查出 来的n如果没有及时检查出来这些错误，软件费 用会直线上升21获取软件需求的复杂性n系统复杂和庞大如何将软件需求得到？描述清楚？n片面, 不完全如何保证得到了所有的软件需求？n模糊, 不准确如何保证把需求说清楚和准确？n不一致, 歧义如何保证所描述的需求是不矛盾的？n及时性当需求变更时，如何
8、让相关人员都知道需求已经变更？n软件需求变动带来的问题波动性放大性22需求分析与程序分析的不同23需求分析常见问题n误解n交流障碍n缺乏共同语言n“完整性”问题n需求永远不会稳定n用户意见不统一n错误要求n认识混淆24案例分析：中源公司的电信软件项目n思考：为什么需求工作出现了问题？在需求出现变更时怎么办？ 如何更好地进行需求管理？下一步可采取什么 措施？25需求问题的解决方法和手段n技术层面需求分析方法、技术和工具n方法：数据流、面向对象n技术：抽象、建模、多视点、原型、n工具：UML，Rose，Word，Excel，RequisitePron管理层面对需求分析中的人、活动和产品进行管理n形
9、成新的研究领域：需求工程26需求工程（Requirement Engineering ）软件工程的子领域。应用已证实有效的技术、方 法进行需求分析，确定客户需求，帮助分析人员 理解问题并定义和管理目标系统的需求 需 求 工 程需 求 开 发需 求 管 理需求 获取需求 分 析需求 建模需求 规约需求 验证27软件需求工程：n需求获取n需求分析与协 商n需求建模n需求描述n需求验证n需求管理需求分析和 协商需求描述需求验证 系统模型用户需求和 系统需求需求规约需求管理需求获取需求建模28（一）需求获取 n系统分析人员通过与用户交流，对 现有系统的观察及对任务进行分析 ：确定系统或产品范围与系统或
10、产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的 领域限制一组描述不同运行条件下系统的应用 场景为更好地定义需求而开发的原型 n需求获取工作的产品为进行需求分 析提供了基础 29需求获取方法 n工作内容用耳 聆听用户的需求用脑 分析和整理所获取的信息用手 形成文档化的描述n方法建立顺畅的通信途径 客户访谈和调查建立联合分析小组，观察用户操作流程 组成联合小组及时整理分析，反馈循环快速原型30建立顺畅的通信途径 n建立分析所需要的通信途径，以保证能 顺利地对问题进行分析。31访谈与调查 n在具体的实践中，通常采用折衷的方法，即适当地 计划好面谈，但不要过于详细，允许有
11、一定的灵活 性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开始 提问，接下来的问题应有助于对前面的问题更好 的理解和细化不要限制用户对问题的回答，这有可能会引出原 先没有注意的问题提问和回答在汇总后应能够反映用户需求的全貌 。 32需求分析要深入实际n市场调查了解市场对待开发软件的要求；市场上有无与 待开发软件类似的系统及其情况n访问用户和用户领域的专家n考察现场,跟踪现场业务流程 n查阅与待开发系统有关的资料 33观察用户操作流程 n到用户的实际工作环境中对用户的工作流 程进行观察，了解用户实际的操作环境、 操作过程和操作要求，对照用户提交的问 题陈述，对用户需求可以有
12、更全面、更细 致的认识。 34组成联合小组 n便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ：打破用户（需方）和开发者（供方）的界限，共 同组成一个联合小组，发挥各自的长处，共同负 责项目的推进，这样有助于发挥各自优势并增进 解和协调 鼓励建立客户和系统分析员之间的合作，由他们 共同工作来标识问题、提出解决方案的要素、商 议不同的方法以及刻画出初步的解决方案需求n加强联系n促进交流n增进合作35FAST基本原则 在中立的地点举行由开发者和用户出席的会议；建立准备和参与会议的规则；建议一个足够正式的议程以便可
13、以进行自由的交流；一个“协调者”(他可以是用户、开发者或其他外人) 来控制会议；使用一种“定义机制”(它可以是工作表、图表、墙 上胶黏纸或墙板)；目标是标识问题、提出解决方案的要素、商议不同的 方法、以及在有利于完成目标的氛围中刻画出初步的 需求。36需求收集的注意事项n如果应用规模较大，可分成几个需求调查小组同 时进行，最后对结果进行汇总n一定要和用户进行充分的交流，发现问题要及时 沟通n要和用户打成一片，建立起良好的合作关系n如果发现多个软件需求相互矛盾，要能找到仲裁 人或者决策人n需求调查应遵循先整体后部分、先抽象后具体的 原则n帮助用户发现潜在的需求37（二）需求分析n需求获取结束后，
14、分析活动对需求进行分 类组织，分析每个需求与其它需求的关系 ，检查需求的一致性、重叠和遗漏的情况 ，并对需求进行排序n在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围 或实现能力 不同的用户提出了相互冲突的需求 38需求协商 n协商的过程就是讨论需求冲突，找出每 个人都满意的折衷方案 n协商不是简单的逻辑或技术上的争论， 要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异 39n参加者应该包括发现冲突、遗漏或重叠 的分析员，以及可以解决发现的问题的 项目相关人员 n会议应该讨论那些非正式讨论不能解决 的问题 通常会议是
15、解决冲突最快的方式40（三）需求建模 n为什么需要对软件需求进行建模？ 需求调查所获取和文档化（文字）的软 件需求不能有效地描述软件需求文字描述的局限性(不准确、二义、歧义、不能 直观揭示关联)不准确不一致不全面41建模技术n建模工具的使用在用户和系统分析人员之 间建立了统一的语言和理解的桥梁，同时 系统分析人员借助建模技术对获取的需求 信息进行分析，排除错误和弥补不足，确 保需求文档正确反映用户的真实意图n常用的建模方法面向数据流方法面向对象的方法 42结构化分析方法数据建 模的基 础，描 述数据 对象及 其关系功能建模 的基础， 描述数据 怎样转换 以及转换 的功能行为建模的基础，表示系
16、统的各种行为状态以及状 态间的转换方式适用于 数据处理类型软件的需求分析43数据建模：实体关系图（ERD）n数据模型的基本元素数据对象描述对象的属性描述对象间相互连接的关系n数据对象之间的关联 一对一（1:1）一对多（1:N）多对多（M:N）44数据流图n描述了信息流和数据转换，表达系统内数据的运 动情况n系统的功能体现在核心的数据变换中n系统的输入源于用方框表示的外部实体，这种输 入引发系统的数据变换，产生传递给外部实体的 输出n基本元素45数据流图的基本组成46数据字典n数据字典描述数据流图的数据存储、数据 加工（最底层加工）和数据流。它记录的 主要内容有： 基本信息：名字、别名、描述 定义：数据长度、数据类型、数据结构 使用特点：取值范围、使用频率、使用方式等 控制信息：来源、用户、引用程序、读写权限 等
