传统服装软件需求分析

CDIO教育思想认为，“构思”即按照客户的需求，考虑技术、企业战略等因素，设立系统目标和要求；定义功能、概念和结构，为项目的设计、实现和运作奠定基础。由于需求分析是依靠分析技术，对待开发软件系统所对应的问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，并按照某种规范形成需求规约的过程。因此，需求分析正是对待开发软件进行构思的阶段。本篇从传统分析方法和面向对象分析方法两个层次分别讨论了需求分析过程。

传统服装软件需求分析
虽然现代软件工程方法有了长足的发展，但是传统方法学在软件开发过程中仍然占有一定的比重，为许多软件工程师所青睐 。
在传统的软件工程方法中，软件的过程分为需求分析、设计、编程和测试等阶段。传统的方法学主要使用的是结构化分析技术来完成需求分析和设计等各个阶段的工作，它强调以模块为中心，采用模块化、自顶向下逐步求精的设计过程，从系统的功能人手，按照工程标准来开发出相应的软件系统。

1．1需求分析与需求工程
1．1．1软件需求和需求分析
服装软件需求可定义为为用户解决某一问题或达到某一目标所需的软件功能；系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。软件需求包括三个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求)。
1)业务需求(BusinessRequirement)业务需求反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
2)用户需求(UserRequirement)用户需求文档描述了用户使用产品必须要完成的任务,这在使用实例(usecase)文档或方案脚本说明中予以说明。
3)功能需求(FunctionalRequirement)功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
在软件需求规约说明书(SoftwareRequirementsSpecification，SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规约说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，另外一些可能属于子系统(或软件部件)。 作为功能需求的补充，软件需求规约说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
所谓需求分析，是指对要解决的问题进行详细的分析，弄清楚问题的要求。而在软件工程中，软件需求分析就是把软件计划期间建立的软件可行性分析进行求精和细化，分析各种可能的解法，并且分配给各个软件元素。
需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求，它是软件工程中的一个十分关键的活动。在这个活动中，系统分析员和软件工程师需要明确地确定顾客的需求；只有这些需求确定了之后，才能够分析和寻求建立新系统的解决方法。

需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规约说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规约说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

需求分析指的是在建立一个新的软件系统或改变一个现存的软件系统时对系统的目的、范围、定义和功能等进行描述时所要做的一切工作。需求分析的任务是确定对系统的综合要求。虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统而言包括的需求有：功能需求、性能需求、接口需求、出错处理需求、可靠性和可用性需求、系统约束、将来可能提出的要求等。在进行需求分析时，假如分析者们未能够正确地认识到客户需要的话，那么最后的软件实际上不可能满足客户的要求，或者软件无法在规定的时间里完工。在进行需求分析时，往往需要关注需求分析的过程和进行需求获取的方法。

1．1．2需求工程
需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模小，软件开发所关注的主要是代码的编写，需求分析很少受到人们的重视。随着软件系统规模的扩大和软件危机的出现，引人了软件工程的概念，需求分析成为生命周期中的第一阶段。后来，人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。20世纪80年代中期，形成了软件工程的子领域——需求工程(RequirementEngineering，RE)。进入90年代以来，需求工程成为研究的热点之一。
需求工程是指应用已证实有效技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。需求工程强调需求分析不是一个独立的阶段而是存在于整个软件过程中，通过进行需求演进活动尽可能满足用户需求。需求工程不仅包括需求获取、需求分析和需求规约说明等阶段，还包括原来一直被忽略的软件需求过程的两个重要阶段一～如何衡量软件需求的质量，以及如何处理软件需求的不断变化。这种认识反映了需求的动态变化特性和需求的模糊性，并且也符合人类的认知过程。需求工程的提出是从时间的角度来降低需求分析的复杂性，提高需求分析的可靠性。如今，需求工程强调用工程化的方法进行需求开发和需求管理。
需求工程可分为系统需求工程和软件需求工程。系统需求工程是针对由软硬件共同组成的整个系统；服装软件需求工程仅是针对专门的纯软件部分，是一门分析并记录软件需求的学科。它把系统的需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究和原型开发等过程把这些系统需求转换成软件的需求描述和一些性能参数。

1．1．3需求工程与系统工程
需求分析是确定系统需要做什么，即软件或系统必须达到的目标和能力。需求分析使得软件分析员能够刻画出软件的功能属性和非功能属性需求及相关的领域需求；指明软件和其他系统元素的接口；建立软件必须满足的约束。同时也允许软件分析员精化软件分解模块，并建造将被软件处理的数据、功能和行为模型。需求分析为软件设计者提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为开发者和客户提供了软件建造完后质量评估的依据。
但对于需求工程来说，内容远不止这些。需求工程是系统工程和软件工程的一个交叉分支，涉及软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境等。它还涉及这些因素和系统的精确规约说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。
可以说，需求工程是软件项目成功的核心所在，它贯穿于系统开发的整个生命周期过程中，对软件开发生命周期中其他过程和活动具有重大的影响作用。
1)需求的确定是制定项目计划的基础开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。需求是软件或系统必须达到的目标和能力，只有需求确定之后，才能制定出满意的软件项目开发计划。通常，项目计划指出所有希望的特性不可能在允许的资源和时间内完成，因此，需要缩小项目范围或采用版本计划对功能特性进行选择。
2)需求工程是项目跟踪和控制内容之一项目进行中，需要监控每项需求的状态，以便项目管理者能发现设计和验证是否达到预期的要求。如果没有达到，管理者通常请求变更控制过程来进行范围的缩减。
3)需求工程和变更控制之间相互影响在需求工程过程中编写完文档并制定出基线之后，所有接下来的变更都应通过确定的变更控制过程来进行。需求工程既是变更控制的前提，也是变更控制的结果。变更控制过程能够确保：
(1)变更的影响是可以接受的。
(2)由合适的人选来作出接受变更的正式决定。
(3)受到变更影响的所有人都接到通知并明白这一点。
(4)保持需求文档是最新版本并是准确的更新文档。
4)用户需求和功能需求是系统测试的重要参考
系统测试的目的是为了保证开发出来的软件系统能够满足用户的需求，如果没有清楚说明用户对产品的期望，系统测试者就很难明确正确的测试内容。反过来，系统测试也可以验证需求中所列的功能是否按预期要求实现了。
5)软件的需求是用户编制文档的重要参考
低质量和拖延的需求会给编写用户文档带来极大的困难。
6)需求说明文档是所有软件设计和实现工作的基础和关键项目主要产品是交付可执行软件，而不是需求说明文档。但是所有的软件设计和实现工作都需要基于需求文档来进行。要根据功能要求来确定设计模块，而模块的设计又要作为编写代码的依据，只有准确合理的需求分析结果才有利于后面的设计和实现工作。

