软件工程2章需求法分析33lin.ppt

《软件工程2章需求法分析33lin.ppt》由会员分享，可在线阅读，更多相关《软件工程2章需求法分析33lin.ppt（113页珍藏版）》请在三一文库上搜索。

1、1 第三章第三章 需求分析需求分析 软件需求分析软件需求分析 需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统 怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系 统提出完整、准确、清晰、具体的要求。 并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明 书，以书面形式准确地描述软件需求。即： - 准确地回答“系统必须做什么?”。 意义：意义： 软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把 设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失 望，给开发带来烦恼。 2 软件需求工程的活动（内容）软件需求工程的活动（内容） 软件需求工

2、程 需求开发需求管理 需求建模 需求获取需求规格说明 需求验证 建立基线 变更控制 需求跟踪 3 综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段： （1）需求获取：深入实际，确定待开发的软件系统的用户类，通过与用户 的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户 的需求； （2）需求分析及建模：主要对收集到的需求进行提炼、分析和认真审查， 确保所有参加人员取得一致共识。找出错误、遗漏和不足，为最终用户所看 到的系统建立模型，根据软件需求信息建立软件系统的逻辑模型或需求模型 。需求模型作为对需求的抽象描述，尽可能多的捕获现实世界的语义，并确 定非功能性需求和约束

3、条件和限制。 （3）形成需求规格：根据收集的需求信息和逻辑模型生成需求模型构件的 精确的形式化的描述，作为用户和开发者之间的一个协约编写需求规格说明 及其文档。 （4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型 等途径，分析需求规格的正确性和可行性； （5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。当需 求发生变更时，对需求规格说明及需求变更实施进行管理。需求工程也是一 个项目工程，因此也包括了项目的管理。 软件需求工程的活动（内容）软件需求工程的活动（内容） 4 3.13.1需求获取需求获取 l需求获取是需求工程的主体内容之一。获取需求是一个确定和理解不同 涉

4、众的需要和约束的过程。 l涉众团体( 所有能够影响软件系统的实现,或者被实现后的软件系统所影 响的个人和团体 )之间的相互沟通，识别需要的过程。涉众团体通过这个 过程提取、定义需求。需求获取既涉及技术问题，也涉及社会交往问题。 难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确的； 存在默认的知识,如难以描述的常识问题； 存在多个知识源,且多知识源之间可能有冲突； 客户可能的偏见，如不能提供或不想告知你所需要了解的事 情。 5 在分析软件需求和书写软件需求规格说明书的过程中，分析 员和用户都起着关键的、必不可少的作用。 n只有用户才真正知道自己需要什么，但是他们并不知道怎样 用软件实现自己

5、的需求，用户必须把他们对软件的需求尽量 准确、具体地描述出来；分析员知道怎样用软件实现人们的 需求，但是在需求分析开始时他们对用户的需求并不十分清 楚，必须与用户沟通获取用户对软件的需求 3.13.1需求获取需求获取 6 业务需求 项目范 围文档 用户需求 文档 功能需求 质量属性 其他非功 能需求 设计约束 需求规约 (specification) 非功能需求 系统需求 需求组成的全景图 软件需求的层次软件需求的层次 7 业务需求：反映组织机构和客户对系统、产品 高层次的目标要求。 用户需求：从用户使用的角度给出需求的描述。 如一个小型超市需要一个商品的查询系统。 业务需求：进货人员需要查询

6、商品库存以便保 证及时进货；收款员需要查询商品的销售价格以 便结账；经理需要查询商品的销售及盈利情况。 用户需求:这三类用户怎样去查询系统，查 询哪些信息，还需要哪些操作。 软件需求的层次软件需求的层次 8 系统需求：从系统的角度描述要提供的服务以及所受到 的约束。 功能性需求：描述系统应该做什么，即为用户和其它系 统完成的功能、提供的服务。 非功能性需求：产品必须具备的属性或品质。 设计约 束：设计与实现必须遵循的标准、约束条件。 如运行平台、协议、选择的技术、编程语言和工具等。 软件需求的组成软件需求的组成 9 需求获取的过程：需求获取的过程： 确定需求开发计划 建立项目前景与范围 确定调

