软件工程 第3章需求分析全解课件.ppt

《软件工程 第3章需求分析全解课件.ppt》由会员分享，可在线阅读，更多相关《软件工程 第3章需求分析全解课件.ppt（102页珍藏版）》请在三一办公上搜索。

1、软件工程与软件开发工具,第3章 需求分析,3.1需求分析概述3.2数据流图 3.3数据字典 3.4加工逻辑描述工具 3.5结构化分析方法3.6复审 3.7需求分析人员,3.1软件需求分析概述,3.1.1软件需求分析的任务通过对要解决的问题、用户的要求及其目标环境的研究、分析和综合，建立抽象级的分析模型准确地、完整地体现用户的功能和性能及其它要求，规范地通过“软件需求规格说明书” 表达出来。,3.1.2 需求类型,1. 按内容分类软件需求代表系统的综合要求，包括以下几种类型：(1) 系统功能需求系统功能需求指根据系统所能实现的功能要求，对于每一类功能或者有时对于每一个功能，需要弄清输入、加工和输

2、出等需求。(2) 系统性能需求按照系统的性能要求分类。例如联机系统的响应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。,3.1.2 需求类型(2),(3) 系统运行需求这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么，采取哪种数据库管理系统，需要什么样的外存储器和数据通信接口。 (4) 未来可能出现的问题就是把不属于当前系统开发范围的问题都明确地列出来，因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备，当以后需要时就可以很容易地进行扩展和修改了。,3.1.2 需求类型(3),

3、2. 按用户的期望分类(1) 正常需求用户陈述的针对系统的目标。(2) 期望需求隐式的需求，可能由于是非常基础的而用户没有显示的陈述，如人机交互的容易性、整体的操作正确性和可靠性，以及软件安装的容易性。(3) 兴奋需求在用户的期望范围之外，如果实现将令人愉快和出乎意料。,3.1.2 需求类型(4),3. 按必要性分类(1) 强制的需求是指除非软件与这些需求一致，则该软件是不可接受的 (2) 希望的需求是指这些需求将增进软件产品功能，但是如果缺乏的话也不是不可接受 (3) 任选的需求是指这个功能可有可无,3.1.3 需求特性,(1) 正确性需求规格说明书中的功能、行为、性能描述必须与用户对目标软

4、件产品的期望相吻合。(2) 无歧义性对于用户、分析人员、设计人员和测试人员而言，需求规格说明书中的任何语法单位只能有唯一的语义解释。确保无歧义性的一种有效措施是在需求规格说明书中使用标准化术语，并对术语的语义进行显式的、统一的解释。(3) 完整性需求规格说明书不能遗漏任何用户需求，具体地说，目标软件产品的所有功能、行为、行为约束以及它在所有可能情况下的预期行为，均应完整地包含在需求规格说明书中。(4) 可验证性对于规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。,3.1.3 需求特性(2),(5) 一致性需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用

5、方面的冲突，功能和行为方面的冲突，以及时序方面的前后不一致。(6) 可理解性追求上述目标不应妨碍需求规格说明书对于用户、设计人员和测试人员的易理解性。特别是对于非计算机专业的用户而言，不宜在说明书中使用太多的专业化词汇。(7) 可修改性需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改，并使修改后的说明书能够较好地保持其他各项属性。(8) 可追踪性需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引用这些需求项提供便利。,关于需求分析,如何看待需求,理解需求和功能的区别 需求是需要分析的 需求一般不专一，是会变的 （要注意应变）

6、 （1）积极的沟通。及时了解变化，并进行变更控制管理。 （2）在系统的架构设计上，为变化做准备。面向对象也好、面向服务也好、三层也好、四层也好，我们为什么把代码分开层次，为什么提供那么多抽象的接口？都是为了应对变化，为了我们在这个需求像云彩一样变化的环境中能够适应。保持沟通渠道的畅通,需求分析的一般性技术,为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本的需求分析技术，主要包括： 初步需求获取技术； 需求建模技术； 快速原型技术； 问题的分解与抽象； 多视点分析技术等。,初步需求获取技术,原因：在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员对问