1．1．4需求工程的重要性及复杂性
在软件工程发展初期的很长时间里，需求分析被认为是整个软件工程中最简单的一项活动而被忽视。但是随着软件规模的扩大，人们发现开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，包括所有面向用户、面向机器和其他软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。从而，需求分析越来越受到人们的广泛关注。
在需求工程活动中，系统分析员和软件工程师需要明确地确定顾客的需求；只有这些需求确定了之后，他们才能够分析和寻求建立新系统的解决方法。假如在需求分析时分析者们未能正确地认识到顾客的需要，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。
因此，需求工程在整个软件开发与维护过程中越来越重要，是当前软件工程中的关键问题，直接关系到软件的成功与否。
需求分析是一项重要的工作，也是最困难的工作。该阶段工作有以下特点：
1)用户与开发人员很难进行交流在软件过程中，其他各个阶段都是面向软件技术问题，只有本阶段是面向用户的。需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该“做什么”。但是在开始时，开发人员和用户双方都不能准确地提出系统要“做什么”。因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
2)用户的需求是动态变化的对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来困难。
3)系统变更的代价呈非线性增长需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一小时的时间，到设计、编程、测试和维护阶段解决，则要花2．5、5、25甚至i00倍的时间。

总之，需求工程面对的问题几乎是没有范围的，它的难度不仅体现在非功能性需求及其与功能性需求的错综复杂的联系上，还体现在需求工程需要方方面面人员的参与(如领域专家、领域用户、系统投资人、系统分析员、需求分析员等)，各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。

1．2软件需求工程过程
1．2．1软件需求工程活动
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。它由一些活动组成，通常可分为需求开发和需求管理两部分。需求开发的任务是收集和分析来自用户或市场等各方面的需求，编写规约说明文档，并采用评审、商议等有效手段对其进行验证，其最终结果作为一个需求基线。需求开发又可进一步分为需求获取、需求建模、编写规约说明和需求验证四个阶段。由于软件开发过程中经常发生需求变更的情况，如何管理和控制这些变更也成为需求管理的重要任务。需求工程的具体活动如图3-2所示。
因此，一般可以把需求工程的活动划分为以下5个独立的阶段。
(1)需求获取。通过与用户交流，对现有系统进行观察及任务分析的基础上，开发、捕获和修订用户的需求的过程。
(2)需求建模。基于需求的获取，为用户最终所看到的系统建立的一个概念模型；需求建模作为对需求的抽象描述，应尽可能多的捕获现实世界的语义。
(3)形成需求规格。生成需求模型构件的精确图3-2需求工程活动的形式化的描述，作为用户和开发者之间的一个协约。
(4)需求审查和验证。以需求规约说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。
(5)需求管理。为了支持系统的需求演进，解决需求变化和可跟踪性等问题。

1．2．2需求抽取和发现
软件需求包括功能需求、非功能需求和设计约束三方面内容。功能需求是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
非功能需求是指软件产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。
设计需求，通常是对解决方案的一些约束说明，如必须运行的操作系统等。
需求抽取和发现是指收集准备建立的系统和正在使用的系统的信息，并从这些信息当中提取用户和系统需求。为了收集到全面完整的信息，需求获取可以通过对现有系统分析、与潜在用户和购买者交流、讨论等方式来导出软件系统的需求；也可以开发一个或者多个系统模型或原型来帮助用户更好的表达系统的需求，这样有利于系统分析员了解所要描述的系统的功能。需求发现阶段的信息源包括已有文件、系统信息持有者以及类似系统的相关内容。
在确定功能需求之后，还需要考虑用户非功能方面的需求，包括系统性能、有效性、可靠性和可用性等，提高用户对软件的满意程度。总之，需求的抽取和发现活动可能涉及机构中方方面面的人，是一个复杂困难的过程。

1．2．3需求建模和文档化
在问题分析阶段分析人员的主要任务是对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。
在需求开发中通过建立模型来确认理解需求。模型描述了问题域的逻辑方面，如数据组成、事务和转换、现实世界对象和允许的状态，或者可以从文本需求出发来画模型，从不同的角度来表示这些需求，或者可以从所画的基于用户输入的模型来获得功能需求。但是，分析阶段所建造的模型不应涉及软件实现细节，因为这样会分散分析人员的注意力，限制软件设计人员为提高软件的质量和效率而选择实现方法放入自由度。需求分析的核心在于建立分析模型。通常，需求分析可以采用多种形式(如文本和图形等)来描述需求，通过建立需求的多种视图，揭示出一些更深的问题。需求分析建模的方法有很多，其中最重要的是结构化分析和面向对象分析。结构化分析方法通过提供实体关系图、数据流图和状态转换图等图形模型，来进行数据建模、功能建模和动态建模。而面向对象分析方法则是以用例模型为核心，提供类图、对象图、状态图、时序图、协作图、活动图、构件图和分布图等图形模型，建立设计视图、进程视图、实现视图和分布视图等。

