【文档说明】软件工程2章需求法分析33lin课件.ppt，共(114)页，861.096 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-44977.html

以下为本文档部分文字说明：

软件工程2章需求法分析33lin课件软件需求工程的活动（内容）软件需求工程需求开发需求管理需求建模需求获取需求规格说明需求验证建立基线变更控制需求跟踪综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：（

1）需求获取：深入实际，确定待开发的软件系统的用户类，通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；（2）需求分析及建模：主要对收集到的需求进行提炼、分析和认真审查，确保所有参加人员取得一致共识。找出错误、遗漏和不足

，为最终用户所看到的系统建立模型，根据软件需求信息建立软件系统的逻辑模型或需求模型。需求模型作为对需求的抽象描述，尽可能多的捕获现实世界的语义，并确定非功能性需求和约束条件和限制。（3）形成需求规格：根据收集的需求信息和逻辑模型生成需求模型构件的精确

的形式化的描述，作为用户和开发者之间的一个协约编写需求规格说明及其文档。（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；（5）需求管理：支持系统的

需求演进，如需求变化和可跟踪性问题。当需求发生变更时，对需求规格说明及需求变更实施进行管理。需求工程也是一个项目工程，因此也包括了项目的管理。软件需求工程的活动（内容）3.1需求获取需求获取是需求工程的主体内容之一。获取需求是一个确定和理解不同涉众的需要和约束的过程

。涉众团体(所有能够影响软件系统的实现,或者被实现后的软件系统所影响的个人和团体)之间的相互沟通，识别需要的过程。涉众团体通过这个过程提取、定义需求。需求获取既涉及技术问题，也涉及社会交往问题。难点：

缺乏领域知识,应用领域的问题常常是模糊的、不精确的；–存在默认的知识,如难以描述的常识问题；–存在多个知识源,且多知识源之间可能有冲突；–客户可能的偏见，如不能提供或不想告知你所需要了解的事情。在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。只有

用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，

必须与用户沟通获取用户对软件的需求3.1需求获取业务需求项目范围文档用户需求文档功能需求质量属性其他非功能需求设计约束需求规约(specification)非功能需求系统需求需求组成的全景图软件需求的层次•业务需求：反映组织机构

和客户对系统、产品高层次的目标要求。•用户需求：从用户使用的角度给出需求的描述。如一个小型超市需要一个商品的查询系统。业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。用户需求:这

三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。软件需求的层次•系统需求：从系统的角度描述要提供的服务以及所受到的约束。•功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务

。•非功能性需求：产品必须具备的属性或品质。•设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。软件需求的组成需求获取的过程：确定需求开发计划建立项目前景与范围确定调查对象实地收集用户需求信息确定非功能需求和约束条件1.确定需

求开发计划确定需求开发计划的基本任务是确定需求开发的实施步骤，给出收集需求活动的人员、具体安排和进度。需要重点注意的是：针对不同层次的调查对象，安排的调查人员在阅历和经验上的对等原则。调查人员的沟通和业务理解能力必须适当。用户的时间延误、文档确认的时间

要在计划进度中预留。2.确定产品前景与项目范围本阶段的任务是帮助投资管理人、产品经理弄清楚“为什么要作这个项目？”，组织的业务目标以及系统最终版本具备哪些功能的长远规划。产品前景（productvision）描述了产品用来干什么，它最终会是什么样子。项目范围（projectscope）确定当前

的项目要解决产品长远规划中的哪一部分。项目范围的细节体现于项目定义的需求基线。产生文档：前景与范围文档。前景与范围的关系前景关系到整个产品。当产品的战略定位或业务目标随时间发生改变时，前景也会变化。范围则只与一个

特定项目，或实现产品功能下一增量的某次迭代相关。产品前景包括了每一个计划产品版本的范围版本1.0的项目范围版本1.1的项目范围版本1.1的项目范围版本n的项目范围产品目录前景和范围文档的模板1.业务需求1.1背景1.2业务机遇1.3业务目标与成功标准1.4客户和市场需要1.5业务风险2.解决方案

的前景2.1前景陈述2.2主要的系统特征2.3假设和依赖条件3.项目范围与限制3.1第一个版本的范围3.2各后续版本的范围3.3限制和排除条件4.业务背景4.1涉众档案4.2项目优先级4.3运行环境3.确定调查对象本

阶段的基本任务是明确地确定来自不同层次的需求来源和用户，并将其分类。(前景与范围文档可以帮助区分用户分类)由于软件需求分为三个层次，业务需求、用户需求、功能需求，故应根据需求的层次来区分不同的用户。用户分类：可分为三种不同类别用户方的领导者、项目规划者、项目