7、题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊的，从而会造成相互交流和相互理解上的困难。为了克服困难，获取初步需求，可以采用如下的技术手段： 访谈与会议； 观察用户工作流程； 分析人员和用户组成联合小组。,1访谈与会议,分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，分析人员根据对问题的初步描述精心准备一系列问题，通过用户对问题的回答或互相商讨来逐步理解用户的需求。准备问题的原则有：首先应搞清一般性、整体性问题，然后再涉及细节问题。在组织问题时要尽量做到客观、公证，不应限制用户的自由发挥。所提问题汇总后应能反映应用问题及其子问题的全貌、并且不要过

8、分详细。,2观察用户工作流程,通过实际观察用户的手工操作过程来提取新系统的初步用户需求。,第一手资料软件开发和应用的经验,发现不合理的用户需求、提出用户还没有意识到的潜在的但却很有价值的用户需求,获得用户满意的分析结果,观察手工操作过程,3用户和开发人员共同组成联合小组,目的：为加强信息沟通、减少误解和避免产生遗漏、充分调动用户的积极性。方法：建立由开发方和用户方共同组成的联合小组。联合小组成员：双方的分析人员 专门的记录员 负责会议议程的人员 资料员 另外：制定小组的规章制度和计划，选定一种易于理解、简洁、精确的表示机制作为双方的共同语言，比如采用带文字说明的流程图等。,【例】这里以“家庭保

9、安系统”为例，简要说明初步需求的获取过程。假设用户的原始需求描述如下：,根据家庭保安市场的增长趋势，我们希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的报警措施。这些异常事件有：非法进入、火灾、水淹，等等。当传感器一旦探测出相应的异常事件时，系统应自动用电话向监控中心报警。此外，系统应允许户主对其行为实施程序式控制。,【例】,为进行初步的需求分析，这里采用开发方和用户方组成联合小组的方法。为此，联合小组应制定工作制度：每次会议开始前必须有确定的议程，小组成员必须针对议程进行充分准备并应形成文字。联合小组会议首先应明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达

10、成共识。小组负责人要求每位参加者根据负责的范围列出应用问题及环境中有关的对象、对象的操作及对象间的关系。 如：市场营销人员列出控制面板、电话机、监控中心等对象和用户编程控制、电话拨号、报警等操作； 负责传感器的用户可能列举烟雾传感器、门窗监视器、警报器等对象。,【例】,将对这些列举的对象和操作进行更详细的讨论和描述，比如，详细地描述接收传感器事件、用户编程控制、电话报警等操作等。用户可能提出一些约束条件。比如，造价不应超过3000元，对传感器事件的响应时间不得超过1秒，事件必须按优先级顺序进行处理等等。小组负责人应对这些信息加以整理并形成文档，该文档应能反映“家庭保安系统”的全貌。,【例】,根

11、据“家庭保安系统”的特点，将联合小组分成两个小组，并行处理用户编程控制和传感器检测两个子系统，以便使子问题的软件需求进一步细化，这时可能又会增加新对象、新操作、新约束条件。在子系统的需求基本明确并形成文档后，还应就子系统的整合及需求验证标准等进行初步的讨论。初步需求分析应形成结论性文档。比如，经过初步的需求分析，“家庭保安系统”的部分初步需求文档如下：,【例】,“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与户主进行信息交互。 系统开机后，软件系统负责显示系统当前的工作状态，接收并处理户主的命令。 当系统处于配置状态，软件系统允许户主进行配置操作。配置操作

12、包括：指定每一传感器的种类和编号； 设置开、关机密码； 指定报警电话号码； 指定报警延迟和电话重拨延迟时间（以秒为单位）。 当系统处于监视状态时，软件系统即开始对所有传感器实施监控。当软件系统接收到传感器发出的数据后，判别是否出现异常事件，如果是，则经过指定的延迟时间即开始拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。此时软件系统负责向监控中心报告异常事件发生的地点、时间和性质。,【例】,以上文档没有包括约束条件、测试标准等方面的内容。初步需求文档将是后续详细需求分析的基础。在此基础上，就可以采用某种需求分析方法进行详细的需求分析。分别介绍几种详细的需求分析方法和其中最重要的需