需求开发的最终结果是要编写规约说明。软件需求规约说明精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规约说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和程序设计的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规约说明不应该包括设计、构造、测试或工程管理的细节。可以用以下三种方法编写软件需求规约说明：
(1)用好的结构化和自然语言编写文本型文档。
(2)建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类以及它们之间的关系。(3)编写形式化规约说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。
由于形式化规约说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规约说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规约说明。
编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。

1．2．4需求审查和验证
许多软件开发人员都经历过在开发阶段后期或在交付产品之后才发现需求问题的情况。在软件开发完成以后，再回头去修补由于需求的原因导致的错误需要大量的时间和精力。根据一些相关的研究表明，与在需求分析阶段发现错误然后进行改正相比，在开发后期或在交付产品之后纠正同一个错误需要多花68～110倍的时间和精力。因此，为了能够节省开发的时间和成本，在未进行开发之前对需求规约说明进行验证就显得极其重要。

需求验证就是为了确保需求说明的准确和完整而进行的活动，它是针对那些已编写成文档的需求，而对于那些存在于用户或开发人员思维中的没有表露的、含蓄的需求则不予验证。
需求验证包括需求评审和需求测试两个部分。

需求文档的评审是一项精益求精的技术，它可以发现那些具有二义性的、不确定的和那些由于定义不清而不能作为设计基础的需求，还有实际上是设计规约说明的所谓的“需求”。在需求评审阶段，分析人员要在用户和软件设计人员的配合下对已经生成的需求规约说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰和具体，并使用户和软件设计人员对需求中的特定问题达成共识。一旦发现遗漏或模糊的地方，就必须尽快更正，并再行检查。软件的需求评审包括非正式评审和正式评审两种。非正式评审一般是指把需求文档分发给许多其他的开发人员粗略看一看或走过场似地检查一遍，并根据检查的结果给出意见。非正式评审有利于培养他人对需求的了解和认识并获得非正式的反馈意见，但非正式评审是非系统化的、不彻底的，或者在实施过程中具有不一致性。非正式评审可以根据个人爱好的方式进行评审。正式评审则是遵循预先定义好的一系列步骤来进行，评审内容需要记录在案。正式评审的内容包括确定材料和评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。

正式技术评审的最好类型叫作审查，对需求文档的审查是可利用的最高级软件质量技术。一些公司已经认识到在审查阶段上花费一个小时，那么在其他阶段就可节省10多个小时的工作时间。

但是对需求文档的审查也不是一件容易的事，它会面临着许多困难，如大型的需求文档(大型的软件需求规约说明可能包括几百页的内容)的审查是令人畏惧的；许多需求审查都需要建立一个庞大的审查小组，而庞大的审查小组将导致会议难于安排，并且经常在许多问题上也难于达成一致意见；审查员在地域上越来越分散，地域上的分散性使需求审查更加困难。需求评审是一种有效的需求验证手段，但是仅仅通过阅读软件需求规约说明，通常很难想像出在特定环境下的系统行为。例如，当你阅读软件需求规约说明时。可能觉得需求是对的，但实现却很可能会出现问题。因此，可以以需求说明为依据编写测试用例来进行检验，即根据用户需求所要求的产品特性写出黑盒功能测试用例，客户通过使用测试用例以确认是否达到了期望的要求。同时，还可以从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。这种方法虽然没有在运行系统上执行测试用例，但是设计测试用例的过程可以解释需求的许多问题，从而及早地发现需求规约说明中的一些错误和缺陷。

1．2．5需求管理随着计算机技术的飞速发展，软件已经成为人们生活中不可缺少的一部分。人们在使用软件的过程中，常常会抱怨它无法执行某些基本操作。对于软件开发人员而言，用户不断提出新的要求又是一件十分烦人的事。但是当需求说明完成之后，不可避免地还会遇到项目需求的变更。在软件开发过程中或软件提交之后遇到的许多问题，都是软件需求过程中的失误和需求的不断变化带来的。可以这样说，软件项目中40％～60％的问题都是在需求分析阶段埋下的“祸根”。

既然需求的变更不可避免，那么对需求变更进行有效管理就变得十分重要。需求管理可定义为一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在客户与开发人员之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理的具体内容将在项目管理部分进行阐述。

1．3软件需求获取
需求获取(RequirementElicitation)是需求工程的主体。对于所建立的软件产品来说，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。

1．3．1需求获取活动
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解，一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。需求包括业务需求、用户需求和功能需求以及非功能需求，在需求开发之前，需要先定义好需求开发的过程，形成文档，内容包括：需求开发的步骤，每一个步骤如何实现，如何处理意外情况，如何规划开发资源等。需求获取就是进行需求收集的一个活动，它从人员、资料和环境中得到系统开发所需要的相关信息。需求获取是一个需要高度合作的活动，并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。需求获取不是一个简单地进行知识转移的活动，为了能够解决需求获取中普遍存在的问题，获取活动至少要做到：确定待获取信息的内容；确定待获取信息的来源；确定应采取的获取方法；执行获取；记录获取成果。

1．3．2获取需求的内容
需求分析是使软件分析员能够刻画出软件的功能属性和非功能属性需求及相关的领域需求、指明软件和其他系统元素的接口，并建立服装软件必须满足的约束。
一般来说需求工程需要获取的信息内容主要有以下三种。
1)需求需求是需求获取的主要对象，也就是系统期望达到的功能和非功能的目标。它主要来源于用户、客户、领域专家等相关涉众，在获取中体现为相关人员的问题、期望、观点、看法和态度等。分析人员应该与各种层次的客户进行充分的交流和沟通，包括决策领导、使用部门的领导、具体使用人员和系统维护人员等，尽量清楚地理解用户的问题和要求。
2)问题域描述在需求获取的过程中，软件人员与用户之间最常见的交流方式就是会议和访谈，由于双方的知识领域不同，经常会遇到误解、交流障碍、需求不全和意见冲突等情况。因此，需要借助问题域的描述来解决交流的问题。问题域描述是用来承载和解释需求的问题域特征，主要是现实环境的业务运行状况。它可以从用户等相关人员的业务描述中获得，也可以从业务运行过程中所产生的各种数据文档中获得。
3)环境与约束软件需求不仅要描述系统期望达到的功能和非功能的目标，同时也需要描述系统相关的环境和约束。环境与约束属于一种特殊的问题域特征，限定了解系统部署的环境和条件。之所以将其单独列举出来，是因为它常常在需求获取中被人们遗漏。它们主要来源于用户及相关人员的描述和对应用环境的观察。无论是需求、问题域描述，还是环境与约束，它们都要和项目前景保持一致，都要界于项目的范围之内。