7、查对象 实地收集用户需求信息 确定非功能需求和约束条件 10 1.1.确定需求开发计划确定需求开发计划 确定需求开发计划的基本任务是确定需求开发的实施 步骤，给出收集需求活动的人员、具体安排和进度。需要 重点注意的是： l针对不同层次的调查对象，安排的调查人员在阅历和经验 上的对等原则。 l调查人员的沟通和业务理解能力必须适当。 l用户的时间延误、文档确认的时间要在计划进度中预留。 11 2.2.确定产品确定产品前景与项目范围前景与项目范围 本阶段的任务是帮助投资管理人、产品经理弄清楚“为什么要作这个 项目？”，组织的业务目标以及系统最终版本具备哪些功能的长远规划。 产品前景（product

8、vision）描述了产品用来干什么，它最终会是什么 样子。 项目范围（project scope）确定当前的项目要解决产品长远规划中的哪 一部分。项目范围的细节体现于项目定义的需求基线。 产生文档：前景与范围文档。 12 前景与范围的关系前景与范围的关系 前景关系到整个产品。当产品的战略定位或业务目标随时间发生 改变时，前景也会变化。范围则只与一个特定项目，或实现产品功能 下一增量的某次迭代相关。 产品前景包括了每一个计划产品版本的范围 13 前景和范围文档的模板前景和范围文档的模板 1.业务需求 1.1 背景 1.2 业务机遇 1.3 业务目标与成功标准 1.4 客户和市场需要 1.5 业务

9、风险 2.解决方案的前景 2.1 前景陈述 2.2 主要的系统特征 2.3 假设和依赖条件 3.项目范围与限制 3.1 第一个版本的范围 3.2 各后续版本的范围 3.3 限制和排除条件 4.业务背景 4.1 涉众档案 4.2 项目优先级 4.3 运行环境 14 3.3.确定调查对象确定调查对象 本阶段的基本任务是明确地确定来自不同层次的需求来源和 用户，并将其分类。(前景与范围文档可以帮助区分用户分类) 由于软件需求分为三个层次，业务需求、用户需求、功能需 求，故应根据需求的层次来区分不同的用户。 用户分类：可分为三种不同类别 n 用户方的领导者、项目规划者、项目出资人 (目标) n 软件的

10、直接使用、操作人员 （功能,易用性） n 未来软件系统的技术管理、运行维护人员（性能,安装,维护） 15 4. 4. 实地收集用户需求信息实地收集用户需求信息 实地收集需求信息面临的困难 1）能提出软件需求的用户没有时间 2）有时用户希望通过简单的说明和问答 3）用户和开发人员只考虑自己的利益 4）用户本身不能提出明确的需求 5）开发人员缺乏用户的业务知识，而用户缺乏计算机方面的 知识，引起交流困难。 16 实地调查的步骤实地调查的步骤 1）向掌握“全局”的负责人调查：概貌,规划,目标,范围 2）向部门负责人调查：业务和业务流程,部门间相互关系。功 能需求和非功能需求,与其他部门间的接口。 3

11、）向业务人员调查：自身工作处理细节、具体数据或表格的作 用来源和去向、类型、精度、处理要求和输入/输出格式。 具体的功能和性能需求。 17 *17 实地收集需求信息的方式实地收集需求信息的方式 需求获取可能是软件开发中最需要交流的一项工作。获取 涉众的需求是需求工作的重要环节。 需求获取只有通过客户与开发者的有效合作才能成功。分 析者必须为客户建立一个对问题进行彻底探讨的环境，而 这些问题与将要开发的产品有关。另外要让用户明确了解 ，对于某些功能的讨论并不意味着即将在产品中实现它。 对于想到的需求必须集中处理并设定优先级，消除不必要 的需求，以避免项目范围无意义地膨胀。目前主要有以下 的需求获

12、取方法。 18 n面谈法 重要而直接，简单的需求获取技术。 面谈的对象主要有用户和领域专家： 1）面谈前的准备要充分； 2）面谈后注意认真分析总结； 3）注意掌握面谈的人际交流技能。 提问题：a. 你所在部门的业务流程是怎样的？ b. 你所在部门与其它部门的关系是怎样的？ c. 本部门产生哪些表格及其输入/输出形式？ d. 在业务中使用什么计算方法？ 关于如何解决问题的提问： a. 当某问题发生时，应该如何解决？ b. 你现在工作中存在什么问题？如何解决？ c. 除了正常情况，还会发生什么异常情况？该如何应对？ 实地收集需求信息的方式实地收集需求信息的方式 19 交谈形式举例交谈形式举例 n正