13、求建模技术，它们是： “面向数据流的需求分析方法”； “面向数据的需求分析方法”； “面向对象的需求分析方法”。,需求建模技术,为了使用户需求逐步精细化、完全化、一致化，通常采用需求建模技术，即用建立目标软件系统模型的方法来刻画软件系统中的信息、处理功能和外部行为。通常，分析人员选定一种分析方法，并用该方法中的一些图形记号分别表示信息流、处理功能和系统行为，并利用受限制的自然语言给出用户需求的描述。这种模型的表示机制还应具有良好的结构化能力，以便处理大型问题的按层次分解的问题。软件需求分析的过程，实际上是软件模型的建造和不断完善的过程。,需求建模的步骤,在分析的初期，分析人员通过访谈、会议、实

14、际观 察、分析现有系统等方法获取初步的用户需求。分析人员根据选定的一种分析方法，在初步用户需 求的基础上构筑初步的模型作为开发方和用户相互 沟通的表示机制。分析人员在用户的密切配合下，利用选定的分析方 法不断地对模型进行精细化、一致化、完全化，直 至获得满意的用户需求为止。在分析阶段构筑的模型不应涉及软件实现的细节，以免分散分析人员的注意力、限制软件设计人员为提高软件质量和效率而选择实现方法的自由度。需求分析结束时确立的软件模型是生成需求规格说明的依据，也是软件设计和实现的基础。,快速原型技术,如果按照传统的软件开发方法，需要经过漫长的开发时间之后用户才能看到目标软件的最初版本。此时用户常常会

15、提出许多修改意见，有时甚至全盘否定，导致开发失败。为了降低开发风险，在需求分析阶段常常采用快速原型技术。 1快速原型技术的基本思想 在软件开发的早期，快速开发一个目标软件系统的原型，让用户对其进行评价并提出修改意见，然后开发人员根据用户的意见对原型进行改进。当原型几经改进最终确认后，它将直接进化成软件产品，或者由软件设计、编码人员按照模型所确立的外部特征去实现软件产品。,2采用快速原型技术的具体步骤,采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明。对该规格说明进行评审通过后，立即生成设计规格说明。为了快速生成原型，这种设计仅注重所关心的问题，如软件的总体结构、用户界面和数据

16、设计、或者某个复杂的算法等等，不注重过程内部的控制流设计。使用可重用软部件、用户界面自动生成器等工具快速生成可运行的软件原型并通过测试。将原型提交给用户进行评价，以便征求改进意见。上述过程反复迭代，直至用户完全满意。此时的原型已完全、准确地反映了目标软件在所关心方面的需求，可作为需求规格说明的一部分而成为软件设计的基础。,3快速原型技术的适用场合,该技术特别适合于软件产品要求大量的用户交互、或产生大量的可视输出、或设计一些复杂的算法等场合，目前的绝大多数软件都适合于快速原型技术。除非由于问题相当复杂，致使开发快速原型可以获得的支持太少、所冒的风险太大时，就不易采用。但对于其中的某些子问题，尤其

17、是用户界面，还可采用快速原型技术进行部分分析。,问题分解与抽象、多视点分析技术,问题分解技术 分析人员常常采用一种问题分解的技术。即将一个大型复杂的问题分解为若干个子问题，然后对每一个子问题逐个进行分析，再自底向上综合成整个问题的分析结果。这种分解可以逐级进行，直至子问题的规模降到合适的程度。问题抽象技术 分析人员在分析过程中要善于从诸多的特殊问题中抽象出一般的问题，首先关注一般问题的解决途径，再用其指导特殊问题的求解。在抽象的过程中，还要注意用户的描述所处的抽象级别的不同，以便建立清晰的思路。,问题分解与抽象、多视点分析技术,比如，在“家庭保安系统”中，用户可能提出“系统状态显示”、“用户编