1．3．3获取需求的来源需求获取的关键是通过与用户的沟通和交流，收集和理解用户的各项要求。而软件需求可以来自方方面面，这取决于所开发软件系统的性质、开发环境和相关的人员。为了能够获得完整、准确、清晰、具体的需求，需要从不同用户代表和来源获取信息。在需求获取中，信息的主要来源包括以下几种。
(1)涉众。用户、客户、领域专家；市场人员、销售人员等其他用户替代源。
(2)相关产品。原有系统；竞争产品；协作产品(和系统存在接口的其他软件系统)。
(3)重要文档。原有系统的规约说明；竞争产品的规约说明；协作产品的规约说明；客户的需求文档(委托开发的规约说明、招标书)。(4)硬件数据。登记表格、单据、报表等定量文档；备忘录、日志等定性文档。
(5)相关技术标准和法规。相关法律、法规及规章制度；行业规范、行业标准；领域参考模型。在进行需求获取时，以上的信息来源并非全部都会存在，也没有必要对这些全部的来源都进行处理，一般要视项目的具体情况而定。通常需求主要来自于涉众，尤其是用户，而其他的信息来源更多的是提供问题域和环境与约束方面的知识，它们的存在只是更有利于分析人员精确、有效地理解系统的需求。

1．3．4获取需求的方法
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户一开发者的合作才能成功。在需求分析的初期，分析人员对问题知之甚少，用户对问题的描述、对目标软件的要求通常也是相当零乱和模糊的。更为严重的是，分析人员与用户的知识领域不同，从而造成相互理解方面的困难。因此，在需求分析过程中，为了能够获得系统真正的需求，往往需要进行需求捕获，也就是去寻找需要与软件系统开发有关的系统信息。
对需求问题的全面考察需要一些相关的技术和方法，这些技术和方法不但考虑了问题的功能需求方面，还可通过讨论获得项目的非功能需求。

常用的需求获取方法包括以下几种。
1)用户访谈
用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组会议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照一定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列出一个粗糙的想法，根据访谈的具体情况来进行发挥。

2)用户调查
在进行用户访谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项目涉及的客户面较广，不可能一一访谈。因此，就需要借助用户调查的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求信息，这样就可以克服上述的问题。
用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3)现场观摩
俗话说，百闻不如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之有效的方法。，现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随客户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记：建造软件系统不仅仅只是为了模拟客户的手工操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界面等作为软件设计的目标。

4)文档考古文档考古是指对历史存在的一些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于～些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

5)建立联合分析小组在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。用户提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获取。

6)原型法
原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发中存在的各种不确定性。原型主要有三种类型：探索型，实验型，进化型。探索型的目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性，实验型是用于大规模开发和实现前，考核方案是否合适，规约说明是否可靠；进化型的目的不在于改进规约说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。对于原型法的使用也有两种不同的策略：废弃策略和追加策略。废弃策略是指先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统，系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略则与之不同，它是指在原模型的基础之上不断增加和修改，最终产生实用的系统。
在需求模糊的不确定性较大的情况下，使用原型方法来进行需求信息的获取尤其有效。

7)模型驱动
前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通过一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。模型驱动方法是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求获取方法。这些方法的模型定义确定了所要收集的信息类型，模型的建立和完善的过程就是进行需求获取的过程。常见的模型驱动方法有面向目标的方法(Goal一0rientedMethods)、基于场景的方法(Scenario—BasedMethods)和基于用例模型的方法(UseCase—BasedMethods)。这里主要讨论一下基于用例模型的方法。建立用例模型是一种需求获取的有效方法，其简洁清晰的描述方式容易被软件人员和用户共同理解和接受。在用例模型中，角色和用例是两个基本概念，分别代表着系统外部的执行者和系统应包含的功能，因此，建立用例模型的主要工作是确定角色、确定用例和描述用例。用例模型以用户和任务为中心，将整个工作的焦点集中在从用户的角度说明系统能够干什么，完全不考虑具体的实现细节，从而达到准确地理解客户需求的目的。这种方法已经在许多大型系统的开发中取得成效，实践证明它能有效地解决用户参与的问题。

8)基于上下文的方法软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在一定环境下表现出来的行为，通过分析用户的行为得到信息。
总之，进行需求分析时，应注意一切信息与需求都应站在用户的角度上，尽量避免分析员的主观想象，并尽量将分析进度提交给用户，ik,匪lP进行检查与评价，从而达到需求分析的准确性。当然，在需求人员进行需求获取的过程中，往往可能是多种方法的结合，取长补短，从而达到更好地获得系统需求的目的。