出资人(目标)软件的直接使用、操作人员（功能,易用性）未来软件系统的技术管理、运行维护人员（性能,安装,维护）4.实地收集用户需求信息实地收集需求信息面临的困难1）能提出软件需求的用户没有时间2）有时用户希望

通过简单的说明和问答3）用户和开发人员只考虑自己的利益4）用户本身不能提出明确的需求5）开发人员缺乏用户的业务知识，而用户缺乏计算机方面的知识，引起交流困难。实地调查的步骤1）向掌握“全局”的负责人调查：概貌,规划,目标,范围2）向部门负责人调查：业务和业务流程

,部门间相互关系。功能需求和非功能需求,与其他部门间的接口。3）向业务人员调查：自身工作处理细节、具体数据或表格的作用来源和去向、类型、精度、处理要求和输入/输出格式。具体的功能和性能需求。2022/11/2417实地收集需求信息的方式需求获取可能是软件开发中最需要交流的

一项工作。获取涉众的需求是需求工作的重要环节。需求获取只有通过客户与开发者的有效合作才能成功。分析者必须为客户建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的产品有关。另外要让用户明确了解，对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，消除不必要的

需求，以避免项目范围无意义地膨胀。目前主要有以下的需求获取方法。面谈法重要而直接，简单的需求获取技术。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。提问题：a.你所在部门的业务流程是怎样的？b.你所在部门与其

它部门的关系是怎样的？c.本部门产生哪些表格及其输入/输出形式？d.在业务中使用什么计算方法？关于如何解决问题的提问：a.当某问题发生时，应该如何解决？b.你现在工作中存在什么问题？如何解决？c.除了正常情况，还会发生什么异常

情况？该如何应对？实地收集需求信息的方式交谈形式举例正向模拟：选择典型业务情景（初始情况），请用户说明工作过程；陈述过程中不断提炼并提问新情况案例分析：请用户选择有代表性的业务情景（初始情况），并说明工作过程；陈述过程

中不断提炼并提问新情况局外评论：存在现有系统，请用户对正在进行的过程进行评论知识反教：在获取一些信息后，按照自己的理解表述给用户，请用户判断正确与否问卷法调查法是对面谈法的补充。是从多个用户中收集需

求信息的有效方式，一般问卷设计形式：1）多项选择问题；2）评分问题；3）排序问题。实地收集需求信息的方式需求专题讨论会最有力的需求获取技术。有利于培养高效团队。由开发方和用户方共同召开,操作步骤：①开发方根据双方制定的《需求调研计划》召开相关需

求主题沟通会；②会后开发方整理出《需求调研记录》提交给用户方确认；③如果此主题还有未明确的问题则再次沟通,否则开始下一主题；④所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。会前发议题，控制参会人员规模、时间、讨论范围，会中有记录，会后

整理。掌握方向不跑题。实地收集需求信息的方式需求信息的分类如图列出9种需求类别：解决方案建议业务需求用例或场景业务规则功能性需求质量属性外部接口需求数据定义约束业务规则（领域需求）当客户说只有特定的人在特定的条件下才能执行某一动作时，他也许是在描述一条业务规则。业务规则举

例：产品必须符合某项国际（或国家）标准。必须根据（某个公式）计算。如果（满足某一条件），则（进行某事）。功能性需求功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用户执行的操作。如：所

有的用户界面操作都属于功能性需求。功能性需求占据了软件需求规格说明的大部分篇幅。质量属性产品的易用性、可靠性、运行速度、出错频率、异常处理能力……等等特性合称为质量属性，它是系统非功能性需求的一部分。非功能需求是衡量软件能否良好运行的定性指标。举例：可靠性：

规定条件下系统完成所要求功能的概率。定量指标如平均无故障时间和平均修复时间。可扩充性：系统能方便和容易地增加新功能，可用增加新功能所需工作量大小来衡量。安全性：如防止非法访问,防止数据丢失，防止病毒入侵等。例如：身份验证、用户

权限、访问控制等。互操作性：指系统与其他系统交换数据和服务的难易程度。健壮性：指系统或组成部分遇到非法输入数据以及在异常情况和非法操作下能继续运行的程度。易用性：指用户学习和使用软件系统功能的简易程度,也包括对系统输出结果的易于理解的程度。可维护性

：指系统中发现并纠正一个故障或进行一次更改的简易程度。可移植性：指把一个软件系统从一种运行环境移植到另一个运行环境所花费的工作量的度量。可重用性：指组成软件系统中的某个部件还可以在其他应用系统中使用的程度。质量属性外部接口需求描述了系统与外部世界的联系。软件需求

规格说明中专门有一章描述系统与用户、硬件、其它软件系统之间接口的说明。约束对设计和实现的约束合理地限制了开发人员可用的选择。如：通过电子邮件传送的文件大小不能超过10MB。进行安全交易时，必须使用128位的加密算法。产品数据库必须支持Oracle11g期末大作业之