13、向模拟：选择典型业务情景（初始情况），请用户说明工 作过程；陈述过程中不断提炼并提问新情况 n案例分析：请用户选择有代表性的业务情景（初始情况）， 并说明工作过程；陈述过程中不断提炼并提问新情况 n局外评论：存在现有系统，请用户对正在进行的过程进行评 论 n知识反教：在获取一些信息后，按照自己的理解表述给用户 ，请用户判断正确与否 20 n问卷法调查法 是对面谈法的补充。 是从多个用户中收 集需求信息的有效方式 ，一般问卷设 计形式： 1）多项选择问题 ； 2）评分问题 ； 3）排序问题 。 实地收集需求信息的方式实地收集需求信息的方式 21 n需求专题讨论会 最有力的需求获取技术。有利于培养

14、高 效团队。 由开发方和用户方共同召开,操作步骤： 开发方根据双方制定的需求调研计划召开相关需求主 题沟通会； 会后开发方整理出需求调研记录提交给用户方确认； 如果此主题还有未明确的问题则再次沟通,否则开始下一 主题； 所有需求都沟通清楚后，开发方根据历次需求调研记录 整理出用户需求说明书，提交给用户方确认签字。 会前发议题，控制参会人员规模、时间、讨论范围，会中 有记录，会后整理。掌握方向不跑题。 实地收集需求信息的方式实地收集需求信息的方式 22 需求信息的分类需求信息的分类 如图列出9种需求类别： 解决方案建议 业务需求 用例或场景 业务规则 功能性需求 质量属性 外部接口需求 数据定义

15、 约束 23 业务规则（领域需求）业务规则（领域需求） 当客户说只有特定的人在特定的条件下才能执行某一动作时，他也许是在描述 一条业务规则。业务规则举例： n 产品必须符合某项国际（或国家）标准。 n 必须根据（某个公式）计算。 n 如果（满足某一条件），则（进行某事）。 功能性需求 功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用 户执行的操作。如：所有的用户界面操作都属于功能性需求。 功能性需求占据了软件需求规格说明的大部分篇幅。 24 质量属性质量属性 产品的易用性、可靠性、运行速度、出错频率、异常处理 能力等等特性合称为质量属性，它是系统非功能性需求的 一部分。非功能

16、需求是衡量软件能否良好运行的定性指标。举 例： n 可靠性：规定条件下系统完成所要求功能的概率。定量指标 如平均无故障时间和平均修复时间。 n 可扩充性：系统能方便和容易地增加新功能，可用增加新功 能所需工作量大小来衡量。 n 安全性：如防止非法访问,防止数据丢失，防止病毒入侵等 。例如：身份验证、用户权限、访问控制等。 25 n互操作性：指系统与其他系统交换数据和服务的难易程度。 n健壮性：指系统或组成部分遇到非法输入数据以及在异常情况和非法 操作下能继续运行的程度。 n易用性：指用户学习和使用软件系统功能的简易程度,也包括对系统 输出结果的易于理解的程度。 n可维护性：指系统中发现并纠正一

17、个故障或进行一次更改的简易程度 。 n可移植性：指把一个软件系统从一种运行环境移植到另一个运行环境 所花费的工作量的度量。 n可重用性：指组成软件系统中的某个部件还可以在其他应用系统中使 用的程度。 质量属性质量属性 26 外部接口需求 描述了系统与外部世界的联系。软件需求规格说明中专门有一 章描述系统与用户、硬件、其它软件系统之间接口的说明。 27 约束约束 对设计和实现的约束合理地限制了开发人员可用的选择。如 ： n 通过电子邮件传送的文件大小不能超过10MB。 n 进行安全交易时，必须使用128位的加密算法。 n 产品数据库必须支持Oracle 11g 期末大作业之一：假设让你开发一个在