1．3．5获取信息的过程
在软件需求的获取中，对于不同规模及不同类型的项目来说，获取信息的过程可能不完全一样。下面给H：获取信息的过程的一些参考步骤。
1)开发离层的业务模型所谓应用领域，就是目标系统的应用环境。如果系统分析员对该领域有了充分的了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入的了解应用领域，之后再对业务模型进行改进。
2)定义项目范围和高层需要
一个项目要成功，离不开项目利益相关方的支持。在项目开始之前，应当在所有利益相关方中建立一个共同的愿景，即定义项目范围和高层需求。项目范围描述系统的边界以及与外部事物(包括组织、人员和软硬件设备等)的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。
3)识别用户需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。能否让系统分析员更准确地了解用户需求，将决定软件需求获取工作能否取得成功。为此，需要根据用户的差异将其分为若干不同的用户类，每类用户都会根据自身的情况提出一组自己的需求。不同的用户类可能有不同的功能和非功能性的需求，甚至可能发生需求冲突。因此，系统分析员必须对不同用户类的需求进行权衡与折中。
4)获取具体的需求确定了项目范围、高层需求和用户后，就需要获取更具体、完整和详细的需求。在进行获取具体需求时，一定要清楚目标系统的5WlH：
What：系统要处理的业务内容是什么；
Where：此系统在整个环境中所处的位置，在其前后有些什么系统与其衔接；
When：系统业务过程的主要活动什么时候发生，持续时间多长；
Who：系统过程的各个活动中会有哪些相关人、事、物；
Why：为什么会出现这样的问题；
How：为完成系统目标应采取什么方法。
在获取具体的需求信息时，可以采用前面介绍过的相关方法。
5)需求整理与总结
在完成上面的步骤之后，需要对获取的需求信息进行整理和总结，确定对目标软件系统的综合要求，并提出这些需求的实现条件，以及需求应达到的标准。

1．3．6获取信息的成果在需求获取过程中会得到一系列不同的信息成果，这些成果按照分类的不同一般包含下列内容。
(1)功能需求。包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为描述。在某些情况下，功能需求还需明确系统不应该做什么。
(2)非功能需求。对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束和标准等。非功能需求常用于整个系统，不用在单个系统或服务中。
(3)领域需求。来自系统的应用领域的需求，反映了该领域的特点，可能是功能需求或非功能需求。
(4)用户需求。是从用户的角度来描述系统的功能和非功能需求，以便于不具有专业技术知识的用户能看懂。这样的需求只描述系统的外部行为，要尽量避免对系统设计特性的描述。
(5)系统需求。是用户需求的扩展版，是软件工程师开始系统设计的起点。系统需求添加了许多细节内容，解释如何让系统提供用户需求。原则上系统需求应该仅仅描述系统的外部行为和对它的操作上的限制，而不应该包括系统应该如何设计和实现。
(6)接口描述。绝大多数的软件系统需求要与其他已经实现的或者在环境中运行着的系统进行交互。如果新系统要和已存在的系统一起工作，已存在的系统接口必须被精确地定义。一般有三种类型的进行必须定义：过程接口、数据结构和数据的表示。
(7)软件需求文档。需求文档是对系统开发者应当实现的内容的正式陈述。它应该包括系统的用户需求和一个详细的系统需求描述。在某些情况下，用户需求和系统需求被集中在一起描述。如果有许多的需求，详细的系统需求可能被分开到不同的文档中单独描述。需求文档中的内容的详细程度，取决于所要开发的系统的类型，以及所使用的开发过程。

1．4结构化分析
传统软件开发方法包括Parnas方法、Jackson方法、Warnier方法和结构化方法等，其中目前应用得比较广泛的是结构化方法，因此，本书中的传统软件开发的内容主要介绍结构化方法。

1．4．1结构化方法概述
系统结构是指系统内部各个组成元素之间的相互联系、相互作用的框架。结构化方法就是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法，是生命周期法与结构化程序设计思想的结合。在结构化开发方法中，提出了一系列提高软件结构合理性的准则，如分解与抽象、信息隐蔽、模块独立性等，其基本思想就是用系统工程的原理和工程化的方法，以用户至上为原则，自始至终按照结构化、模块化，自顶向下地对系统进行分析与设计。

自顶向下逐层分解的策略如图3—3所示，是指当面对一个比较复杂的问题时，分析人员一开始可能无法考虑到问题的所有方面以及全部细节，就采用分解的方法，把一个复杂的问题划分成若干个较容易的小问题，然后再分别解决这些小问题，从而可以将问题的复杂性降到可控的程度。

在进行系统分解工作时应按层次进行：首先，把整个系统看做一个模块，然后把它按功能分解雇屡成若干模块，各模块承担一定的局部功能，共同完成系统的整个功能；其次，每层中的每个模块又可以进一步分解成为更简单一些的下层模块，越下层的模块越简单，功能也越具体。在模块进行分解过程中，具有三种不同的结构形式，即顺序结构、选择结构和循环结构。
针对软件过程各个不同的阶段，结构化方法可以分为结构化分析(StructuredAnalysis，SA)、结构化没计fStructuredDesign，SD)和结构化程序设计(StructuredProgramming，SP)等部分。

1．结构化分析
结构化分析是20世纪70年代末，由Demarco等人提出的，是面向数据流进行需求分析的方法，旨在减少分析活动中的错误，建立满足用户需求的系统逻辑模型。结构化分析的要点是：根据软件内部数据传递、变换的关系，采用自顶向下，逐层分解的方法，经过一系列分解和抽象，建立系统的逻辑模型。结构化体现在将软件系统抽象为一系列的逻辑加工单元，各单元之间以数据流发生关联。结构化分析方法给出了一系列帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用数据流图、数据字典及描述加工逻辑的结构化语言、判定表和判定树等工具来建立一种结构化的目标文档和需求规约说明书。
1)数据流图
描述系统由哪几部分组成，各部分之间有什么联系。
2)数据字典
定义了数据流图中每一个图形元素。
3)结构化语言、判定表、判定树详细描述数据流图中不能被再分解的每一个加工。
结构化分析方法是通过对用户的调查，以软件的需求为线索，获取当前系统的具体模型；去掉具体模型中非本质因素，抽象出当前系统的逻辑模型；并将分析的结果用图形表示，方法简单，易于掌握和使用，是一种行之有效的方法。

