软件工程-第03章.doc

第040页第3章 需求分析 需求问题是造成软件工程项目失败的主要原因，能否开发出高质量的软件，很大程度上取决于对要解决的问题的认识以及如何准确地表达出用户的需求。通过需求分析使得分析者深刻地理解和认识系统，并将其完全、准确地表达，其结果不仅起到沟通（用户和开发者）作用，还是后续工作的依据。本章介绍需求分析的一些基本概念，分别对需求获取技术、需求规格说明书、如何进行需求分析以及需求分析方法进行讨论，重点讨论结构化的需求分析方法。 3.1.1 需求的概念和任务 什么是需求？到目前为止还没有公认的定义。对用户来讲需求是对软件产品的解释，是用户对目标软件系统在功能、行为、性能、设计和约束等方面的期望；而开发人员所讲的需求对用户来说又像是详细设计。比较权威的定义是IEEE软件工程标准词汇表中的需求定义： (1)用户解决问题或达到目标所需的条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。 由定义可知，需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。用规范的格式表达出来的文档说明称为需求规格说明书，或者简称为“需求说明”。 3.1.2 需求的层次 需求可分解为4个层次：业务需求、用户需求、功能需求和非功能需求。 (1)业务需求(Business Requirement)：业务需求是反映组织机构或客户对软件高层次的目标要求。这项需求是用户高层领导机构决定的，它确定了系统的目标、规模和范围。业务需求是需求分析阶段制定需求调研计划、确定用户核心需求和软件功能需求的依据，应在进行需求分析之前确定，通常在项目定义与范围文档中予以说明。 (2)用户需求（User Requirement）：用户需求是用户使用该软件要完成的任务。要弄清这部分需求，应该充分调研具体的业务部门，详细了解最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其他系统的接口等。用户需求是最重要的需求，也是最容易出现问题的部分。 (3)功能需求(Functional Requirement)：功能需求定义了软件必须实现的功能。由于用户是从完成任务的角度对软件提出需求的，通常是凌乱的、非系统化的、冗余的，开发人员无法据此编写程序。分析人员必须在充分理解用户需求的基础上，将用户需求整理成满足特定业务需求的软件功能需求。 (4)非功能需求：非功能需求是对功能需求的补充。可以分为两类：一类是用户关心的一些重要属性，如有效性、效率、灵活性、完整性、互操作性、可靠性、健壮性、可用性；另一类是对开发者来说很重要的质量属性，如可维护性、可移植性、可复用性、可测试性。第041页 软件需求各组成部分之间的关系如图3-1所示。图3-1 软件需求各组成部分之间的关系3.1.3 需求分析的任务 软件需求分析是在软件计划的基础上进行的。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，确定目标系统“做什么”的问题。需求分析的结果应该反映的是系统必须做什么，而不是怎么做。具体地讲，该阶段的工作是在对问题进行调查了解的基础上，确定系统的目标和范围，将用户的需求变为软件的功能和性能描述。为了将软件的功能和性能描述清楚，系统分析人员需要用一定的方法和手段对问题进行分析，建立反映问题所涉及的信息、功能及系统行为的模型，用文字、图形符号来详细说明软件必须要做什么以及配合运行的环境应该是什么，形成需求规格说明。 需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目计划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又为用户和开发人员提供一起协商讨论的基础，作为软件设计、实现、测试和维护的依据。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。 随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期，并将需求工作分为需求开发和需求管理两部分，将这两部分统称为“需求工程”（Requirement Engineering，RE）0 20世纪80年代中期，需求工程成为软件工程的子领域，进入90年代以来，需求工程成为研究的热点之一。需求工程结构图如图3-2所示。第042页图3-2 需求工程结构图 由此，需求分析阶段的任务就是实现需求工程，具体内容如下。 3.1.3.1 需求开发 需求开发工作包括软件产品的需求收集、评价、编写文档等所有活动，分为4个阶段：需求获取、分析建模、编写需求规格说明、需求验证。 1需求获取 进行用户需求调查，获取需求，识别问题，确定系统的综合要求是需求分析的第一步，是一个对所求解问题及其环境的理解、分析和综合的过程，也是进行软件设计与实现的基础。 在系统开发阶段的初期，分析人员往往对待解决的问题知之甚少，而用户对问题的描述、对目标软件的要求通常也相当零乱、模糊。尤其是分析人员与用户共同的知识领域不多，造成相互之间理解方面的困难。分析员通过与用户充分交流，准确、完整地获取用户需求，确定软件系统的综合要求。通常软件系统的综合要求包括以下几方面： (1)系统功能要求：分析用户要求实现的全部功能，并分析其中每个要求的必要性和相容性。确定系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出，划分出目标系统必须完成的所有功能。 (2)性能要求：理解用户对系统性能的要求，确定目标系统必须达到的技术性能指标。如响应时间，存储容量及后援存储，计算精度与效率，系统安全指标等。 (3)运行和扩充要求：合理地规定系统运行要求和系统将来可能的扩充要求。 系统运行要求通常包括系统运行的物理环境，如系统运行的设备地点，位置是集中式的还是分布式的，对环境的要求如何（如温度、湿度，电磁场干扰等）；支持软件系统；数据通信方式；系统界面，如要求与其他系统进行数据交换的内容与格式、终端用户的类型与熟练程度、用户对界面的特定要求、用户操作的易接受性等。 系统可能的扩充要求主要有是否要求可移植、未来扩充或者升级的要求、扩充的方式、范围、接口等。 (4)系统维护要求：包括系统出错后可以允许的最大恢复时间、对错误修改的回归测试要求、系统运行日志规格、是否允许对系统修改、系统变化如何反映到设计中等。第043页 (5)系统文档规格要求：系统要求交付什么文档及各类文档的编制规范和预期使用对象等。 取需求的方法见3.2节。 2分析建模 为了更好地识别问题，应综合上述分析的结果，对已获取的需求进行抽象描述，为目标系统建立一个详细的逻辑模型。模型是形成需求说明的重要工具，通过模型可以更清晰地记录用户对需求的表达，更方便地与用户交流，以便帮助分析人员发现用户需求中的不一致性，排除不合理的部分，挖掘潜在的用户需求，确定被开发系统的运行环境、功能和性能要求。 建模方法有多种类型，如面向过程的方法、面向数据结构的方法、面向数据流的方法及面向对象的方法等。本书后面将要介绍的分析方法，实际都是建模方法。通常系统逻辑模型可用数据流图、实体一联系图、状态转换图、数据字典和主要功能的处理算法等进行描述。 通常，软件开发是要实现系统的物理模型，即确定待开发的软件系统的系统元素，然后把功能和数据结构分配到这些系统元素中。但是，目标系统的具体物理模型是由它的逻辑模型经实例化得到的，所谓逻辑模型就是忽略实现机制和具体细节，只描述系统要完成的功能和要处理的数据。因此，软件系统的开发，可看做是建立模型及模型转换的过程。具体分析建模过程如图3-3所示。图3-3 分析建模过程 3编写需求规格说明 该阶段的主要工作是需求描述。在对问题空间准确、全面理解的基础上，对需求模型进行精确地、形式化的描述。需求描述应定义和详细描述全部系统功能，反映影响系统事件前后关系的软件行为，建立系统界面的特征，并揭示设计限制。结果以文档形式表述，成为可见的，能够与用户交流的，可以进行复审的系统逻辑模型。该阶段的文档包括：需求规格说明书、用户手册初稿、确认测试计划、修改的开发计划等。其中： (1)需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准以及用户在性能、质量、可维护性等方面的要求。 (2)用户手册包括用户界面描述以及有关目标系统使用方法的初步构想。在需求分析阶段就开始编写用户手册，而不是在编码测试完成后组织人员另行编写，其优点在于，首先，使系统分析和设计人员在系统开发的早期就从用户的角度观察和分析系统，有利于提高系统对用户的友好程度，并有利于提高系统运行的方便性和实用性；其次，可以使用户手册随着系统各阶段的开发不断完善，有利于保证其正确性、完备性和同真实系统的一致性，并可保证其按时完成。 (3)在需求分析中确立测试标准，作为系统开发目标是否完成的验收依据。而该测试计划的依据是系统目标，包括系统功能和性能等详细内容的用户需求。由于系统目标是在需求分析阶段制定的，所以，以此为依据的确认测试计划应在同一阶段，由相同的人员制定。这样能最有效地保证两者的一致性。 (4)修改的项目开发计划是根据新的分析结果，对可行性分析和软件计划阶段中制定的初步的项目开发计划作必要的修改、补充和完善。 4需求验证 在以上各阶段的实施过程之中，形成了有关的文档。在此基础上，由专家、分析人员、开发人员、用户组成评审组，对需求分析所得结果的正确性、合理性和有效性进行检查，第044页以确保需求分析的全面性、准确性和一致性。并使用户和开发人员对需求规格说明及用户手册达成一致的理解。通常应从以下几点进行评审： (1)完整性：完整性体现在两个方面。首先是不能遗漏任何必要的需求。避免遗漏需求的关键是需求获取的方法，后面将详细讨论这个问题。需求完整性的第二层含义是清楚、完整地描述每一项需求所要完成的任务，使开发人员理解实现这项需求的所有必要信息，用户能够审查这项需求描述的正确性。 (2)正确性：所谓正确性是指每项需求都必须准确地反映用户要完成的任务。不仅要从不同角度检查需求的正确性，还应该检查每项需求是否与软件的总体目标一致，是否超出了业务需求所定义的软件范围。 (3)一致性：用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格地遵守不同层次间的一致性关系，就可保证最后开发出来的软件系统不会偏离最初的实现目标。 (4)必要性：必要性即每项需求都应该是客户所需要的，开发人员不得自作主张添加需求。检查需求必要性的方法是将每项需求回溯至用户的某项输入。 (5)无歧义性：无歧义性即需求分析结果的描述，应使不同的人员对需求的理解是一致的。如采用自然语言描述需求，其优点是任何人不经训练，都可理解，但自然语言对需求分析最大的弊病就是它的二义性。所以各种需求分析方法中都对描述语言作了一些限制，对描述语言的规定是需求分析方法的重要组成部分。发现需求二义性可通过对需求文档的正规检查，包括编写测试用例和开发原型，还可使用按多种不同的方式、从多个角度描述同一需求的方法发现需求二义性。 (6)可验证性：每项需求都应该是可验证的。系统分析员在需求分析时就要考虑每项需求的可验证性问题，为需求设计测试用例或其他的验证方法。 (7)优先级的划分：为每一项需求按照重要程度分配一个优先级，在开发产品时，可以先实现优先级最高的核心需求，将优先级低的需求放在后续版本中。优先级的划分可以帮助项目管理者解决冲突、安排阶段性交付，在必要时做出功能取舍，以最少的费用获得软件产品的最大功能。 在评审中，一旦发现问题，应尽快予以更正。若需求分析工作通过评审，则可以开始下一阶段工作。同时，需求规格说明成为用户方与系统开发方之间的合同，任何增删或改动所引起的开发规划及成本变化，应由提出方承担责任。若未通过评审，则需重新进行有关的需求分析工作。 需求开发的过程如图3-4所示。图3-4需求开发的过程 3.1.3.2 需求管理 由于基于计算机系统的需求常常要变更，而且变更需求的要求贯穿于整个生命期，所以，完成需求开发，形成规格说明仅是需求成功的一半，开发人员必须能够真正把所有客户的需求应用到产品中，并能够有效地控制需求变更，才能保证需求与设计的一致性，最准确地实现既定的需求。需求管理就是一组在软件开发进展中的任何时候标识、控制和跟踪需求的活动。 需求管理的内容包括在工程进展过程中为保证需求集成性及精确性所进行的所有活动，具体内容包括需求变更控制、版本控制、需求跟踪和需求状态跟踪。第045页 (1)需求变更控制：建议变更；评审所提出的需求变更，评估分析每项变更可能的影响，从而决定是否实施变更；以一种可控制的方式将需求变更融入到项目中。 (2)版本控制：建立需求基准版本和需求控制版本文档，确定一个需求基准。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。需求文档的每一个版本必须被统一确定，在变更时，应记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。可采用版本控制工具自动完成这些任务。 (3)需求跟踪：跟踪所有受需求变更影响的工作产品，让每项需求都能与其对应的设计、源代码和测试用例联系起来。当进行某项需求变更时，与其相关部分可能也需要修改。通过需求跟踪所建立的联系，可方便地找到相关的其他需求、设计模板、源代码和测试用例。通过跟踪减少当变更需求时必须进行的变更被遗漏，确保覆盖全部的需求，同时确保所有的输出符合用户的需求。 (4)需求状态跟踪：定义需求状态，在整个项目过程中跟踪需求的每一个状态及其变更情况。可将跟踪每项需求的状态建立一个数据库，其中每一条记录保存一项功能需求的重要属性。需求状态有已推荐的、已通过的、已实施的或已验证的等，这样在任何时候都能得到每个状态类的需求数量。 需求开发的结果是形成了客户与开发人员双方均满意的系统逻辑模型，它连接需求开发和需求管理，作为需求管理的输入。需求管理的过程，从需求获取即开始，并贯穿于整个软件项目生命周期，以实现最终产品同需求的最佳结合。 需求开发与需求管理间的关系可用图3-5来表示。图3-5 需求开发与需求管理间的关系3.2获取需求的方法 综上所述，需求分析的主要任务，就是正确理解和表达用户的要求，但如何从应用领域获取所需知识，往往造成需求分析的障碍，所以获取需求是需求分析的关键的一步，也是最困难、最易出错的一步。第046页3.2.1 存在问题 在获取需求过程中遇到的典型问题有： (1)对需求的理解问题。要准确、完整地获取需求必须对问题进行深入的理解与把握。而大多数情况下，应用领域具有一定的专业性，分析人员不是问题领域的行家，造成理解问题。 (2)分析人员与用户的通信问题。由于分析人员不懂特定的业务，需要通过用户的描述来了解。而用户对应用问题的理解、描述以及他们对目标系统的要求往往具有片面性、模糊性，在很多情况下，用户往往不能正确表达他们的需求。而且用户多是考虑业务领域本身，而分析员对问题的理解必须从信息处理要求出发，所以与用户建立相互信任，有效地沟通是分析员的首要任务。 (3)用户需求的可变性问题。应用领域与用户需求具有多样性，由于用户领域的业务不断扩展或者转移、市场竞争的要求或用户主管人员的变更等原因，使得用户的需求常发生变化。需求的可变性就要求分析员能够使其工作适应需求的变化，给需求分析造成了很大的困难。 (4)分析方法和分析工具问题。需求分析方法论和分析工具的缺乏，及其应用范围的局限性是造成障碍的又一原因。3.2.2 常用方法 需求获取方法是沟通用户和开发人员之间的桥梁。目前，需求分析方法中，用户需求获取主要是依靠以下几种方法： (1)访谈。 访谈是最早开始使用的获取用户需求的方法，也是目前仍然广泛使用的需求分析技术。 访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题，例如，询问处理的单据种类、处理的方法以及信息反馈时间应该多快等。而在非正式访谈中，分析员可提出一些用户可以自由回答的开放性问题，例如，询问用户对目前正在使用的系统有哪些不满意的地方，以鼓励被访问人员说出自己的想法。询问一个开放的、可扩充的问题将有助于更好地理解用户目前的业务过程，并且确定在新系统中应如何解决目前系统的问题。分析人员通过用户对问题的回答获取有关问题及环境的知识，逐步理解用户对目标系统的要求。 采用访谈方式时分析员的主要任务是问题的设计，包括探讨功能、非功能、例外情况的问题，甚至一些看起来“愚蠢的问题。必须把所有的讨论记录下来，同时还要做一定的整理，并请参与讨论的用户评论并更正。 (2)问卷调查。 问卷调查即把需要调查的内容制成表格交给用户填写。该方法对需要调查大量人员的意见时十分有效。这种方法的优点是：用户有较宽裕的考虑时间和回答时间。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确，从而可以得到对提出的问题较为准确细致的回答。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。 采用问卷调查方法的关键是调查表的设计。在开发的早期用户与开发者之间缺乏共同语言，用户可能对表格中的内容存在理解上的偏差。因此调查表的设计应简洁、易懂、易填写，同时还要注意用户的特点和调查的策略。第047页 (3)情景分析。 由于很多用户不了解计算机系统，对自己的业务如何在将来的目标系统中实现无认识，所以很难提出具体的需求。所谓情景分析就是对目标系统解决某个具体问题的方法和结果，给出可能的情景描述，以获知用户的具体需求。 情景分析技术的优点是，它能在某种程度上演示目标系统的行为，便于用户理解，从而进一步揭示出一些分析员目前还不知道的需求。同时，让用户起积极主动的作用对需求分析工作获得成功是至关重要的，情景分析较易为用户所理解，使得用户在需求分析过程中能够始终扮演一个积极主动的角色。因此在访问用户的过程中使用该技术是非常有效的。 (4)实地考察。 分析人员到用户工作现场，实际观察用户的手工操作过程也是一种行之有效的需求获取方法。 在实际观察过程中，分析人员必须注意，系统开发的目标不是手工操作过程的模拟，还必须考虑最好的经济效益、最快的处理速度、最合理的操作流程、最友好的用户界面等因素。因此，分析人员在接受用户关于应用问题及背景的知识的同时，应结合自己的软件开发和软件应用经验，主动地剔除不合理的、一些暂时行为的用户需求，从系统角度改进操作流程或规范，提出新的潜在的用户需求。 (5)构造原型。 在系统开发的早期，以对用户所进行的简单需求分析为基础，快速建立目标系统的原型。用户可以通过原型进行评估并提出修改意见，从而使用户明确需求。快速原型方法既可针对整个系统，也可针对系统的某部分功能o（快速原型方法内容详见3.4节）o3.2.3 需求分析的原则 需求分析应遵循以下原则： (1)解决逻辑问题。 需求分析是对问题的识别和说明过程，分析员要回答的是“系统必须做什么”的问题，而不是“系统应该怎么做”的问题。需求分析的基本原则是给出要完成的功能和处理的信息，而不考虑实现的细节，即需求分析工作集中在系统应当完成什么功能上，而不在怎样才能实现这些功能上。 (2)以运行环境为基础。 需求分析工作必须以具体的运行环境为基础，系统分析人员可以参考，但不能照搬其他类似的系统开发时的分析工作，更不能凭个人的好恶或主观想象办事。 (3)用户参与的原则。 需求分析工作是系统分析人员同用户不断交互的过程。因此，需求分析工作应该要有客户（开发委托者或开发委托者兼系统使用者）所指定的人员参加，以保证交互的充分性和工作效率。 (4)构造高质量的需求规格说明。 需求规格说明是需求分析工作重要的完成标志。在生成规格说明的有关文档的过程中，分析人员应该严格遵循既定规范，做到内容全面、结构清晰、格式严谨。 3.2.4 需求分析方法概述 随着软件开发技术的发展，目前已形成许多需求分析及描述的方法，每种方法都有其独到之处。第048页但不管采用哪种方法进行需求分析，都应满足如下基本要求： (1)必须能理解问题的数据域和功能域。 一个软件从外部可以被看成是一个黑盒子，信息从一端流入，从另一端流出。在内部对输入信息进行转换，形成中间结果，再转换，最终得到所需要的输出信息，就是软件所具有的功能。所以可通过对数据的描述和数据转换的描述，实现对系统的理解和描述。 计算机程序所处理的数据域的描述一般为：数据内容、数据结构和数据流。数据内容就是数据项，数据结构就是数据项的组织形式，数据流是数据通过系统时的变化方式。 对数据进行的一系列的转换即系统应实现的功能和子功能。两个功能之间的数据传递就确定了功能之间的接口。在需求分析阶段的功能描述通常是用文字说明要“做什么”，不必具体展开怎样做。 (2)必须能按自顶向下、逐层分解的方式对问题进行分解和不断细化。 现实世界是复杂多变的，从整体上考虑一个问题通常是困难的。特别是一些复杂的问题，作为一个整体很难准确理解，不可能给出正确的解决方案。此时，对问题进行分解与抽象是普遍有效的基本法则。 分解是将求解的复杂问题，分解为若干相对简单问题求解的组合。例如实现一个教学管理系统，可以将该系统分解为学生管理、教师管理、课程管理、教务管理、考试管理等5个子系统。定义好各子系统之间的相互联系，对每个子系统分别求解。如子问题仍然较复杂，则可以进一步分解。如可将考试管理进一步分解为试题库维护、试卷生成、考务管理、学生考试和评阅试卷等子系统。 分解的目的是为了降低问题求解的复杂性，将复杂问题分解成一些小的、容易控制和理解的子问题不仅便于理解，还可以将子问题划分给不同的开发小组，分别完成，然后再装配起来形成一个完整的系统。更重要的是通过分解，可以促进软件开发走向构件开发的道路。因为划分的小问题中有些是常见的公共问题，有些是特殊的问题。对常见的公共问题可以复用已有的软件构件，开发人员只对特殊的问题提供解决方案。这样不仅可提高软件开发的效率，还使软件开发向着“工程化”方向迈进。 在需求阶段分解的内容，可以是软件的功能域和数据域两个部分，分解的方式有横向分解和纵向分解。横向分解在同一层次上，把一个功能分解为几个子功能，并确定这些子功能与父功能之间的接口；纵向分解是将一个功能分解为几个子功能，然后对其中复杂的子功能再继续分解为更小的子功能，逐层分解下去直到获得合适的子功能为止。在实际操作中，没有单纯的横向分解或纵向分解，通常是二者相结合的分解方式，如图3-6所示。 而抽象是认识问题的一般与特殊的关系。例如在上述的考试管理子系统中，可以考虑考试要求的不同试题类型，构造每种类型的典型试题，通过对典型试题的答题要求和阅卷判定方法分析，抽象出各类试题的不同答题模式和计算机阅卷策略与算法。 问题分解与抽象定义了问题的层次结构，应该在问题求解中反映出这种层次结构。结构与问题求解结构的对应关系保证了问题定义的完整性、正确性和可跟踪性。 (3)要给出系统的逻辑视图和物理视图。 软件需求的逻辑视图描述的是软件要达到的功能和要处理的信息之间的关系，但没有描述实现的细节。如库存系统中的检查库存的功能，在逻辑视图中只关心库存文件的数据结构，而不考虑计算机的具体存储方式。软件需求的逻辑描述是软件设计的基础。 软件需求的物理视图给出的是处理功能和信息结构的实际表现形式，需考虑实际的环境和具体的设备。如一些数据是由终端键盘输入的，而有些数据可能是由模一数转换设备第049页提供的。软件分析人员必须弄清已确定的系统元素对软件的限制，并考虑功能和信息的物理表示。注意此时功能和信息的物理表示只限于“系统必须做什么的范围，而不考虑“如何做”的细节。图3-6 问题的分解 由上述讨论可见，系统的逻辑视图和物理视图描述了系统满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件。3.3结构化分析法法 结构化方法是20世纪70年代初，由E.Yourdon、L.Constantine、T.DeMarco等人提出的一种系统的软件开发方法，包括结构化分析(SA)、结构化设计(SD)和结构化编程(SP)。结构化分析方法，多年来被广泛应用，是最经典的面向数据流的需求分析方法。适用于分析大型的数据处理系统。3.3.1 结构化分析方法的基本思想 SA方法以数据流分析作为需求分析的出发点，任何信息处理过程均看作是将输入数据变换成所要求的输出信息的装置。而当分析人员面对一个复杂的问题时，结构化分析的策略是基于问题分解与抽象的观点，用抽象模型概念，按照软件内部的数据传递关系，采用自顶向下、逐层分解技术，直至找到满足功能需求的可实现软件元素为止。 该方法的特点是利用数据流图来帮助人们理解问题，对问题进行分析，即利用图形工具来模拟数据处理过程。该方法的核心是数据流图。数据流图是一种用来表示信息流程和信息变换过程的图解方法，它将系统看成是由数据流联系的各种功能的组合。数据流图可以方便地描述由数据流的流动联系的各种功能。通过各种功能的输入输出结果，表现现有系统或待开发系统的功能。 具体做法是首先将整个系统看作一个加工信息处理的装置，是一个黑匣子，标识出系统边界和所有输入输出数据流。然后自项向下，对加工内部进行细化，逐层分解，将复杂第050页功能分解为若干简单功能的有机组合，绘制数据流图，并逐步补充细节描述。通过将系统分解成多层处理后，在较低层次上，可以看到数据流图的高层次加工的细节和相关的数据流。用数据字典精确定义数据流图中每个数据流的成分及每个成分的属性、数据结构、数量、传递方式等。用结构化英语、判定树和判定表对数据流图中的每个加工的功能进行描述。 结构化分析方法的实质就是一种强烈依赖数据流的自顶向下的建模方法，采用一组分层的数据流图及相应的数据字典作为系统的逻辑模型。它不仅是需求分析技术，也是完成规格说明文档的技术手段。3,3.2描述工具 SA方法提供一套图形、表格和结构化语言等半形式化的描述方式表达需求，简明易懂。描述工具包括： (1)数据流图（Data Flow Diagram,DFD）：描绘系统逻辑模型的图形工具，描述了系统的组成部分及各部分之间的联系。通常通过对系统的分解得到一套分层的数据流图。 (2)数据字典（Data Dictionary,DD）：DFD只描绘信息在系统中的流动和处理情况，而数据字典则是对图中的元素进行定义。 (3)结构化英语、判定表和判定树：详细描述数据流图中一些复杂处理的加工逻辑。3.3.3数据流图 SA方法使用数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能，是一种功能模型，如图3-7所示。图3-7 一个学生选课系统的DFD3.3.3.1基本符号数据流图中的基本图元包括：O：圆框，表示加工。口：方框，表示数据的源点或数据的终点。一：箭头，表示被加工数据的路径和流向，即数据流。-：双杠，表示数据存储，可以是一个记录或一个数据文件，可用名词或名词性短语命名。第051页 1数据源点和数据终点 数据源点和数据终点用方框表示，它是系统之外的实体，可以是人、物、部门或者其他系统，如图3-7中的教师和学生。数据源点是数据流的起点，数据终点是系统数据流的最终目的地。利用数据源点与终点明确标识出系统与环境的接口，给出系统有效作用范围的边界。 2加工（数据处理变换） 加工用圆框表示，是对数据进行处理的逻辑单元。它接受若干输入数据流，通过加工内部产生规定的输出数据流。数据流图中对加工的标识通常由加工编号和加工命名组成。如图3-7中的学生选择课程、注册课程和打印表格都是加工的例子。为了给读者理解系统提供有意义的信息，对加工的命名通常要求使用“动词+宾语”形式的结构化语言简单明确地进行标识。例如“注册课程”，“打印报表”等，不应使用如“计算、“处理”、“加工”等抽象名词作为加工命名。如果一个加工很难给出适当的命名，应该考虑该加工的处理功能是否恰当，是否应该重新分解。 3数据流 数据流用带数据流标识的箭头表示，表示系统处理的数据对象和数据流动的方向。数据流的方向可以是：从一加工流向另一加工；从加工流向数据存储或数据存储流向加工；从源点流向加工或从加工流向终点。 当数据流的方向指向一个加工时，表示它是该加工的一个输入数据流；当数据流的方向是从一个加工发出时，表示它是通过该加工得到的一个输出数据流。数据流是客观世界的实体对象的逻辑表示，可以是一个数据项，也可以是一组数据项组成。例如图3-7中“费用”由“学生学号”、“注册课程号”和“金额”组成。一个数据项可以是基本项（不可再分解的数据项，如组成“费用”的数据项），也可以是结构型数据项。例如“选课单由“学生学号”和“注册课程列表”组成，“注册课程列表由若干“注册项”构成，每个“注册项”由“课程名”、“课程号”、“学分构成。 每个数据流应有良好的命名，它不仅作为数据的标识，还有利于深化对系统的认识。可以考虑使用数据流中最主要的数据项作为该数据流的名称。与加工命名类似地，应该避免使用诸如“数据”、“信息”之类地抽象名词标识数据流。因为加工是一个进行数据处理的黑匣子，因此流入、流出同一加工的数据流应该具有不同的名称。数据流不应包括控制流。数据流反映的是加工处理的对象，控制流是一种选择或用来影响加工的性质，而不是对它进行加工的对象。例如图3-8中的“读下张卡片”即属于控制流，不应该在数据流图中画出。图3-8含有控制流的例子 4数据存储 数据存储用两条平行线段表示，逻辑上是信息的静态存储。物理上，DFD中的数据存储可以是计算机系统中的外部或者内部文件、文件的一部分、数据库的元素或记录的一部分等，还可以是一个人工系统中的表册、账单等。数据存储是系统的重要组成部分，在分层数据流图中，通常是局部于某一分解层次的。数据存储可用名词或名词性短语命名，还需要在数据词典中说明其逻辑或者物理组织要求以及存储介质等。一个数据流从加工流向第052页数据存储，表示该加工对文件写；如果数据流是从数据存储流向加工，表示该加工对文件读。如果加工到数据存储之间的数据流是双向的，表示该加工对文件的操作包括读、写和修改。流入、流出数据存储的数据流的名字通常和数据存储同名，可以不标识。 3.3.3.2 数据流与加工之间的关系 在数据流图中，两个加工之间可以有多个数据流。如果有两个以上的数据流指向同一加工，或一个加工流出两个以上数据流，则这些数据流之间往往存在一定的关系。为表达数据流之间的逻辑联系，可以附加说明标记符号。常见的说明符号及含义如图3-9所示。 图3-9(a)表示流入加工的两个数据流必须同时到达，该加工才能启动。 图3-9(e)表示流入加工的两个数据流只要有一个到达，该加工即可启动。 图3-9(c)表示流入加工的两个数据流不能同时到达。 对于图3-9(b)、图3-9(d)、图3-9(f)则是对流出加工的数据流相应关系的对应解释。图3-9流入流出同一加工数据流 3.3.3.3 数据流图的分层 对于一个大型软件系统，不可能将全部最终的加工和数据流都在一张图上表现出来。这样图面太大，关系复杂，难以理解。结构化控制复杂性的方法，是采用分层技术，用一套分层DFD来分解复杂性。分层体现了抽象和信息隐蔽，即上层不考虑下层的细节，暂时掩盖了下层加工的功能及它们的复杂关系。 一个软件系统的一套分层DFD图包括顶层DFD、中间层DFD和底层DFD组成。顶层图只有一张，它描绘了整个系统的作用范围，可将整个系统作为一个加工，其加工名就是系统名，输入和输出就是系统的所有输入和输出数据，也就是系统与外界的接口；中间层的DFD图是对上层父图的分解，它的每一加工还可继续分解细化。当分解一直进行到每个加工的功能独立，简单明确，数据流被严格定义时，即得一组底层DFD图。每张底层DFD图是由一些不能再分解的加工和简单数据流组成，这些加工被称之为基本加工。第053页显然，这种自顶向下，逐层地理解和表达系统的分层DFD图，是一个控制复杂度，保证分析质量的很好的系统分析方法。 分解示意图如图3-10所示。图3-10分层数据流图 为了控制分解过程，严格地表现一套DFD图，引入如下概念： (1)父图与子图。如图3-11所示的顶层图是整个系统的抽象表示，如果系统S可分解为三个子加工S 1、S2、S3，画出相关的数据流，得到顶层下的第一层数据流图。继续分解S 1、S2、S3，得到多层的数据流图。其中上一层图是其分解的下一层图的父图。相反下一层图是上层图的子图。父图里的加工是其相应子图的抽象表示，子图则是其父图中相应加工的细化。图3-11 分解示意图 (2)分层图编号。顶层图中加工，即整个系统的编号以O表示，以下每一张子图的编号就是上图中相应加工的编号，而子图中每个子加工的编号应该是子图号，加小数点，加局部加工号。在一张分层图中，每个加工的编号中所含小数点的个数，就是该图的层次数。图3-11显示了这一编号规则。 (3)父图和子图数据流的平衡性。在绘制分层DFD图时，必须注意子图与其父图中相应加工的数据接口保持平衡，即父图中流入流出某加工的数据流，与分解后子图中流入流出加工的数据流应保持逻辑上的一致。控制分层DFD图的数据流的平衡性，是消除DFD第054页图错误的一个重要手段。例如图3-12(b)是图3-12 (a)中S3的分解，父图中流入S3的数据流为M、N，流出S3的数据流为O，而在图3-12(b)中流入的数据流少了M，显然是错误的。 注意，很多情况下父图和子图数据流的平衡性，不一定是数据流的名称和个数的形式一致，如图3-12 (cl)所示，流出的数据流为J、K，从表面上看，数据流的名字和数量与图3-12(a)中流入流出S3的均不一致，但若数据流J、K是随着对图3-12(a)中加工S3的分解