18、线交易 平台网站，分别从功能需求，质量特性，约束3 种需求类别进行描述。 28 3.2 3.2 需求分析需求分析 需求分析和需求获取是密切相关的两个过程。需求分析的任 务就是分析和综合通过需求获取阶段收集到的需求信息，提 炼出真正的需求，确保所有参加人员取得一致共识。找出错 误、遗漏和不足，建立系统完整的逻辑模型。 n需求分析是一种提炼与整合活动：需将用户的原始需求合 并到业务活动中去。 n需求分析是一种规格化活动：要找到冲突、矛盾，并通过 访谈手段解决问题。 29 划分需求优先级的用处： n可帮助判断系统的核心需求，可用于风险分析。 n优先级之间的关联可以帮助决定软件体系结构、解决设计冲突。

19、 n帮助权衡项目范围、进度安排、预算、人力资源及质量目标要求。 使用方法：接受一个高优先级的需求时，删除低优先级的需求，或将其推 迟到下一版去实现。 3.2 3.2 需求分析需求分析 30 3.3 3.3 需求建模需求建模 目的：需求建模的工作就是导出目标系统的逻辑模型，以明确目标系统“ 做什么”的问题。 定义：所谓模型就是为了理解事务而对事物做出的一种抽象，是对事物的 一种无歧义的书面描述。 组成：通常模型可由图形符号或数字符号以及组织这些符号的规则组成。 注意：建立需求模型的目的是为了增强对用自然语言描述的需求规格说明 的理解，而不是替换它。 31 软件工程中常用模型分类 开发过程模型：瀑

20、布、增量、螺旋模型等(规约性) 信息流模型：DFD、SADT等(描述性) 设计模型：类图、功能层次图等 交互作用模型：实例图、交互作用图、时序图等 状态迁移模型：状态图、Statecharts、Petri网等 用于构造细节的原理模型：设计模式、实体关联图等 3.3 3.3 需求建模需求建模 32 3.4 3.4 需求文档需求文档 规格说明规格说明(SRS)(SRS) l通常用自然语言+模型，完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要求、出 错处理需求、接口需求、约束、逆向需求以及将来可能提 出的要求。 l软件需求规格说明书，是需求分析阶段得出的最主要的文 档。

21、 l需求规格说明书的作用在于： 提供一个用户和开发者对开发软件的共同的理解； 相当于用户和开发单位之间的一份技术合同； 是今后各阶段设计的基本依据，起到控制系统演进的作 用； 是今后验收测试阶段对软件进行确认和验收的基准。 33 3.43.4需求文档需求文档 需求规格说明书主要内容： 概述。从系统的角度描述软件的目标和任务。 数据描述 数据流图 数据字典 系统接口说明 内部接口说明 功能描述 功能 处理 设计的限制 34 3.4 3.4 需求文档需求文档 性能描述 性能指标 测试种类 预期的软件响应性能 其它 参考文献目录 附录 35 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1

22、.4 参考资料 2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束 软件需求说明书的编写提示（GB856T88） 36 软件需求说明书的编写提示（GB856T88） 3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求 4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制 37 (一) 需求验证的重要性 l需求审查和管理复审是需求开发的最后一个环节，通过了这一环节， 就等于暂时为需求分析阶段画上了

23、一个“句号”。尽管后期可能还会有 些对需求分析的反复，但有了这个“句号”，就可以进入设计阶段了。 l经过审批之后的文档，在整个项目范围内，相当于用户与开发人员双 方对需求达成共识后作出承诺形成了一份合约，后期的系统设计和系统 测试，都将以这份“规约”为准。 l任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要 经过严格的审批和签约。 软件软件 设计设计 软件软件 编码编码 软件软件 测试测试 运行运行 维护维护 软件软件 需求需求 做什么做什么 怎么做怎么做 3.5 3.5 需求的有效性验证需求的有效性验证 38 (二) 需求验证的内容 1.有效性检查指功能需求是否符合用户所提出的需

24、求 2.一致性检查需求文档中各个需求之间不会发生矛盾。矛盾常常潜伏在需 求文档的上下文中。 3.完备性检查是指需求规约中没有遗漏一些必要的需求。人们往往倾向于 关注系统的特色功能，而忽视了其他一些不起眼的但却是必需的功能。不完 备的文档将导致产生功能不完整的产品，用户在使用该软件时可能无法完成 预期的任务。 4.可检验性检查文档中的各项需求对用户方而言都应当是可验证的。如果 需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。 例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之 ，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造 个十二级台风来试验？如