但它也具有一定的局限性，主要表现在：
(1)结构化分析方法要求对系统有完整确切的需求定义，这是非常困难的。
(2)结构化分析方法需要书写大量的文档，随着分析的深入，这些文档需要及时进行更新，即使在工具的辅助下，仍有一定的难度。
(3)结构化分析方法描述的模型仅仅是书面的，因此该方法的人机界面表达能力差，很难使从中及时地获得用户的反馈信息。
2．结构化设计
结构化设计方法是在传统软件工程中使用得最广的一种设计方法，是基于模块化、自顶向下细化、结构化分析等技术基础发展起来的，它为软件设计人员给出了一系列在模块层上进行设计的原理与技术。结构化设计方法的基本思想是将系统设计成由相对独立、功能单一的模块组成的结构。
结构化设计方法通常与结构化分析方法衔接起来共同使用，以数据流图为基础得到软件的模块结构。在设计过程中，它从整个程序的结构出发，利用模块结构图表述程序模块之间的关系。
3．结构化程序设计结构化程序设计的概念最早由E．W．Dijikstra在1965年提出的。它的主要观点是采用自顶向下、逐步求精的程序设计方法来对程序进行构造。结构化程序设计中包含三种基本的结构：顺序结构、选择结构和循环结构，即任何程序都可由这三种基本控制结构进行构造。结构化程序设计曾被称为软件发展中的第三个里程碑。

1．4．2系统流程图系统流程图(SystemFlowChart)又叫业务流程图(TransactionFlowDiagram)，是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表，利用它可以帮助分析人员找出业务流程中的不合理流向。业务流程图主要是描述业务走向，以业务处理过程为中心，而不是表示对信息进行加工处理的控制过程。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等)，表达信息在各个部件之间流动的情况。业务流程图的基本图形符号有6个，这6个符号所代表的内容与信息系统最基本的处理功能一一对应。如图3-4所示，其中圆圈表示业务处理单位；方框表示业务处理内容；报表符号表示输出信息(文件、报表、报告、图形等)；不封口的方框表示存储文件；卡片符号表示收集资料；箭头连线表示业务过程联系。业务流程图是一种系统分析人员都懂的共同语言，用来描述系统组织结构、业务流程。业务流程图的绘制是按照业务的实际处理步骤和过程进行的。系统流程图的作用表现在以下几个方面：
(1)制作流程图的过程是全面了解系统业务处理的过程，是系统分析员做进一步分析的依据。
(2)系统流程图是系统分析员、管理人员和业务操作员进行相互交流思想的工具。
(3)系统分析员可直接在系统流程图上画出可以实现计算机处理的部分。
(4)可利用系统流程图来分析业务流程的合理性。
业务流程图是一种用尽可能少、尽可能简单的方法来描述业务处理过程的方法。它的符号简单明了，非常易于阅读和理解业务流程。但它的不足是对于一些专业性较强的业务处理细节缺乏足够的表现手段，比较适用于反映事务处理类型的业务过程。

1．4．3数据流分析在结构化分析中。信息流是系统的一个需要考虑的关键因素．通常用数据流图(DataFlowDiagram，DFD)来进行描绘。数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。也就是说，数据流图的作用就是从数据传递和加工的角度，在需求分析阶段以图形的方式描述数据流从输入到输出的移动变换过程，为系统建立逻辑模型。

1．数据流图的表示数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。DFD有四种元素，其基本符号如图3—5所示。
1)外部实体与系统进行交互，但系统不对其进行加工和处理的实体，用带标记的矩形表示。
2)数据的加工加工是对数据进行变换和处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。在数据流图中加工／处理用带标记的圆圈表示，在圆圈内写上加工名。一个处理框可以代表一系列程序、单个程序或者程序的一个模块。
3)数据流
在数据加工之间或数据存储和数据加工之间进行流动的数据，用带标记的箭头表示。数据流由一组固定的数据组成，用来指出数据在系统内传播的路径。如订票单由旅客姓名、身份证号、年龄、日期、单位和目的地等数据项组成。由于数据流是流动中的数据，在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名(与数据存储之间的数据流不用命名)。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。数据流图中的箭头表示的是数据流，而程序流程图中的箭头表示的是控制流。
4)数据存储表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等，用带标记的双实线表示。
在数据流图中，如果有两个以上数据流指向一个加工，或是从一个加工中引出两个以上的数据流，这些数据流之间往往存在一定的关系。为表达这些关系，可以对数据流的加工标上不同的记号。一般来说，数据流与加工之间可用星号“*”表示相邻的一对数据流同时出现，用“+’’表示相邻的两数据流可取其一或者两者，用“o”表示相邻的两数据流只能取其一，具体情况如图3-6所示。为了能够有效表达数据处理过程的数据加工情况，需要采用层次结构的数据流图，即按照系统的层次结构进行逐步分解，并以分层的数据流图来反映这种结构关系，这样就能比较清楚地表达和理解整个系统。层次结构的数据流图分为顶层数据流图、中层数据流图和底层数据流图。
(1)顶层流图仅包含一个加工，它代表被开发系统。顶层加工的输入流和输出流就是整个系统的输入数据和输出数据，表明系统的范围，以及与外部环境的数据交换关系。
(2)中间层数据流图是对其上层父图中加工的细化，它的每一加工都可能继续细化，形成子图；中间层次的多少，一般视系统的复杂程度而定。
(3)底层流图是指所有的加工都不需再做分解的数据流图，其加工称为“原子加工”，它处在数据流图的最底层。
数据流图的画法包括如下步骤。
(1)确定系统的输入输出。由于系统究竟包括哪些功能可能一时难以弄清楚，可使范围尽量大一些，把可能有的内容全部都包括进去。此时，应该考虑系统有哪些输入数据、输出数据流等相关信息。
(2)画系统的顶层数据流图。在确定输入输出之后，就可以画出系统的顶层数据流图。顶层流图只包含一个加工，用以表示被开发的系统。顶层图的作用在于表明被开发系统的范围以及它和周围环境的数据交换关系。
(3)自顶向下逐层分解，绘出分层数据流图。对于大型的系统，为了控制复杂性，便于理解，需要采用自顶向下逐层分解的方法进行，即用分层的方法将一个数据流图分解成几个数据流图来分别表示。不再分解的加工称为基本加工。除顶层数据流图外，其他数据流图从零开始编号，画0层数据流图时，分解顶层流图的系统为若干子系统，决定每个子系统间的数据和加工之间的关系。在数据流的值发生变化的地方就是一个加工。在画数据流图时，需要给各个加工、加工之间的数据和文件命名。