18、制程序时的系统外部行为”等的需求。分析人员则应在“用户界面”这一抽象级别上统一地规划软件系统与用户的交互行为。可见，在不同的抽象级别上去分析不同层次的问题，也是解决复杂问题的一个重要方法，它可以避免不一致性，减少分析的工作量。多视点分析技术： 为了获得全面的需求分析结果，防止遗漏，有必要从各个视点分别对问题进行理解与分析，然后综合成全面的理解。分析人员可以就系统视点与用户视点、信息视点、功能视点与行为视点等多个视点分别进行分析，以确保需求分析的完全性。,需求规格说明与评审,需求分析的主要阶段性产品是需求规格说明书。它必须通过需求评审后才能生效，这是一个重要的里程碑。4.3.1 需求规格说明书的

19、作用与内容1. 需求规格说明书的作用主要有：1）它是软件设计人员进行设计和编码的出发点和基础；2）它是对目标软件产品进行验收测试的依据。这就要求需求规格说明书中的各项需求都应该是可测试的；3）它起到软件开发方和客户（或用户）方之间的一份合同的作用。,需求规格说明书的作用与内容,2. 需求规格说明书中的内容应主要包括功能与行为的需求描述和非行为需求描述。功能与行为需求的分析与描述方法将在以后几章中根据不同的需求建模方法分别介绍。非行为需求是指目标软件系统在工作时应具备的属性，主要有运行效率、可靠性、安全性、可维护性、可移植性等等。在需求规格说明书中不应包括如人员需求、成本预算、进度计划、质量保证

20、计划等内容，以便使其简洁、目标明确。,需求规格说明书的基本格式框架,目录1 引言 1.1 本说明的编写目的 1.2 软件产品的作用范围 1.3 定义、同义词与缩写 1.4 参考文献2 概述 2.1 产品与其环境间的关系 2.2 功能概述 2.3 用户特征 2.4 约束条件 2.5 假设与前提条件,需求规格说明书的基本格式框架,3功能或行为需求 3.1 功能或行为需求1：1）引言 2）输入 3）处理过程描述 4）输出 3.2 功能或行为需求2：1）引言 2）输入 3）处理过程描述 4）输出 3.n 功能或行为需求n: 4）输出,需求规格说明书的基本格式框架,4外部界面需求 4.1 用户界面 4.

21、2 硬件界面 4.3 软件界面5性能需求 5.1 精度 5.2 时间特征 5.3 灵活性6设计约束 6.1 标准化约束 6.2 硬件约束 ,需求规格说明书的基本格式框架,7其他需求 7.1 数据库需求 7.2 用户操作需求 7.3 工作场地需求8软件产品属性 8.1 可用性 8.2 安全性 8.3 可维护性 8.4 可移植性附录索引,需求评审,软件系统中的错误约有15%来源于需求分析中的错误。而在维护阶段去改正这部分错误是相当困难的。为了及时发现并纠正这类错误，必须对需求规格说明书进行评审，即需求评审。1. 评审标准（按照重要性的次序）1）正确性。指需求规格说明书中的每一项功能、行为、性能的描

22、述都是正确的、合理的，并能满足用户的期望。2）无歧义性。指规格说明书中的每个需求陈述都只有唯一的解释。要避免产生歧义性，就应使用标准化术语，并对术语的语义进行统一的解释。,1. 评审标准（按照重要性的次序）,3）完全性。指不遗漏任何用户需求。即需求规格说明书中包括了所有的功能、行为、性能约束等。4）可验证性。指需求规格说明书中的每一项需求都是可以检验的。5）一致性。指陈述的需求之间不存在矛盾之处。6）可理解性。指规格说明应尽量简洁、明确，便于分析人员、客户（用户）、设计人员、测试人员和维护人员的理解。因此，应尽量减少专业化的词汇。,1. 评审标准（按照重要性的次序）,7）可修改性。指需求规格说

23、明书的框架结构应能比较容易地实现对其可能进行的增补、删除和修改，并能保持总体结构不变。8）可追踪性。指规格说明可向前追踪，即其中的每一项需求与用户的原始需求项清晰地联系起来；也可向后追踪，即为后续开发和其他文档引用这些需求项提供了依据。,2. 需求评审过程,需求评审过程应采用召开正式评审会议的形式。 参加的人员应当有用户、系统分析员、系统设计人员等。在评审会上，分析人员应说明软件产品的总体目标，也就是介绍需求规格说明书中的主要内容。之后，与会人员对说明书的核心部分需求模型进行评估。并按照上述的评审标准逐一进行审查，最后确认其是否具有良好的品质、是否构成以后开发的良好的基础。如果在评审过程中发现