一：假设让你开发一个在线交易平台网站，分别从功能需求，质量特性，约束3种需求类别进行描述。3.2需求分析需求分析和需求获取是密切相关的两个过程。需求分析的任务就是分析和综合通过需求获取阶段收集到的需求信息，提炼出真正的需求，确保所有参加人员取得一致共识。找出错误、遗漏和

不足，建立系统完整的逻辑模型。需求分析是一种提炼与整合活动：需将用户的原始需求合并到业务活动中去。需求分析是一种规格化活动：要找到冲突、矛盾，并通过访谈手段解决问题。划分需求优先级的用处：可帮助判断系统的核心需求，可用于风险分析。

优先级之间的关联可以帮助决定软件体系结构、解决设计冲突。帮助权衡项目范围、进度安排、预算、人力资源及质量目标要求。使用方法：接受一个高优先级的需求时，删除低优先级的需求，或将其推迟到下一版去实现。3.2需求分析3.3需求建模目的：需求建模的工作就是导出目标系统的逻辑模型，

以明确目标系统“做什么”的问题。定义：所谓模型就是为了理解事务而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。组成：通常模型可由图形符号或数字符号以及组织这些符号的规则组成。注意：建立需求模型的目的

是为了增强对用自然语言描述的需求规格说明的理解，而不是替换它。软件工程中常用模型分类开发过程模型：瀑布、增量、螺旋模型等(规约性)信息流模型：DFD、SADT等(描述性)设计模型：类图、功能层次图等交

互作用模型：实例图、交互作用图、时序图等状态迁移模型：状态图、Statecharts、Petri网等用于构造细节的原理模型：设计模式、实体关联图等3.3需求建模3.4需求文档规格说明(SRS)通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、

功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。软件需求规格说明书，是需求分析阶段得出的最主要的文档。需求规格说明书的作用在于：①提供一个用户和开发者对开发软件的共同的理

解；②相当于用户和开发单位之间的一份技术合同；③是今后各阶段设计的基本依据，起到控制系统演进的作用；④是今后验收测试阶段对软件进行确认和验收的基准。3.4需求文档需求规格说明书主要内容：⑴概述。从系统的角度描述软件的目标和任务。

⑵数据描述①数据流图②数据字典③系统接口说明④内部接口说明⑶功能描述①功能②处理③设计的限制3.4需求文档⑷性能描述①性能指标②测试种类③预期的软件响应性能④其它⑸参考文献目录⑹附录1引言1.1编写目的1.2背景1.3定义1.4参考资料2任务概述2.1目标2.2用户的特点2.3假定和约束软件需求说

明书的编写提示（GB856T—88）软件需求说明书的编写提示（GB856T—88）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控制(一)需求验证的重要性需求审查和管理复审是需求开发的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画上了一个“句号”。尽管后期可能还会有些对需求分析的反复，但有了这个“句号”，就可以进入设计阶段了。经过审批之后的文

档，在整个项目范围内，相当于用户与开发人员双方对需求达成共识后作出承诺形成了一份合约，后期的系统设计和系统测试，都将以这份“规约”为准。任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。软件设计软件编码软件测试运行维护

软件需求做什么怎么做3.5需求的有效性验证(二)需求验证的内容1.有效性检查—指功能需求是否符合用户所提出的需求2.一致性检查—需求文档中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。3.完备性检查—是指

需求规约中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其他一些不起眼的但却是必需的功能。不完备的文档将导致产生功能不完整的产品，用户在使用该软件时可能无法完成预期的任务。4.可检验性检查—文档中的各项需求对用户方而言都

应当是可验证的。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果

双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。3.5需求的有效性验证(二)需求验证的内容5.必要性检查—需求规格说明书中的各项需求对用户而言应当都是必要的。可以把必要比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦

上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条

件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在需求规约中将那些“锦上添花”的需求设置为较底的优先级。3.5需求的有效性验证用户的需求分类基本的需求：用户明确提出的系统应达到的目标，如果产品实现了这些需求，用户会感到满意。例如，用

户所要求的图形界面的类型，特定的系统功能，以及指定的性能。期望的需求：这些需求隐含于产品或系统中，用户没有明确的陈述。但如果没有实现这些需求，用户会感到失望。例如产品的易于安装，超负载时的正确性和可靠性等。感兴趣的需求：这些需求在用户的期望之外，但

如果被实现了，用户会感到非常满意。例如字处理软件除了标准的特性之外，提供了许多页面的排列功能。3.6需求管理需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI2019)。这种契约都包