2．数据流图的注意事项在画分层数据流图应考虑如下几个问题。
(1)编号。为便于管理和阅读，要对每个层次上的图及其加工进行编号。层次编号自上而下分别为顶层图(系统图)、0层图、l层图等。各层图的关系为父子关系，下层图为子图，上层图为父图。子图的编号就是其父图中相应加工的编号；子图中加工的编号由子图号、小数点和局部号组成。在这种编号中，图号中的小数点的个数就是该图所在的层次号，最后一个小数点前的号码就是其父图的编号。
(2)父图和子图的数据平衡。子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，此即父图与子图的平衡。
(3)分解的程度。对一个加工进行细化分解，一次分解成两个或三个加工，可能需要的层次过多；但分解得过多又难于让人理解。根据心理学的研究成果，人们能有效地同时处理问题的个数不超过7个。因此，一个加工每次分解细化出的子加工个数一般不要超过7个。当所分解出的子处理已十分简单时，就可停止这种分解过程。
(4)图表格式。对于一个较大的系统来说，其数据流图可能多达十几张、几十张，一般都将它们装订成册。
(5)局部数据存储。当某层数据流图中的数据存储不是父图中相应加工的外部接口，而只是本图中某些加工之间的数据接口，则称这些数据存储为局部数据存储。
(6)提高数据流图的易懂性。注意合理分解，要把一个加工分解成几个功能相对独立的子加工，这样可以减少加工之间输入、输出数据流的数目，增加数据流图的可理解性。

1．4．4数据字典
数据流图只表示出系统由哪几部分组成和各部分之间的关系，而没有说明各个成分(如数据流，加工等)的含义。因此，只有数据流图还不足以描述用户的需求，必须通过数据字典(DataDictionm‘Y，DD)来对各类数据实体对象进行详细的描述。数据字典以一种准确的、无二义的说明方式，为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述，以供人们查询对不了解的条目的解释。
在结构化分析中，数据词典和数据流图密切配合，能清楚地表达数据处理的要求。数据词典对数据流图中出现的所有成分给出定义，使数据流图上的数据流名、加工名和数据存储名都具有确切的解释。每条解释就是一条词条，按一定的顺序将所有词条排列起来，就构成了数据词典，就好像日常使用的新华词典、英汉词典一样。在数据字典中一般需要建立的一组严密、一致的定义以有助于改进分析员和用户的通信。

1．数据字典的条目
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个条目类型。
1)数据项
数据项条目是不可再分的数据单位，在数据字典中数据项的描述通常包括以下内容：
数据项描述一{数据项名，别名，含义说明，数据类型，取值范围，数据长度，取值含义，
与其他数据项的逻辑关系，数据项之间的关系)其中，取值范围、与其他数据项的逻辑关系、数据项之间的关系定义了数据的完整性约束条件，是设计数据检验功能的依据。2)数据结构数据结构反映了数据之间的组合关系。一个数据结构可以由多个数据项组成，也可以由多个数据结构组成，或由多个数据项和数据结构的混合组成。对数据结构的描述通常包括如下内容：
数据结构描述一{数据结构名，含义说明，组成：{数据项或数据结构}}
3)数据流数据流条目是对数据结构在系统内部进行传输的路径进行定义，一般采用自上而下、逐层分解的方式进行。数据流的描述通常包括如下的内容：
数据流描述一{数据流名，含义说明，数据流来源，数据流去向，平均流量，高峰期流量，组成：{数据结构}}其中，平均流量是指在单位时间内的传输次数，而高峰期流量就是指高峰时段的数据流量。
4)数据存储
数据存储条目就是原来保存数据结构的地方，也是数据流的来源和去向之一。有两种类型的数据存储：文件形式和数据库形式。对于文件形式，其定义包括文件的组成数据项和文件的组织方式两项内容。数据存储的描述通常包括如下内容：
数据存储描述一{数据存储名，数据存储编号，含义说明，流入的数据流，流出的数据流，存取方式．数据量，组成：{数据结构}}其中，流入的数据流要指出其来源，流出的数据流要指出其去向。存取方式包括：是批处理，还是联机处理；是检索还是更新；是顺序检索还是随机检索等。数据量是指每次存取多少数据、每小时(每天或每周等)存取几次等信息。
5)处理过程处理过程条目是用来说明DFD中基本处理过程的逻辑的，由于上层的处理过程是由下层的基本处理过程分解而来．因此，数据词典中只需列出基本处理的说明即可。只要有了基本处理过程的说明，就可理解其他处理过程。处理过程的具体处理逻辑一般用判定表或判定书来描述，数据字典中只需描述处理过程的说明性信息。它集中描述一个加工做什么，也可包括一些与加工有关的信息，其描述通常包括如下的内容：
处理过程描述一{处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}其中，简要说明主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么(而不是怎么做)，处理要求包括处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。

2．数据字典的组合
在数据字典中，数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解。直到不需要进一步解释且参与人员都清楚其含义为止。
数据组合有三种方式：
(1)顺序：以确定的次序连接多个数据项。
(2)选择：从多个数据项中选取一个。
(3)重复：将某个数据项重复多次。
对于上述组合，数据字典使用一套特定的符号表示．如表3—1所示。
此外，数据字典还有另一种含义。就是在进行数据库没计时用来描述数据库中基本表的设计的一种工具，主要包括字段名、数据类型、主键、外键等描述表的属性的内容。

1．5案例分析
下面以某政府计划管理部门的办公自动化系统(OfficeAutomation，OA)为例，对结构化分析与设计方法进行案例研究。