25、果双方都认可“采用计算机模拟十二级台风”等效 于实际测试，那么这项需求就是“可验证”的。 3.5 3.5 需求的有效性验证需求的有效性验证 39 (二) 需求验证的内容 5.必要性检查需求规格说明书中的各项需求对用户而言应当都是必 要的。 可以把必要比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添 足”要么是“锦上添花”。 “画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工 作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。 “锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼 前用户不会为此多付钱。开发者应当集中精力先完成必要的需求， 如果条件允许则再做“锦上添

26、花”的需求。为了避免主次颠倒，应当 在需求规约中将那些“锦上添花”的需求设置为较底的优先级。 3.5 3.5 需求的有效性验证需求的有效性验证 40 用户的需求分类用户的需求分类 n基本的需求：用户明确提出的系统应达到的目标，如果产品 实现了这些需求，用户会感到满意。例如，用户所要求的图 形界面的类型，特定的系统功能，以及指定的性能。 n期望的需求：这些需求隐含于产品或系统中，用户没有明确 的陈述。但如果没有实现这些需求，用户会感到失望。例如 产品的易于安装，超负载时的正确性和可靠性等。 n感兴趣的需求：这些需求在用户的期望之外，但如果被实现 了，用户会感到非常满意。例如字处理软件除了标准的特

27、性 之外，提供了许多页面的排列功能。 41 3.63.6需求管理需求管理 需求管理需要“建立并维护在软件工程中同客户达成的契约 ”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明 与模型中， 需求管理贯穿需求分析全过程 通常的需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）。 所谓的基线是配置演化过程中的状态标识，是配置在某一时刻 的快照，反映了它所描述的系统或者其组成部分在某一时刻的 状态；可以将配置的基线理解为配置的版本，是配置演化的里 程碑，即软件生命周期内的阶段里程碑。 所谓需求基线就是项目组成员一经承诺将在某一特定产品版本 中实现的功能性和非功能性需求的集合

28、。需求基线的确定可以 保证项目的涉众各方可以对发布的产品中希望具有的功能和属 性有一个一致的理解。 42 3.63.6需求管理需求管理 评审提出的需求变更、评估每项变更的可能影响 从而决定是否实施它。以一种可控制的方式将需求 变更融入到项目中。 1)随着项目的进展，人们（包括开发方和客户方） 对需求的了解越来越深入。原先的需求文档可能存 在这样那样的错误或不足，因此要变更需求。 2)市场发生了变化，原先的需求文档可能跟不上当 前的市场需求，因此要变更需求。 43 (3)让每项需求都能与其对应的设计、源代码和测试用例 联系起来以实现跟踪。 需求跟踪的目的是建立与维护“需求设计编程测试 ”之间的一

29、致性，确保所有的工作成果符合用户需求。 需求跟踪有两种方式: 正向跟踪：检查产品需求规格说明书中的每个需求是 否都能在后继工作成果中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工作成果是 否都能在产品需求规格说明书中找到出处。 3.6 3.6 需求管理需求管理 44 3.6 3.6 需求管理需求管理 45 需求变更控制需求变更控制 案例 n王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一 定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的 需求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相 当满意。 n但需求变

30、更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而 是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关 文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人 能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置 管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知 此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了 耐心”。 n而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异 常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了

31、这个问题， 但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担 心系统中还隐含着其他类似的错误,公司高层对项目的质量也疑虑重重。 n随后发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并 为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一方，于是保持了沉 默。最终客户决定调整所有界面， 王先生只好立刻动员大家抓紧时间修改。可后来 当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非 常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不 会让你改呢！”王先生委屈极了，疑惑自己到底错在哪里了。 47 需

32、求活动之间关系需求活动之间关系 需求获取 和分析 需求描述 需求有效 性验证 系统模型用户需求和 系统需求 需求规约 软件需求过程 需求管理 48 3.7 3.7 结构化分析方法结构化分析方法 n n 结构化分析结构化分析（Structured AnalysisStructured Analysis，SASA）由美国）由美国YOURDONYOURDON公公 司提出。司提出。 n n 采用自顶向下、逐层进行功能分解的系统分析方法来定义系采用自顶向下、逐层进行功能分解的系统分析方法来定义系 统的需求。统的需求。 n n 适用于分析大型的数据处理系统。适用于分析大型的数据处理系统。 n n 方法的特