含在编写的需求规格说明与模型中，需求管理贯穿需求分析全过程通常的需求管理活动包括：⑴定义需求基线（迅速制定需求文档的主体）。所谓的基线是配置演化过程中的状态标识，是配置在某一时刻的快照，反映了它所描述的系统或者

其组成部分在某一时刻的状态；可以将配置的基线理解为配置的版本，是配置演化的里程碑，即软件生命周期内的阶段里程碑。所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证

项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。3.6需求管理⑵评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。1)随着项目的进展，人们（包括开发方和客户

方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。2)市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。(3)让每项需求都能与其对应的设计、源代码和测试用例联

系起来以实现跟踪。需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式:正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点

。逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。3.6需求管理3.6需求管理需求变更控制案例王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需

求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而

不做任何记录，很多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改

好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下

的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误,公司高层对项目的质量也疑虑重重。随后发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻

动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”王先生委屈

极了，疑惑自己到底错在哪里了。需求活动之间关系需求获取和分析需求描述需求有效性验证系统模型用户需求和系统需求需求规约软件需求过程需求管理3.7结构化分析方法结构化分析（StructuredAnalysis，SA）由美国YOURDON公司提出。采用自顶向下、逐层进

行功能分解的系统分析方法来定义系统的需求。适用于分析大型的数据处理系统。方法的特点：利用数据流图（DataFlowDiagram，DFD）来帮助理解问题，对问题进行分析。一般工具：DFD、数据字典、判定表、判定树等。–功

能分析工具：DFD、DD、判定表和判定树。–数据分析工具：ER图或者EER（扩展ER）图。–行为分析工具：状态迁移图、Petri网等。–SA主要针对数据处理领域，因此，系统分析的侧重点在于功能分析和数据分析，而行为分析使用得较少。结构化分析方法的一些

弊病：1.基于功能分析和数据分析，将功能和数据分离，与人类现实世界环境不一样，和人的自然思维也就不一致了。2.以功能为主，数据只是被动的信息载体。当系统行为发生变化时，系统维护非常困难。3.DFD中不涉及系统的

控制信息，因此，SA不适合于分析以控制信息为主的系统需求。3.7结构化需求分析分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决（如右图）。一、SA法的基本思想——―分解”和“抽象”抽象：分解可以分层进行，即先考虑问

题最本质的属性，暂把细节略去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。1.11.21.3x2132.12.22.31.11.33.7结构化需求分析三、SA法的描述方法1、分层的

数据流图（DFD图）2、数据词典3、描述加工逻辑的结构化语言、判定表及判定树二、SA法的步骤当前系统具体模型建立当前系统逻辑模型抽象目标系统逻辑模型建立完善的系统逻辑模型改进深入调查研究分析用户需求,用DF

D图描述分析系统需求,用DFD图描述修改完善DFD图,增添功能3.7结构化需求分析3.7结构化需求分析四、SA总结软件系统开发中的结构化分析方法就是面向数据流自顶向下逐步求精的需求分析方法。通过可行性研

究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。要达到此目的，一般从数据流图的输出端入手，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。3.8分析建模3.8.1建立模型模型

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

人员对怎样正确的完成所要取得功能和性能也没把握，所以需求分析选择模型开发方法。需求分析过程应该建立3种模型：数据模型：实体－联系图，描绘数据及数据对象之间的关系。功能模型：数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程。行为模型：状态转换图，描绘系统各种行为模式和在

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

用的方法是：实体－联系方法（Entity—RelationshipApproach）即E－R模型。表示概念模型最常用的是实体―联系方法（entity-relationshipapproach）。该方法用E―R图

(E―R模型或实体联系模型)来描述。它是描述概念世界、建立概念模型的实用工具。E-R模型独立于具体的计算机系统。E-R模型的主要成分是实体、联系和属性。它用简单的图形反映了现实世界中存在的事物或数据及它们之间的关系。E-R模型独立于具体的计算机系统。E-R模型

的主要成分是实体、联系和属性。它用简单的图形反映了现实世界中存在的事物或数据及它们之间的关系。实体联系模型1.实体：客观存在并且相互区别的事物称为实体2.实体属性：实体所具有的某一特性称为属性。一个实体可以由若干个属性

来刻画。3.实体集和实体型：属性值的集合表示一个实体，实体名和各个属性名的集合来抽象和描述同类实体称为实体型(Entitytype)。同类型的实体的集合称为实体集(有时也把它直接称为实体)。学生1(学号、姓名、性别、出生日期、系别、籍贯)实体属性实体集实体型学生2(学号、姓名、性别、出生日期

、系别、籍贯)学生n(学号、姓名、性别、出生日期、系别、籍贯)实体联系模型实体集之间的对应关系称为联系，反映现实世界各种事物之间的相互关联，一般有以下三种联系。（1）一对一联系（1:1）–如果对于实体集A中的每一个实体，实