1．系统开发的意义
国民经济计划是我国宏观经济控制的重要手段，离开了国民经济和社会发展计划，国民经济管理就不可能顺利进行。随着我国经济tONel革的深入进行，对政府计划工作的科学性提出了更高的要求。由于宏观经济控制手段从过去开环、半开环控制变成闭环控制，因而对信息的收集、加工、存储、流通各环节的要求水准更高，特别是伴随信息量的剧增及对信息反馈及时性的迫切需要，都对传统的手工方法提出挑战。某政府计划管理部门是省政府的一个重要综合性经济决策和管理机关，是政府的重要经济参谋机构，因此，采用现代科技手段，提高部门的办公效率和决策水平，对推动计划工作具有重要的意义。

2．对现有系统的分析
软件的开发首先要确切定义所要解决的问题。现有系统是待开发系统的取代对象，对现有系统的分析是为了阐明开发新系统的必要性，同时也是导出新系统方案的出发点。

该部门办公自动化系统包括：办公室，综合处，投资处，财金处，外经处，工业处，农经处，物资处，市场处，人事处，能交处，社会处，国土整治办公室(国土办)，发展资金办公室(发展办)，交通战备办公室(交战办)等15个处室，部门组织机构如图3—7所示。部f-1OA系统将把计划工作的科学化、提高计划工作的效率与质量作为OA工程的宗旨。部门的主要任务是：根据党和国家的方针政策，结合实际，编制全省国民经济和社会发展的长期、中期、年度计划，负责国民经济和社会发展的综合平衡，对计划执行情况进行监督检查；并负责组织和协调全省基本建设和重大技术发行的工作。

1)部门的主要职责
(1)编制全省经济和社会发展的长期、中期和年度计划草案。
(2)指导省人民政府各部门和各地州市县的计划工作，从综合平衡的要求出发，审核和调整他们拟订的计划草案。
(3)检查各部门、各地区计划的执行情况，年度计划在执行中需要作重大调整时，会同其他主要部门研究和提出调整意见。
(4)研究经济、科技、社会发展中的方针、政策和重大问题。
(5)负责组织限额以上的基建和400万元以上的技改项目的论证、可行性研究报告和设计任务书的审批。
(6)负责拟订贯彻全国有关基本建设的方针、政策和规章制度的实施细则。
2)机构原手工系统的局限性提出建立OA系统的主要原因在于手工系统存在以下几个严重局限性。
(1)随着我国经济体制改革的深入进行，对部门计划工作的科学化提出了更高的要求。
(2)传统的方式信息检索困难，每查找一条资料都要翻箱倒柜，还不一定能查到信息。
(3)传统的方式对数据的深度加工不够，进一步的加工有困难，数据处理重复严重，数据的一致性无法保证。
(4)决策时以定性方法为主，没有足够的数据作依据，决策缺乏科学性。
(5)计划的制定与执行是一个制定、反馈、调整、再反馈、再调整的不断重复过程，以保证国民经济沿着健康的轨道运行。传统的手工数据不断的在表格上改写，多次涂改后要围挡，既易出错，工作中重复性又大。
(6)各处室之间、部门与国家上级部门、各地州市部门之间的信息共享往往采用纸张复制的办法实现，信息冗余度大，一致性较难保证，时效性也存在问题。
(7)文稿的起草与打印是一个重复劳动的过程，不能平延工序就完成。
(8)大量的工作局限于事务性处理，消耗了许多有才华的同志的精力，不能集中考虑关键性的问题。
(9)工作方式的原始必然影响到工作人员观念的更新。
(10)经济建设的客观发展必然要求机关提高服务质量，传统手工系统的工作效率和工作质量远远不能适应经济发展的需要。
(11)为适应新的要求，若不引入计算机OA系统作为支持，只能通过增加人员，加盖办公楼，设置专门的手工计算部门来实现，而这与计划工作的现代化目标相违背。

3．桌部门0A系统的业务流程通过对系统的分析，该部门的业务有如下特点：
(1)功能多，功能分散。
(2)联系面广，涉及的行业和部门多。
(3)数据流向间关系不密切。
(4)数据的大多在部门外部。
(5)非结构化和半结构化信息占主导地位。
(6)除公文、项目和计划管理等全部门性处理外，其余处理基本上相对独立，但又并非绝对没有联系。
(7)面临机构改革，改革的方向是搞好宏观管理，预计微观管理将逐步。

综上所述，可以得出如下结论：在该部门建立OA系统不同于在企业建立信息系统，它没有明显的主干数据流。准确地说，此OA系统是一个由若干业务系统构成的系统集合。因此，整个系统可以采用集成化的思想进行构造，各子系统面向功能进行戈Ⅱ分。根据系统组织机构，按功能画出的数据流图如图．3—8所示。图中描述了所建议系统的高层逻辑模型，由于部门业务功能多且分散，数据流不集中等特点，图3—8给出的是顶层数据流程图，各个处理的内容是根据现行系统的现状和用户要求而抽象提炼得到的，它基本上满足了用户的要求。

4．系统的安全与保密安全保密是部门OA工程的关键问题之一。部门OA系统的总目标是将先进的技术手段服务于部门的计划、管理、决策工作及其日常的办公事务处理，因此，它将直接涉及财政、金融、市场、能源、工业、农业、交通、邮电、物资、科技等重要信息。这些关系到国计民生的机密信息的安全是至关重要的，也就是说安全保密工作的核心是信息安全。

一般来说，信息的安全是指信息不受到破坏。破坏有两种，即有意破坏和无意破坏。有意破坏是指人为的、有目的的修改、领先、删除、复制、干扰、变形有用的信息，使其无法辨认或使用；无意破坏是指人为或自然力无意识或不可抗拒的因素造成信息的丢失、变形等，使信息失真、无效。信息的保密是指信息不被泄露丢失。泄露也有两种：一种是由于使用者未采用强有力的技术措施防止信息所寄存的信号的外流；另一种是敌对分子采用技术的或破坏性的手段获取信息。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com