24、说明书中存在错误或遗漏，应责承分析人员返工，并再行评审。需求评审也可采用先进行技术评审，再进行管理复审的方法进行。管理复审应有开发方和客户方（或用户方）管理部门负责人参加，复审通过后，双方应签订正式的合同。,3.1.4需求分析的步骤,1. 分析系统的数据要求2. 建立系统的逻辑模型3. 修正开发计划4. 构造原型系统5. 复审、验证软件需求分析的正确性6. 编写软件需求说明书,3.2数据流图,数据流图（DFD,Data Flow Diagram）是用来描绘软件系统的逻辑模型的工具。通过数据流图描绘信息在系统中流动和加工处理的情况。是各类人员之间极好的交流、沟通的工具设计数据流图只需考虑系统必须

25、完成的基本逻辑功能，一般在图中不使用具体的物理元素，完全不需要考虑如何具体地实现这些功能。,3.2.1符号,数据的源点/终点:是指在系统以外的事物或人加工处理:表示对数据的处理功能数据存储:表示对数据存储的逻辑描述，它可以是数据库文件或任何其他形式的数据组织。数据流:表示数据在系统中流动的方向。,附加的图形符号数据流与数据加工之间的关系,描述银行取款过程的数据流图,教材管理系统的数据流图,3.3数据字典DD,数据流图描述系统的逻辑模型，但它不可能表达一个系统的全部逻辑特性，特别是有关数据的详细内容。数据字典恰恰弥补了数据流图在这个方面的不足，它专门记录有关数据方面的信息，作为对数据流图的补充和

26、解释。数据流图和数据词典共同构成全面描述软件需求说明书的核心。,3.3.1定义方法,数据字典要对数据流图中出现的所有名字进行定义。同日常使用的词典一样，为了便于查阅，词典中的所有条目都要按一定的次序排列起来，也可采用卡片的形式，以供开发与维护人员方便地使用。,3.3.1定义方法(2),数据流定义中常用的符号含义如下：=表示“被定义为”；+ 表示“和”，连接两个或多个分量；.|. 表示“选择”，即可选择方括号中的一项，用“|”作为各项的分割符； ( ) 表示“可选”，即括号内的项可选可不选；mn表示“重复”，n为重复次数的上限，m为重复次数的下限，如重复次数没有限定可不标出上下限。也可以利用上下

27、标表示。,3.3.2 实现,数据字典可以用人工方式建立，记录在卡片上。也可以用自动化的方式记录在计算机的存储器上。数据字典的内容主要包括：数据元素、数据流、数据存储、外部项、加工处理等。按词条形式描述数据的属性、结构、逻辑关系、特征信息等。,3.3.2 实现(2),1.数据元素词条描述数据元素名：类型：数字（离散值，连续值），文字（编码类型）长度：取值范围：相关的数据元素及数据结构：,3.3.2 实现(3),2.数据流数据流名：说明：简要介绍作用即它产生的原因和结果数据流来源：来自何方数据流去向：去向何处数据流组成：数据结构数据量流通量：数据量，流通量,3.数据存储,数据存储名：简述：存放的是

28、什么数据输入数据：输出数据：数据文件组成：数据结构存储方式：顺序，直接，关键码存取频率：,4.加工逻辑,加工名：加工编号：反映该加工的层次简要描述：加工逻辑及功能简述输入数据流：输出数据流：加工逻辑：简述加工程序，加工顺序,4.加工逻辑(2),对数据流图的每一个基本加工，必须有一个基本加工逻辑说明基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则加工逻辑说明必须描述实现加工的策略而不是实现加工的细节加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息,5.源点及终点词条描述,名称：外部实体名简要描述：什么外部实体有关数据流：数目：,6.数据结构的描述,