体集B中至多有一个实体与之对应；反之亦然，则称A与B具有一对一联系。（2）一对多联系（1:n）–如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之对应；反之，对于实体集B中的每一个实体,实体集A中至多只有一个实体与之对应，则称A与B具有一对多联系。（3）多对多联系（m

:n）–如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之对应；反之，对于实体集B中的每一个实体,实体集A中也有m个实体（m≥0）与之对应，则称A与B具有多对多联系。部门经理部门部门经理职工职工工作项目实体联系模型一对一联系是一对多联系

的特例，一对多联系又是多对多联系的特例。概念模型和各种数据模型(层次模型除外)均不支持多对多联系，只支持一对一联系或一对多联系。在复杂问题中，两个以上的实体集之间也往往存在一对一、一对多或多对多联系。多对多联系直接处理起来很困难，通常是将

多对多联系转化为两个一对多联系来处理。联系本身也是一种实体型（如老师-学生的联系就是上课，而上课又具有上课时间，地点，课程名等属性），也可以有属性。实体联系模型在E―R图中，实体、属性和联系的表示方法如下：(1)实体型：用矩形表示，矩形框内写实体名；(2)属性：用椭圆表示，并用无向线段与相应

的实体连接；(3)联系：用菱形表示，菱形框内写明联系名，并用无向线段与有关的实体连接。同时在无向线段旁标上联系的类型（1：1，1：n或m：n）。联系本身也是一种实体型，也可以有属性。如果一个联系有属性，也用无向线段将属性与该联系连接。实体

联系模型软件教研室信息学院(a)1:1联系(b)1:n联系(c)m:n联系两个实体之间的三类联系软件教研室实体联系模型学生实体、课程实体及其属性将多对多联系转化为一对多联系的一般方法是：增加一个新的实体集，并且这个新的实体集和原来的两个实体集之间都是一对多联系。实体联系模型教学信息管

理概念模型成绩考分实体联系模型考选数据流图DFD----DataFlowDiagram（功能模型）一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在

软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。数据流图四种基本符号数据加工/处理/变

换数据源点或终点(外部实体)数据流(dataflow)数据存储文件或或或源或宿软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体。表示软件系统输入数据的来源和输出数据的去向，一般只出现在数据流图的顶层图中。因此也称为源点和终点源或宿用相同的图形

符号表示–当数据流从该符号流出时表示是源–当数据流流向该符号时表示是宿–当两者皆有时表示既是源又是宿加工加工：也称为数据处理，它对数据流进行某些操作或变换。描述了输入数据流到输出数据流的变换，即将输入数据流加工成输出数据流。每个加工也要有名字，通常是动词短语，简明地描述完成什么加工。在

分层的数据流图中，加工还应有编号。–每个加工用一个定义明确的名字标识–至少有一个输入数据流和一个输出流–可以有多个输入数据流和多个输出数据流文件文件：保存数据信息的外部单元。使用文件、数据库等保存某些数据结果供以后使用。流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可

理解为从文件读数据或得到查询结果。–每个文件用一个定义明确的名字标识–由加工进行读写–DFD中称为文件，但在具体实现时可以用文件系统实现也可以用数据库系统等实现注意:数据存储和数据流都是数据,仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运行中的数据

。数据流每个数据流用由一组固定成分的数据组成并拥有一个定义明确的名字标识–如：运动会管理系统中，报名单(数据流)由队名、姓名、性别、参赛项目等数据组成数据流的流向–从一个加工流向另一个加工–从加工流向文件(

写文件)–从文件流向加工(读文件)–从源流向加工–从加工流向宿注意：数据流和程序流程图中用箭头表示的控制流有本质不同，在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。数据流图的扩充符号•描述一个加工的多个数据流之间的关系数据流图的

层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据

。描述了软件系统与外界(源或宿)之间的数据流。中间层流图则表示对其上层父图的细化。中间层图中至少有一个加工(也可以有多个)可能继续细化，在下层图中分解成一张子图。底层流图是指其所有加工不需再做分解的数据流图，它处在最底层

。分层的数据流图----系统逻辑模型数据的加工或变换输入输出软件系统外部实体外部实体……外部实体外部实体……数据流程图应用实例某汽车配件公司设有销售、采购、仓库、会计等业务部门。公司每天都要处理大量的销售订单业务。当配件缺货或库存量低于保险贮备量时

，就要进货。如果暂不考虑配件公司内部的仓库和会计业务细节，那么，配件公司的TOP图，如下图所示。发货清单系统2数据流程图应用实例第0层第1层缺货数据到货通知发货清单发货清单系统销售配件采购配件数据流程图应用实例缺货记录客户档案第2层补发清单审核客户档案客户信息开发货单更新库存配