33、点：方法的特点：利用数据流图（利用数据流图（Data Flow DiagramData Flow Diagram，DFDDFD）来）来 帮助理解问题，对问题进行分析。帮助理解问题，对问题进行分析。 n n 一般工具：一般工具：DFDDFD、数据字典、判定表、判定树等。、数据字典、判定表、判定树等。 功能分析工具：功能分析工具：DFDDFD、DDDD、判定表和判定树。、判定表和判定树。 数据分析工具：数据分析工具：ERER图或者图或者EEREER（扩展（扩展ERER）图。）图。 行为分析工具：行为分析工具：状态迁移图、状态迁移图、PetriPetri网等。网等。 SASA主要针对数据处理领域，因

34、此，系统分析的侧重点在主要针对数据处理领域，因此，系统分析的侧重点在 于功能分析和数据分析，而行为分析使用得较少。于功能分析和数据分析，而行为分析使用得较少。 49 n n 结构化分析方法的一些弊病：结构化分析方法的一些弊病： 1.1.基于功能分析和数据分析，将功能和数据分离，与基于功能分析和数据分析，将功能和数据分离，与 人类现实世界环境不一样，和人的自然思维也就不人类现实世界环境不一样，和人的自然思维也就不 一致了。一致了。 2.2.以功能为主，数据只是被动的信息载体。当系统行以功能为主，数据只是被动的信息载体。当系统行 为发生变化时，系统维护非常困难。为发生变化时，系统维护非常困难。 3

35、.3.DFDDFD中不涉及系统的控制信息，因此，中不涉及系统的控制信息，因此，SASA不适合于不适合于 分析以控制信息为主的系统需求。分析以控制信息为主的系统需求。 3.7 3.7 结构化需求分析结构化需求分析 50 分解：对于一个复杂的系统，为了将复 杂性降低到可以掌握的程度，可以把大问 题分解成若干小问题，然后分别解决（如 右图）。 一、一、SASA法的基本思想法的基本思想 “分解”和“抽象” 抽象：分解可以分层进行，即先考虑问题最本质的属性，暂 把细节略去,以后再逐层添加细节，直至涉及到最详细的内容 ，这种用最本质的属性表示一个系统的方法就是“抽象”。 1.1 1.21.3 x 2 13

36、 2.1 2.2 2.3 1.1 1.3 3.7 3.7 结构化需求分析结构化需求分析 51 三、三、SASA法的描述方法法的描述方法 1、分层的数据流图（DFD图） 2、数据词典 3、描述加工逻辑的结构化语言、判定表及判定树 二、二、SASA法的步骤法的步骤 当前系统 具体模型 建立 当前系统 逻辑模型 抽象 目标系统 逻辑模型 建立 完善的系统 逻辑模型 改进 深入调查 研究 分析用户需求, 用DFD图描述 分析系统需求, 用DFD图描述 修改完善DFD 图,增添功能 3.7 3.7 结构化需求分析结构化需求分析 52 3.7 3.7 结构化需求分析结构化需求分析 四、四、SASA总结总结

37、 n n 软件系统开发中的结构化分析方法就是面向数据流自顶软件系统开发中的结构化分析方法就是面向数据流自顶 向下逐步求精的需求分析方法。通过可行性研究已经得向下逐步求精的需求分析方法。通过可行性研究已经得 出了目标系统的高层数据流图，需求分析的目标之一就出了目标系统的高层数据流图，需求分析的目标之一就 是把数据流和数据存储定义到元素级。是把数据流和数据存储定义到元素级。 n n 要达到此目的，一般从数据流图的输出端入手，这是因要达到此目的，一般从数据流图的输出端入手，这是因 为系统的基本功能是产生这些输出，输出数据决定了系为系统的基本功能是产生这些输出，输出数据决定了系 统必须具有的最基本的组

38、成元素。统必须具有的最基本的组成元素。 53 3.83.8分析建模分析建模 3.8.1 3.8.1 建立模型建立模型 模型 -就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧 义的书面描述。通常，由一组图形符号和组织这些符号的规则组成 。 -模型将作为软件设计的基础和编写软件规格说明的依据。一般的说模型将作为软件设计的基础和编写软件规格说明的依据。一般的说 明，在需求分析阶段要写出详细的规格说明是不可能的。因为，用明，在需求分析阶段要写出详细的规格说明是不可能的。因为，用 户对什么是正确的需求没有把握，开发人员对怎样正确的完成所要户对什么是正确的需求没有把握，开发人员对怎样正确的完成