29、符 号 含 义 举 例 被定义为 与 x = ab.,. 或 .|. 或 x = a,b，x = a|b . 或 m.n 重复 x = a， x = 3a8(.) 可选 x = (a)“.” 基本数据元素 x = “a” . 连结符 x = 1.9,练习:,画出和存折操作有关的基本的数据流图定义各种类型的数据字典词条,存折户名所号帐号开户日性质（印密）1存取行50户名2字母24所号“001”.“999” 帐号“00000001”.“99999999”开户日年月日性质“1”.“6” 注：“1”表示普通户，“5”表示工资户等印密“0” 注：印密在存折上不显示存取行日期（摘要）支出存入余额操作复核,

30、3.4 加工逻辑描述工具,对于某些复杂的加工，只用文字说明则存在许多含糊不清之处。此时，可借助一些加工逻辑描述工具来清楚地表达。常用的加工逻辑描述工具有结构化语言、判断表、判断树和IPO图等。,3.4.1结构化语言,是一种介于自然语言和形式化语言之间的语言语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示其基本控制结构有三种：简单陈述句结构：避免复合语句；重复结构：WHILE_DO 或 REPEAT_UNTIL结构。判定结构：IF_THEN_ELSE 或 CASE_OF结构；,结构化英语的词汇表,英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_E

31、LSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。,商店业务处理系统中“检查发货单”,IF 发货单金额超过$500 THEN IF 欠款超过了60天 THEN 在偿还欠款前不予批准 ELSE （欠款未超期） 发批准书，发货单 ENDIFELSE （发货单金额未超过$500） IF 欠款超过60天 THEN 发批准书，发货单及赊欠报告ELSE （欠款未超期） 发批准书，发货单 ENDIFENDIF,BEGIN输入用户账号和口令IF 输入空的帐号或口令 THEN BEGIN提示错误中断登录END验证帐号、口令IF 非合法用户 OR 权限=“禁止” THENBEGIN

32、 提示错误 中断登录END初试化运行环境,数据库事务操作逻辑,3.4.2. 判定表,判定表也是一种表达加工逻辑的工具。在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。,3.4.2. 判定表的组成,条件：列出一组条件的对象；条件取值：列出各种可能的条件取值组合；操作：列出所有的操作；操作条目：列出对应的条件组合下所选的操作。,判定表的一般结构,建立判定表的步骤,列出与一个具体加工 (或过程)有关的所有处理列出过程执行期间的所有条件(或所有判断)将特定条件取值组合与特定的处理相匹配，消去不可能

33、发生的条件取值组合将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作,毕业证、学位证书授予判定表,以“检查发货单”为例,3.4.3 判定树,判定树是判定表的变种，它能清晰地表达复杂的条件组合与所对应的操作之间的关系。判定树的优点在于它含义清楚，易于理解和使用，比判定表更加直观。,3.4.4 IPO图,输入/处理/输出图描绘输入数据、对数据的处理和输出数据之间的关系输入数据左边框对数据的处理中间框，隐含执行顺序输出数据右边框,成绩单输出IPO,统计要求各类课程成绩查询条件,统计成绩成绩录入成绩查询,各类统计报表成绩记录查询结果,3.5结构化分析方法,面向数据流进行需求分析的方法

34、具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止结构化分析方法适合于数据处理类型软件的需求分析,3.5.1数据流图的分层,数据流图的层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统步骤（1）画顶层数据流图（2）画第一层数据流图（3）画下层各数据流图,3.5.1数据流图的分层(2),在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所

35、输出数据底层流图是指其加工不需再做分解的数据流图，它处在最底层中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,3.5.2 画数据流图的注意事项,数据流图上所有图形符号只限于前述四种基本图形元素图上每个元素都必须有名字数据流图中不可夹带控制流数据流图的主图必须包括前述四种基本元素，缺一不可每个加工至少有一个输入数据流和一个输出数据流,3.5.2 画数据流图的注意事项(2),在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡初画时可以忽略琐