件库存补发清单销售报表数据流程图应用实例第3层.便于实现.便于使用---采用逐步细化的扩展方法，可避免一次引入过多的细节，有利于控制问题的复杂度；---用一组图代替一张总图，方便用户及软件开发人员阅读。分层DFD图的优点1）为数据流(或数据存储)命名(1)名字应代表整个

数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。(2)不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。(3)如果在为某个数据流(或数据存储)起名字时遇到了困难则很可能是因为对数据流图分解不恰当造成的，应该试试重新分

解，看是否能克服这个困难。1.注意数据流图中成分的命名画分层DFD的指导原则2）为加工命名(1)通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。(2)名字应该反映整个加工的功能，而不是它的一部分功能。(3)名字最

好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。(4)通常名字中仅包括一个动词，如果必须用两个动词才能描述整个加工的功能，则把这个处理再分解成两个处理可能更

恰当些。(5)如果在为某个加工命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。1.注意数据流图中成分的命名画分层DFD的指导原则画分层DFD的指导原则3.掌握分解的速度一般来说，每一个加工每次可分为2

-4个子加工，最多不得超过7个。4.遵守加工编号规则顶层加工不编号。第二层的加工编号为1,2,3,„,n号。第三层编号为1.1,1.2,1.3„n.1,n.2„等号，依此类推。父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(相对应），分层数据流图的这种特点称为子图与父图“平衡”。

2.注意父图和子图的平衡5.数据流”一定是和“加工”有关联的。一个数据流不是流入“加工”的就必然是从“加工”流出的。数据流与加工的关系6.一个加工的输出数据流不能与该加工的输入数据流同名7.合理使用文件。顶层图通常没有文件,在其他层中当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件

作为数据流图中的一个独立成份画出来了，那么他同其他成份之间的联系也应同时表达出来。画分层DFD的指导原则案例某医院欲开发病人监控系统，该系统通过各种设备监控病人的生命体征，并在生命体征异常时向医生和护理人员报警。该系统的主要功能如下：1）本地监控：定期获取病人的生命体征，如体温

、血压、心率等数据；2）格式化生命体征：对病人的各项重要生命体征数据进行格式化，然后存入日志文件并检查生命体征；3）检查生命体征：将格式化后的生命体征与生命体征范围文件中预设的正常范围进行比较，如果超出了预设范围，系统就发送一条警告信息给医生和护理人员

；4）维护生命体征范围：医生在必要时（如新的研究成果出现时）添加或更新生命体征值的正常范围；5）提取报告：在医生或护理人员请求病人生命体征报告时，从日志文件中获取病人生命体征生成体征报告，并返回给请求者；6）生成病历：根据日志文件中的生命体征，医生

对病人的病情进行描述，形成病历存入病历文件；7）查询病历：根据医生的病历查询请求，查询病历文件，给医生返回病历报告；8）生成治疗意见：根据日志文件中的生命体征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件；9）查询治疗意见：医生和护理人员查询治疗意见，据此对病人进行治

疗。现采用结构化方法对病人监控系统进行分析和设计，获得如图1-1所示的顶层数据流图和图1-2所示的0层数据流图。案例案例在数据流图中对一个数据流、数据存贮或加工只能标明一个名字，没有对这些元素的构成细节、内容、特性及加工过程详

细说明。分析人员仅靠“图”来完整地理解一个系统的逻辑功能是不可能的。为了完整地描述这个系统，还需借助“数据词典”和“小说明”对图中的每个数据和加工给出解释。数据定典就是用来定义数据流图中的各个成分的具体含义的工具，

它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型，是“需求规格说明书”的主要组成部分。数据词典(DD)A、数据流条目给出某个数据

流的定义，通常是列出该数据流的各组成数据项。例如：报名单＝姓名＋单位名＋年龄＋性别＋课程名常用符号：＝、＋、［｜］、｛｝、（）、C、数据项条目（数据流分量）数据项条目给出某个数据单项的定义，通常是数据项的值类型，允许的取值范围。B、文

件条目给出某个文件的定义，文件的定义通常是列出文件记录的组成数据流。例如：订单文件＝订单编号＋顾客名称＋产品名称＋订货数量＋交货日期D、加工条目加工类条目就是“加工小说明”。一般应该单独列出。nm{...}数据词典(DD

)常用的描述数据结构的关系算符1.数据流条目数据流条目通常列出组成该数据流的数据项数。名称：订单别名：无简述：顾客订货时填写的项目来源：顾客去向：加工1.1.1“编辑检查订单”数据流量：1000份/每周组成：编号+订货日期+顾客编号+地址

+电话+银行帐号+配件名称+数量其中：数据流量指单位时间内（每小时或每天）传输的次数数据流条目由数据元素组成数据的方式只有如下三种基本类型：①顺序以一定的顺序连接两个或多的元素；②选择从两个或多个可能

的元素中选取一个；③重复把指定的元素重复零次或多次。④可选理论上，可以使用上述三种关系定义数据字典中的任何条目。因为，当重复次数为0次或一次时，就构成了一种可有可无的可选关系。但由于“可选”是由数据元素组成数据的一种常见方式，把它单独列

为一种关系会使数据字典的描述更清晰。2.数据项条目名称：配件编号别名：配件号简述：本公司的所有配件编号类型：字符型长度：10位取值范围及含义：第1位：进口/国产第2-4位：类别第5-7位：规格第8-10位：编号3.数据

存储条目名称：配件库存别名：无简述：存放配件库存信息组成：配件编号+配件名称+供应商编号+单价+库存量组织方式：索引文件，以配件编号为关键字查询要求：要求能立即查询4.加工条目由于下层的加工是由上层的基本加工分解而来的，只要有了基本加工的说明，就可理解上层的加工。因此，只有把加工分

解到足够具体以后，才对基本加工进行描述。具体格式举例如下名称：确定能否供货編号：1.2激发条件：收到合格订单优先级：普通输入：合格订单输出：可供货订单、缺货订单加工逻辑：根据库存记录IF订单项目的数量<该配件库存量的临界值THEN可供货处理ELSE此订单缺货，登

记缺货情况，待进货后再办理补充订货EDNIF对数据流图的每一个基本加工，必须有一个基本加工逻辑小说明，给出该加工的精确描述。。基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。加工逻辑说

明中包含的信息应是充足的，完备的，有用的，无冗余的。对基本加工说明有三种描述方式：加工逻辑说明结构化语言判定表判定树结构化语言是介于自然语言和形式语言之间的一种半形式语言,是自然语言的一个受限制的子集。

一般分为两层结构：外层语法较具体，为控制结构（顺序、选择、循环）,内层较灵活，表达“做什么”。（一）结构化语言例如：外层可为以下结构：1、顺序结构2、选择结构IF–THEN-ELSE;CASE-OF-ENDCASE；3、循环结构WHILE-DO;REPEAT-U

NTIL加工说明自然语言+结构化形式商店业务处理系统中“检查发货单”if发货单金额超过$500thenif欠款超过了60天then在偿还欠款前不予批准else（欠款未超期）发批准书，发货单else（发货单金额

未超过$500）if欠款超过60天then发批准书，发货单及赊欠报告else（欠款未超期）发批准书，发货单例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于1000元，同时必须信誉

好，或者虽然信誉不好，但是20年以上的老主顾。判定表是一种二维的表格，常用于较复杂的组合条件（与结构化语言比较）。如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适条件框条件条目操作框操作条目（二）判定表特点：可处理较复杂的组合条件，但不易理解，

不易输入计算机通常由四部分组成。条件框—条件定义。操作框—操作的定义。条件条目—各条件的取值及组合。操作条目—在各条件取值组合下所执行的操作。加工说明例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于1000元，同时

必须信誉好，或者虽然信誉不好，但是20年以上的老主顾。1234>1000元YYYN信誉好YNN->20年-YN-优惠XX正常XX化简后12345678>1000元YYYYNNNN信誉好YYNNYYNN>20年YN

YNYNYN优惠XXX正常XXXXXY-满足条件N-不满足条件X-选中判定的结论加工说明特点:描述一般组合条件较清晰，易理解。不易输入计算机。营业额>1000元≤1000元正常处理好的支付信誉优惠处理坏的支付信誉>20年优惠处理<20年

正常处理（三）判定树加工说明状态转化图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作（例如，处理数据）。因此，状态图提供了行为建模机制。可以理解为在任一个时刻

，系统处于有限可能的状态中的一个状态，当某一个激励（条件）到达时，它激发系统从一个状态转换到另一个新状态。1.状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一个行为模式。状态规定了系统对事件的响应方式。系统对事件响应，既可以是做一个（或一系列）动作，

也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。状态转换图（行为模型）2.事件事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。简而言之，事件就是引起系统做

动作或转换状态的控制信息。3.符号在状态图中，初态用实心圆表示，终态用一对同心圆（内圆为实心圆）表示。中间状态用圆角矩形表示，可以用平衡线把它分割成上、中、下3个部分。上部分为状态的名称，该部分是必须的；中间部分为状态变量的名字和值，该部分为可选；下面部分是

活动表，该部分为可选。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。如转换过程中有事件触发，可以用事件表达式标明。案例分析一个具有n部电梯的电梯系统要安装在一座m层的大楼上。电梯和控制机构已造好。每个电梯的内部机构也已给定。问题涉及电梯在楼层间移动的逻辑：（1）每座电

梯有一套按钮，每层一个。按钮按下时使钮灯变亮，并使电梯达到相应的楼层。当电梯到达相应的楼层时按钮灯熄灭。（2）除了底层和顶层外，每层都有两个按钮，一个按钮请求电梯上升，另一个按钮请求电梯下降。这些按钮在按下

时按钮灯亮。电梯到达指定楼层后按钮灯熄灭，然后要么朝期望的方向移动，要么请求等待。在后一种情况下，如果一个楼层上的两个请求按钮都按下，则只取消其中一个按钮。决定先服务哪一层的算法应当使两个请求的等待时间最小。案例分析（3）当

一个电梯没有服务请求时，应当停留在最终的目的地，关上电梯门，并等待后面的请求。（4）楼层上所有电梯请求必须最终得到服务，并且所有楼层具有相同的优先权。（5）电梯内所有楼层的请求必须最终得到服务，各层按电梯移动方向先后得到服务。（6）每

个电梯有一个紧急按钮。按下该按钮时，将使一个报警信号发送到现场管理人员，然后强制电梯“停止服务”。每一个电梯有一个取消其“停止服务”状态的机制。电梯状态转换图举例在一楼上升停滞下降回到一楼回一楼想要到达楼层想要到达楼层电梯行程开始向上向上向下闲置拨号音do:响拨号音超时do:响蜂鸣音存储的信

息do:播放信息接通中do:试接通振铃do:振铃拨号通话断线忙音do:响忙音挂断电话挂断电话拿起话筒超时无效号码有效号码超时数字数字占线已接通受话人回话受话人挂断电话信息播完电话系统的状态图其他图形工具在描绘复杂的关系时，图形比文字叙述优越的多、形象直观。下面介绍三种图

形工具。层次方框图层次方框图采用树形结构的一系列多层次的矩形框来描绘数据的层次结构。随着结构的细化，层次方框图对数据结构也描绘的越来越详细。该模式非常适合于需求分析阶段的需要。请参见教材P58页，图3.5Warnier图Warnier是法国计算机科学家，是他提出的一种信息层次

结构的图形工具。用Wariner图可表明信息的逻辑组织。他可以指出一类信息量是重复出现的，也可以表示特定信息在某类信息中是有条件的出现，因为重复和条件约束是说明软件处理过程的基础，极容易将Warnier图转变成软件设计的工具。请参见教材P58页，图3.

6IPO输入/处理/输出图简称。是IBM公司发展完善的一种图形工具。他能够方便的描绘输入数据、对数据的处理和数据输出之间的关系。它的基本形式是左边框中列出有关输入数据，中间框内列出主要的处理，右边框内列出产生的输出数据，处理框内列出处理的次

序暗示了执行的顺序，但这些基本符号还不足以精确描述执行处理的详细情况。粗大箭头清楚的指出数据通信的情况。改进的IPO图（也称IPO表）包含某些附加信息，在软件设计过程中更有用。IPO图建议使用一种改进的IPO图（也称为IPO表），这种图

中包含某些附加信息，在软件设计过程中将比原始的IPO图更有用。如下图所示，改进的IPO图中包含的附加信息，主要有系统名称，图的作者，完成本图的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清单，本模块调用的模块的清单，注释，以及本

模块使用的局部数据元素等。在需求分析阶段可以使用IPO图简略地描述数据流图中各个处理的基本算法（着重说明处理功能而不是具体实现功能的算法）。当然，在需求分析阶段，IPO表中的许多附加信息暂时还不具备。但是，在软件设计阶段可以进一步补充、修正这些表，继续作为

设计阶段的文档。这正是在需求分析阶段用IPO表作为描述基本算法的工具的重要优点。改进的IPO图的形式改进的IPO图的例子财务管理系统2.1客房帐目管理2.1.1客人入住登记查询处理2.1.1.1.1退房登记查询处理2.1.1.1.2客房结算处理2.1.1.2客

房帐目查询2.1.1.1客人客房结算2.1.1.2.1客房日结算2.1.1.2.2改进的IPO图的例子系统：财务管理系统作者：XXX模块：客房帐目管理日期：2019/03/15编号：2.1.1注释：被调用：财务管理系统调用：客房结算管理有效性检验、客人入住信息查询处理、客人退房信息查询处理输入

：系统当前时间、客人入住信息、客人退房信息、客人入住登记查询请求、。退房登记查询请求。输出：非法信息、客人入住登记查询结果、退房登记查询结果、客人住宿结算表、客房日结算表局部数据元素：