39、所要 取得功能和性能也没把握，所以需求分析选择模型开发方法。取得功能和性能也没把握，所以需求分析选择模型开发方法。 需求分析过程应该建立需求分析过程应该建立3 3种模型：种模型： n n 数据模型数据模型：实体联系图，描绘数据及数据对象之间的关系。：实体联系图，描绘数据及数据对象之间的关系。 n n 功能模型功能模型：数据流图，描绘当数据在软件系统中移动时被变换的逻：数据流图，描绘当数据在软件系统中移动时被变换的逻 辑过程。辑过程。 n n 行为模型行为模型：状态转换图，描绘系统各种行为模式和在不同状态间的：状态转换图，描绘系统各种行为模式和在不同状态间的 转换。转换。 54 概念模型和规范化

40、概念模型和规范化 软件系统的整个开发过程都必须考虑两方面的问题软件系统的整个开发过程都必须考虑两方面的问题 ：“ “数据数据” ”及对数据的及对数据的“ “处理处理” ”。为了把用户的数据要。为了把用户的数据要 求清晰明确的表达出来，系统分析员要建立概念性求清晰明确的表达出来，系统分析员要建立概念性 的数据模型（也称信息模型），它也是一种面向问的数据模型（也称信息模型），它也是一种面向问 题的数据模型，是按用户的观点来对数据和信息建题的数据模型，是按用户的观点来对数据和信息建 模。模。 采采用的方法是：实体联系方法（用的方法是：实体联系方法（EntityEntity Relationship

41、ApproachRelationship Approach）即）即E ER R模型。模型。 55 l表示概念模型最常用的是实体联系方法（entity -relationship approach）。该方法用ER图 (ER模型或实体联系模型)来描述。它是描述概 念世界、建立概念模型的实用工具。 lE-R模型独立于具体的计算机系统。E-R模型的主要 成分是实体、联系和属性。它用简单的图形反映了 现实世界中存在的事物或数据及它们之间的关系。 lE-R模型独立于具体的计算机系统。E-R模型的主要 成分是实体、联系和属性。它用简单的图形反映了 现实世界中存在的事物或数据及它们之间的关系。 实体联系模型实

42、体联系模型 56 1.实体：客观存在并且相互区别的事物称为实体 2.实体属性：实体所具有的某一特性称为属性。一个实 体可以由若干个属性来刻画。 3.实体集和实体型：属性值的集合表示一个实体，实体 名和各个属性名的集合来抽象和描述同类实体称为实体 型(Entity type)。同类型的实体的集合称为实体集(有 时也把它直接称为实体)。 学生1(学号、姓名、性别、出生日期、系别、籍贯) 实体属性 实体集 实体型 学生2(学号、姓名、性别、出生日期、系别、籍贯) 学生n(学号、姓名、性别、出生日期、系别、籍贯) 实体联系模型实体联系模型 57 n实体集之间的对应关系称为联系，反映现实世界各种事物之

43、间的相互关联，一般有以下三种联系。 （1） 一对一联系（1:1） 如果对于实体集A中的每一个实体，实体集B中至多有一 个实体与之对应；反之亦然，则称A与B具有一对一联系。 （2） 一对多联系（1:n） 如果对于实体集A中的每一个实体，实体集B中有n个实体 （n0）与之对应；反之，对于实体集B中的每一个实体,实 体集A中至多只有一个实体与之对应，则称A与B具有一对多 联系。 （3）多对多联系（m:n） 如果对于实体集A中的每一个实体，实体集B中有n个实体 （n0）与之对应；反之，对于实体集B中的每一个实体,实 体集A中也有m个实体（m0）与之对应，则称A与B具有多对 多联系。 部门经理部门 部门

44、经理职工 职工工作项目 实体联系模型实体联系模型 58 l一对一联系是一对多联系的特例，一对多联系又是多对多联系的 特例。 l概念模型和各种数据模型(层次模型除外)均不支持多对多联系，只 支持一对一联系或一对多联系。 l在复杂问题中，两个以上的实体集之间也往往存在一对一、一对 多或多对多联系。多对多联系直接处理起来很困难，通常是将多 对多联系转化为两个一对多联系来处理。 l联系本身也是一种实体型（如老师-学生的联系就是上课，而上课 又具有上课时间，地点，课程名等属性），也可以有属性。 实体联系模型实体联系模型 59 在ER图中，实体、属性和联系的表示方法如下： (1) 实体型：用矩形表示，矩形