36、碎的细节，以集中精力于主要数据流,3.5.2 画数据流图的注意事项(3),容易出现的问题0层DFD概念不清，包含多个加工，往往忽略数据存储，过于简单，不能够建立完整抽象模型数据流、加工的命名中“信息”泛滥，例如接收信息、处理信息试图描述分支控制结构，例如信息分为教师、学生下层数据流没有与唯一的父图中加工项对应数据流没有箭头处理对象作为外部实体，外部实体与数据存储、外部实体之间传递数据,3.5.3结构化分析方法步骤示例 例1,学,生,审查并,开发票,开领,书单,购书单,发票,领书单,无效书单,各班学生用书表,教材存量表表,第一层目标系统逻辑模型,学,生,学,生,审查并,开发票,开领,书单,购书单

37、,发票,领书单,无效书单,各班学生用书表,教材存量表表,目标系统数据流向过程,学,生,例2 在售书的基础上增加采购书,教材购销系统,学生,采购员,购书单,领书单,缺书单,进书通知,第0层数据流图,功能： 教材销售 教材销售,第一层DFD图教材购销系统,进书通知,F2 缺书登记表,1,销售,学生,购书单,领书单,采购员,缺书单,进书通知,2,采购,F1 教材存量表,1框功能：,审查有效性,开发票,登记并开领书单,登记缺书,补售教材,补售,书单,暂缺书单,领书单,发票,购书单,无效书单,F4售书登记表,F3各班学生用书表,F2缺书登记表,F1教材存量表,1.5,补售,教材,1.4,登记,缺书,学,

38、生,有效,购书单,进书通知,学,生,1.3,登记并,开领书单,1.2,开发票,1.1,审查,有效性,采,购,1加工框的第2层数据流图,1框的子图,第一层DFD图教材购销系统,进书通知,F2 缺书登记表,1,销售,学生,购书单,领书单,书库,保管员,缺书单,进书通知,2,采购,F1 教材存量表,父框,第一层DFD图教材购销系统,进书通知,F2 缺书登记表,1,销售,学生,购书单,领书单,书库,保管员,缺书单,进书通知,2,采购,F1 教材存量表,2框功能：,按书号汇总缺书,按出版社统计缺书,修改教材库存和待购量,销,售,书库,保管员,2.3,修改教材库,存和待购量,2.2,按出版,社统计,缺书,

39、F6教材一览表,F1 教材存量表,2.1,按书号,汇总缺书,F2 缺书登记表,F5待购教材表,进书通知,进书通知,缺,书,单,2加工框的第二层DFD图采购子系统,存和待购量,2框的子图,进书通知,F2 缺书登记表,1,销售,学生,购书单,领书单,书库,保管员,缺书单,进书通知,2,采购,F1 教材存量表,父框,例3 商店业务处理系统,这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能,例3数据流图绘制步骤,首先确定系统的输入和输出根据商店业务，画出顶层数据流图，以反映最主要业务处理流程经过分析，商店业务处理的主要功能应当有销售、采购、会计三大项。主要数据流输入的源点和输出终点

40、是顾客和供应商。然后从输入端开始，根据商店业务工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第二层数据流图,第二层数据流图,细化每一个加工框 销售细化,采购细化,商品信息单,管理人员,住院处管理,出院管理,急诊处理,护士工作平台,病人,病人情况,费用结算,管理人员,处理事务,打印,病人,病人,入院通知单,预缴金通知单,入院记录,管理人员,病人,费用结算,打印,出院申请单,结算单,结算单,管理人员,病人,预缴金处理,补缴,急诊处理单,补缴通知单,追加费用单,管理人员,病人,处理事务,入区登记单,医嘱信息,病区退药申请,住院部,病区,入区登记单,病人信息登记,退药批准单,3.6 复审,对每一阶段的工作进行复审是瀑布模型的一个基本要求。由于需求分析是决定软件成败的关键，对需求分析阶段的结果进行复审，检查可能存在的问题并进行修正，后续各阶段的工作提供一个更可靠的基础。,3.7 需求分析人员,需求分析人员的工作目标是产生好的、复合规范的需求，完整地获取用户需求，认真地理解、分析和综合要解决的问题。主要包括以下几方面的活动：通过学习、请教领域专家、向用户提问等手段了解所要解决的问题理解用户的需要确认谁是真正的用户，以及系统实现所受到的各种限制。,谢谢!,