45、框内写实体名； (2) 属性：用椭圆表示，并用无向线段与相应的实体 连接； (3) 联系：用菱形表示，菱形框内写明联系名，并用 无向线段与有关的实体连接。同时在无向线段旁 标上联系的类型（1：1，1：n或m：n）。联系本 身也是一种实体型，也可以有属性。如果一个联 系有属性，也用无向线段将属性与该联系连接。 实体联系模型实体联系模型 60 软件教研室信息学院 (a)1:1联系 (b)1:n联系 (c)m:n联系 两个实体之间的三类联系 软件教研室 实体联系模型实体联系模型 61 学生实体、课程实体及其属性 将多对多联系转化为一对多联系的一般方法是：增加 一个新的实体集，并且这个新的实体集和原来

46、的两个 实体集之间都是一对多联系。 实体联系模型实体联系模型 62 教学信息管理概念模型 成绩 考分 实体联系模型实体联系模型 考考 选选 63 数据流图数据流图DFD - Data Flow Diagram DFD - Data Flow Diagram （功能模型）（功能模型） n一种图形化技术，它描绘信息流和数据从输入移动 到输出的过程中所经受的变换。 n在数据流图中没有任何具体的物理部件，它只是描 绘数据在软件中流动和被处理的逻辑过程，是系统 逻辑功能的图形表示。 n设计数据流图时只需考虑系统必须完成的基本逻辑 功能，完全不需要考虑怎样具体地实现这些功能， 所以它也是今后进行软件设计的

47、很好的出发点。 64 数据流图四种基本符号数据流图四种基本符号 数据加工数据加工/ /处理/ /变换变换 数据源点或终点数据源点或终点 ( (外部实体外部实体) ) 数据流数据流(data flow)(data flow) 数据存储文件数据存储文件 或 或 或 65 源或宿源或宿 n软件系统外部环境中的实体（包括人员、组织或其他软件 系统），统称为外部实体。表示软件系统输入数据的来源 和输出数据的去向，一般只出现在数据流图的顶层图中。 因此也称为源点和终点 n源或宿用相同的图形符号表示 当数据流从该符号流出时表示是源 当数据流流向该符号时表示是宿 当两者皆有时表示既是源又是宿 66 加工加工

48、n加工：也称为数据处理，它对数据流进行某些操作或变 换。描述了输入数据流到输出数据流的变换，即将输入 数据流加工成输出数据流。每个加工也要有名字，通常 是动词短语，简明地描述完成什么加工。在分层的数据 流图中，加工还应有编号。 每个加工用一个定义明确的名字标识 至少有一个输入数据流和一个输出流 可以有多个输入数据流和多个输出数据流 67 文件文件 n文件：保存数据信息的外部单元。使用文件、数据库等 保存某些数据结果供以后使用。流向数据存储的数据流 可理解为写入文件，或查询文件，从数据存储流出的数 据可理解为从文件读数据或得到查询结果。 每个文件用一个定义明确的名字标识 由加工进行读写 DFD中

49、称为文件，但在具体实现时可以用文件系统实 现也可以用数据库系统等实现 注意: 数据存储和数据流都是数据,仅仅所处的状态不同。数据存 储是处于静止状态的数据，数据流是处于运行中的数据。 68 数据流数据流 n每个数据流用由一组固定成分的数据组成并拥有一 个定义明确的名字标识 如：运动会管理系统中，报名单(数据流)由队 名、姓名、性别、参赛项目等数据组成 n数据流的流向 从一个加工流向另一个加工 从加工流向文件(写文件) 从文件流向加工(读文件) 从源流向加工 从加工流向宿 注意：数据流和程序流程图中用箭头表示的控制流有本质不 同，在数据流图中应该描绘所有可能的数据流向，而不应该 描绘出现某个数据流的条件。 69 数据流图的扩充符号数据流图的扩充符号 描述一个加工的多个数据流之间的关系 70 数据流图的层次结构数据流图的层次结构 为了表达数据处理过程的数据加工情况