《软件详细设计教程》课件第4章

第4章软件需求工程4.1软件需求概述4.2需求工程过程4.3需求获取技术4.4可行性研究4.5需求建模4.6小结 4.1软件需求概述

人们对“软件需求”这个术语缺乏统一的描述，客户所说的“需求”在开发人员看来是一个较高层次的产品概念，而开发人员所说的“需求”在用户看来又像是详细设计。应该说，人们从不同的角度和不同的程度反映着各自的要求，形成了不同层次的需求。

《IEEEStandardGlossaryofSoftwareEngineeringTerminology》给出了有关软件需求的如下定义：

①用户解决问题或达到目标所需的条件或能力。

②系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。③一种反映上面①或②所描述的条件或能力的文档说明。

在IEEE的定义中，需求的概念涵盖了用户角度(系统的外部行为)和开发人员角度(系统的内部特性)两个方面，其中的关键在于需求一定要文档化。

通常，软件需求可以划分为业务需求、用户需求、功能需求和非功能需求、系统需求等类型，它们之间的相互关系如图4.1所示。图4.1不同层次的软件需求及其关系4.1.1业务需求

业务需求是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。通常，业务需求应该涵盖以下内容：

●业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？

●客户：产品为谁服务？目标客户是谁?

●特性：产品区别于其他竞争产品的特性是什么?

●价值：产品的价值体现在什么方面?

●优先级：产品功能特性的优先级次序是什么?下面是一些关于图书资料管理系统的业务需求实例：

●该系统使用计算机实现图书资料的日常管理，提高工作效率和服务质量；

●该系统可以让用户在网络上查询和浏览一些电子资料，改变原有的借阅模式；

●由于版权的限制，某些电子资料只能让用户浏览和打印而不能下载。

业务需求代表了项目参与者在产品所满足的业务需要和产品所提供的利益上的统一共识，清楚地界定了产品应该包括什么和不应该包括什么，为后续详细功能需求的确定和需求变更的决策等提供了参考。

项目的远景和范围应该以文档形式描述出来。这种文档一般比较简短，可能只有1～5页，它主要包括业务机会、项目目标、产品适用范围、客户特点、项目优先级和项目成功因素等。下面给出该文档的一种模板。4.1.2用户需求

用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求的描述应该易于用户的理解，一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。

下面给出一个用户对于图书资料管理系统提出的需求描述的实例，请指出它有什么问题。

用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快捷地查找和浏览所需要的电子资料。

首先，上面一句话的需求描述显然包含了3个不同的需求：

(1)用户可以通过Internet随时查询图书信息；

(2)用户可以通过Internet随时查询个人借阅情况；

(3)用户可以通过Internet快捷地查找和浏览所需要的电子资料。

其次，上面描述中的“随时”和“快捷”是对系统功能的约束，但十分模糊，不同的人会对它们产生不同的理解。

上面的实例说明，使用自然语言进行需求描述容易产生含糊不清和不准确的问题，而且多个不同的需求往往混合成一个需求提出。因此，清晰的文档结构和适当的语言表达对于用户需求的描述是十分重要的。4.1.3功能需求和非功能需求

功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。

下面是一些关于图书资料管理系统的功能需求实例：

●用户可以从图书资料库中查询或者选择其中的一个子集；

●系统可以提供适当的浏览器供用户阅读馆藏文献；

●用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的账户上。注意一下以上的需求描述，“适当的浏览器”存在着含糊不清的问题。在用户看来，这个需求意味着浏览器可以支持所有格式的文档。但是，开发人员可能迫于开发进度的压力，只实现支持一种文本格式的浏览器。

非功能需求是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性等。在图4.2中，非功能需求包括过程需求、产品需求和外部需求等类型，其中过程需求包含软件交付、实现方法和标准等方面的需求；产品需求包含软件性能、可用性、存储空间、可靠性、可移植性、安全性、容错性等方面的需求；外部需求有道德、法规、成本、互操作性等需求。图4.2非功能需求的类型非功能需求的常见问题检验起来非常困难，一般采用一些可度量的特性进行描述。表4.1给出了一些常用的非功能特性的度量。表4.1常用的非功能特性的度量下面是一些关于图书资料管理系统的非功能需求实例：

●系统在20 s之内响应所有的请求；

●系统应该每周7天、每天24小时都可使用；

●对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。

4.1.4系统需求

系统需求更加详细地描述了系统应该做什么，通常包括对象模型、数据模型、状态模型等许多分析模型。系统需求主要是面向开发人员进行描述的，是开发人员进行软件设计的基础。前面提到，使用自然语言进行需求描述容易产生含糊不清和不准确等问题，因此需要采用适当的方法形成一致的、完备的和无二义性的系统需求描述。通常，系统需求模型的描述有以下3种方法：

(1)结构化语言(PDL)：是介于自然语言和形式语言之间的半形式语言，它试图把自然语言的非形式化性与程序设计语言的严格语法和控制结构结合起来。

(2)可视化模型：使用图形化符号辅之以文本注释定义系统模型，如数据流图、UML语言、实体关系图等。

(3)形式化方法：基于状态机或集合等数学概念描述系统模型，如Z语言、PetriNet等。

4.2需求工程过程

需求工程应用已证实有效的原理和方法，通过合适的工具和符号，系统地描述了待开发系统及其行为特征和相关约束。在需求工程过程中，开发人员需要收集和分析来自用户或市场等各方面的需求，编写规格说明文档，并采用评审和商议等有效手段对其进行验证，最终形成一个需求基线。由于软件开发过程中经常发生需求变更的情况，因此，必须有效地管理和控制这些变更。

图4.3显示了需求工程的所有过程，包括需求获取、需求分析、需求规格说明、需求验证和需求管理等，并说明了这些过程之间的关系和需要产生的文档。图4.3需求工程过程4.2.1需求获取

需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解，一旦理解了需求，开发人员和客户就能探索出描述这些需求的多种解决方案。

需求获取应该集中在用户任务上，而不是集中在用户接口上，其主要工作内容包括：

(1)聆听用户的需求。开发人员应该与各种层次的客户进行充分地交流和沟通，包括决策管理层、使用部门经理、具体使用人员、系统维护人员等，尽量清楚地理解用户的问题和要求。

(2)分析和整理所获取的信息。对于用户提供的各种问题和要求，开发人员需要对其进行归纳和整理，借助一些工具和方法，从用户一般性的陈述中提取用户的真正需求，并由此确定软件的功能、性能、接口关系、约束条件等。

(3)形成文档化的描述。不论是用户提出的问题，还是最终获取的需求，都应该形成文档化的描述，这种描述需要各种人员的一致理解和认同。4.2.2需求分析

需求分析主要是对收集到的需求进行提炼、分析和认真审查，以确保所有的项目相关人员都明白其含义，并找出其中的错误、遗漏或其他不足的地方，形成完整的分析模型。需求分析的目的在于开发出高质量的、详细的需求，从而支持项目估算、软件设计、软件开发和软件测试。

需求分析的主要工作内容包括：

(1)定义系统的边界。建立系统与其外部实体间的界限和接口的简单模型，明确接口处的信息流。

(2)建立软件原型。当开发人员或用户遇到需求不确定的问题时，开发软件原型是一种最好的解决方法，它将许多概念和可能发生的事情直观地显示出来。用户通过评价原型，使得项目参与人员能够进一步理解问题，同时找出需求文档与软件原型之间的矛盾。

(3)分析需求可行性。在项目成本和性能要求允许的情况下，分析每一个需求实现的可行性，确定与需求实现相联系的开发风险，诸如与其他需求的冲突、对外界因素的依赖和技术障碍等。

(4)确定需求优先级。开发人员通过分析来确定产品特性或每一个需求实现的优先级，并以此为基础确定产品版本将包括哪些特性或需求。由于软件项目受到时间和资源的限制，一般情况下无法实现软件功能的每一个细节，因此需求优先级有助于开发组织和版本规划，以保证在规定的时间和预算内达到最好的效果。

(5)建立需求分析模型。建立需求分析模型是需求分析的核心工作，它通过建立需求的多种视图，例如数据流图、实体关系图、状态变换图、类图、交互图等，揭示出需求的不正确、不一致、遗漏和冗余等更深的问题。

(6)创建数据字典。数据字典定义了系统中使用的所有数据项及其结构，至少应该定义客户的数据项，以确保客户和开发人员使用一致的定义和术语。

多年来，人们提出了许多分析建模的方法，其中占主导地位的是传统的结构化分析方法和当今流行的面向对象分析方法。4.2.3需求规格说朋

软件需求规格说明(SoftwareRequirementSpecification，SRS)是需求开发的结果，它精确地阐述了一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件。

软件需求规格说明具有广泛的使用范围，并成为用户、分析人员和设计人员之间进行理解和交流的手段。用户通过需求规格说明文档指定需求，检查需求描述是否满足原来的期望；设计人员通过需求规格说明文档了解软件需要开发的内容，将其作为软件设计的基本出发点；测试人员根据软件需求规格说明中对产品行为的描述，制定测试计划、测试用例和测试过程；产品发布人员根据软件需求规格说明和用户界面设计编写用户手册和帮助信息等。软件需求规格说明在整个开发过程中具有重要的作用，项目管理人员可以利用它规划软件开发过程，更加准确地估计开发进度和成本，控制需求的变更过程，并将其作为最后验收目标系统的可测试标准。

在软件项目中，开发组织应该采用一种标准的软件需求规格说明模板。现在有许多推荐的软件需求规格说明模板可以使用，这里介绍一种由IEEE标准830-1998改写并扩充的模板。4.2.4需求验证

需求验证用于确保需求说明准确、完整地表达必要的质量特点。有时人们认为软件需求规格说明文档中的需求描述是正确的，但在现实中却会出现问题；在使用需求规格说明编写测试用例时，又有可能发现二义性和不可验证的问题。需求验证通过评审的方式，发现需求规格说明中存在的错误或缺陷，开发人员应及时进行更改和补充，并对修改后的需求规格说明文档进行再评审。

需求验证针对那些已编写成文档的需求进行验证，而对于那些存在于用户或开发人员思维中的没有表露的、含蓄的需求则不予验证。一般来说，需求评审由不同代表(如分析人员、客户、设计人员、测试人员)组成的评审小组以会议形式进行。在评审会议上，分析人员说明软件产品的总体目标、主要功能和性能指标等，评审小组对照需求规格说明文档及其相关模型进行检查和评价，并讨论软件验收的可测试指标。

需求验证主要围绕需求规格说明的质量特性展开，这些质量特性包括正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性等。

1．正确性

正确性是指需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。

审查需求的正确性应该考虑以下几方面的问题：

(1)用户参与需求过程的程度如何?

(2)每一个需求描述是否准确地反映了用户的需要?

(3)系统用户是否已经认真考虑了每一项描述?

(4)需求可以追溯到来源吗?

举例：下面的需求描述正确吗?

在用户每次存钱时系统将进行信用检查。

2．无二义性

无二义性是指需求规格说明中的描述对所有人都只能有一种明确统一的解释。由于自然语言极易导致二义性，所以应尽量把每项需求用简洁明了的用户语言表达出来。

审查需求的无二义性应该考虑以下几方面的问题：

(1)需求规格说明是否有术语词汇表?

(2)具有多重含义或未知含义的术语是否已经定义?

(3)需求描述是否可量化和可验证?

(4)每一项需求都有测试准则吗?

举例：下面的需求描述是无二义性的吗?

如果用户试图透支，系统将采取适当的行动。

3．完整性

完整性是指需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于避免不完整性。

审查需求的完整性应该考虑以下几方面的问题：

(1)是否存在遗漏的功能或业务过程?

(2)在每个定义的功能之间是否有接口?

(3)是否有信息或消息在所定义的功能之间传递?

(4)是否定义了功能的使用者?

(5)是否已经清楚地定义了用户与功能之间的交互?

(6)是否定义了与外部过程和系统之间的接口?

(7)所描述的功能是否可以映射到业务过程中?

(8)文档中是否存在待确定的需求引用?

(9)文档中是否存在未定义的术语和引用?

(10)文档的各个部分都完整吗?

(11)需求包括非功能属性的说明吗?

4．可验证性

可验证性是指需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。

审查需求的可验证性应该考虑以下几方面的问题：

(1)在需求文档中是否存在不可验证的描述，诸如“用户界面友好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等?

(2)所有描述都是具体的和可测量的吗?

举例：下面两个需求描述中哪一个难以验证?

①系统将在20 s内响应所有有效的请求。

②如果用户试图透支，系统将采取适当的行动。

5．一致性

一致性是指需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。

审查需求的一致性应该考虑以下几方面的问题：

(1)文档的组织形式是否易于一致?

(2)不同功能的描述之间是否存在矛盾?

(3)是否存在有矛盾的需求描述或术语?

(4)是否存在矛盾的术语定义?

(5)文档中是否存在时序上的不一致?

举例：下面两个需求描述是否有矛盾?

①系统允许立即使用所存资金。

②只有在手工验证所存资金后，系统才能允许使用。

6．可修改性

可修改性是指需求规格说明的格式和组织方式应保证后续的修改比较容易进行和协调一致。可以使用软件工具或者目录表、索引和相互参照列表等方法使软件需求规格说明更容易修改。

审查需求的可修改性应该考虑以下几方面的问题：

(1)是否存在明显的需求交叉引用?

(2)是否有内容列表和索引?

(3)是否存在冗余需求，即同一个需求的描述出现在文档的不同地方？如果存在，它们是交叉引用吗?

7．可跟踪性

可跟踪性是指每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来。一方面，每一项需求都可以在早期的文档中追溯到其来源，例如备忘录、法规、会议记录等；另一方面，每一项需求都有唯一的名称或索引号，与后期的实现结果对应。

举例：下面的需求描述记录了早期的文档来源。

系统将在20 s内响应所有有效的请求。

[来自与用户的面谈，备忘录编号#1234]4.2.5需求管理

软件需求的最大问题在于难以清楚确定以及不断发生的变化，这也是软件开发之所以困难的主要根源，因此有效地管理需求是项目成功的基础。在软件过程能力成熟度模型(CapabilityMaturityModel，CMM)中，需求管理作为CMM二级所应达到的目标能力之一，其目的在于为软件需求建立一个基线供软件工程和管理使用，并使软件计划、产品和活动与其保持一致。

软件需求规格说明通过评审后，就形成了开发工作的需求基线，这个基线在客户和开发人员之间构筑了计划产品功能需求和非功能需求的一个约定。需求管理的任务是分析变更影响并控制变更过程，主要包括变更控制、版本控制、需求跟踪和需求状态跟踪等活动，如图4.4所示。图4.4需求管理的活动

1．需求变更控制

对许多项目来说，一些需求的改进是合理的且不可避免的。瞬息万变的市场机会、竞争性的产品、新的开发技术和项目目标的调整等都可能产生需求的变更，但是如果不控制这种变更将会导致项目陷入混乱、不能按进度执行或软件质量低劣等问题。因此，应该评估每一项变更建议，将它与项目的视图和范围进行比较，最终决定是否应该采纳它。

变更控制是在一定的程序下有效地实施整个变更过程，应该包括以下几部分：

(1)仔细评估已建议的变更；

(2)挑选合适的人选对变更做出决定；

(3)变更应及时通知所有涉及的人员；

(4)项目要按一定的程序实施需求变更。

2．需求文档的版本控制

版本控制是管理需求的一个必要方面，它保证在需求文档中记录和反映所有的需求变化。需求文档的每一个版本都必须统一确定，组内每个成员必须能够得到需求的当前版本，需求变更应该及时通知到项目开发所涉及的人员。每一个公布的需求文档都应该包括一个修正版本的历史情况，即变更内容、变更日期、变更人姓名以及变更原因等。在实际的软件开发管理中，商业需求管理工具是最有力的版本控制方法，这些工具可以跟踪和报告每个需求的变动历史，特别是当需要恢复早期的需求时非常有意义。另外，在添加、变动、删除、拒绝一个需求后，附加一些评语描述变更的原因对后续的讨论非常有用。

3．需求跟踪

需求跟踪帮助人们全面地分析变更带来的影响，以便做出正确的变更决策。需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等，从而建立需求的跟踪联系链。当需求发生变化时，使用需求跟踪可以确保不忽略每个受到影响的系统元素，需求变更的正确实施可以降低由此带给项目的风险。表示需求和别的系统元素之间的联系链的最普遍的方式是使用需求跟踪能力矩阵。例如，表4.2显示了某应用系统的一个需求跟踪能力矩阵，说明了每个功能性需求向后连接一个特定的用例，向前连接一个或多个设计、代码和测试元素。需求联系链需要由开发人员确定，但大量的需求跟踪信息可以使用特定的工具进行管理。表4.2需求跟踪能力矩阵示例

4．需求状态跟踪

不同类型的需求都有不同的需求状态相对应，作为需求优先级划分标准的补充说明。通过需求状态跟踪能够确保需求实现的完整性，其工作包括定义需求状态和跟踪需求状态两部分。然而手工进行需求管理很难保持文档和现实的一致，且无法跟踪需求的每个状态，特别是对大项目而言。因此，选用合适的需求管理工具可以在整个开发期间有效地管理需求的变动，并使用需求作为设计、测试和项目管理的基础。

表4.3列出了一些商业需求管理工具，主要包括以数据库为核心和以文档为核心两类。表4.3商业需求管理工具实例以数据库为核心的产品(如Caliber-RM和DOORS)将所有的需求、属性和跟踪能力信息存储在数据库中。有些工具可以把每个需求与外部文件相联系(如微软的Word文件、Excel文件、图形文件等)，以补充需求说明。

以文档为核心的工具使用Word或Adobe公司的FrameMaker等字处理程序制作和存储文档。以RequisitePro为例，这种工具通过允许选择文档作为离散需求存储在数据库中，来加强以文档为核心的处理方法的能力，同时提供一些机制来同步数据库和文档的内容。

4.3需求获取技术

需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。为了确定用户的真正需求，避免软件人员与用户之间的交流障碍、需求不全、意见冲突等问题，一方面需要提高分析人员的知识技能，使其不仅具备较高的技术水平和丰富的实践经验，还要具备一定的业务基础知识和较强的人际交往能力；另一方面还要开展大量的调查研究工作，包括用户访谈、现场考察、专家咨询、会议讨论等，并对大量的一手资料进行分析和整理，从而清楚地理解用户。

为了更好地理解用户的需求，可以采用多种不同的技术进行需求获取，常见的需求获取技术包括面谈和问卷调查、需求专题讨论会、观察用户工作流程、基于用例的方法、原型化方法等，而选择这些技术需要根据应用类型、开发团队技能、用户性质等因素来决定。

4.3.1面谈

用户面谈是一种十分重要而直接的需求获取方法，实际上是一种任何情况下都可以使用的简单而直接的方法，其基本要点如下：

(1)事先准备一个合适的与背景无关的面谈，列出一些准备询问的问题，并将其记在笔记本上以便面谈时参考。

(2)面谈前，需要研究一下要面谈的风险承担人或公司的背景资料，不要选择自己能回答的问题打扰被面谈人。

(3)面谈过程中，应该参考事先准备的面谈模板，以保证提出的问题是正确的。同时，需要建立起和谐的气氛，并将答案记录下来。

(4)面谈之后，分析总结面谈记录，找到主要的用户需求或产品特征。

与背景无关的面谈是通过询问一些与背景无关的问题，使开发人员全面理解用户的真正问题，以便给出一些有效的解决方法。

下面给出一个用户面谈过程的示例。4.3.2需求专题讨论会

需求专题讨论会也许是需求获取的一种最有力的技术。项目的主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为1～2天，与会者可以在应用需求上达成共识，对操作过程尽快取得统一意见。

专题讨论会具有以下优点：

●它协助建立一支高效的团队，围绕一个目的——项目的成功；

●所有的风险承担人都畅所欲言；

●它促进风险承担人和开发团队之间达成共识；

●它能够揭露和解决那些妨碍项目成功的行政问题；

●能够很快产生初步的系统定义。

(1)专题讨论会的准备。充分的准备是专题讨论会成功的关键。首先，应向参加讨论的人员宣传专题讨论会的好处，使其对专题讨论会充满信心；第二，确定真正的风险承担人并保证使其参与；第三，做好后勤保障是十分必要的；第四，在专题讨论会之前分发资料，便于与会者进行准备，可以提高专题讨论会的效率。

(2)安排日程。专题讨论会的议程应建立在具体项目需求和所讨论的开发内容的基础上，大多数会议可以遵循一种比较标准的形式。表4.4是一个典型的议程。表4.4专题讨论会议程

(3)举行专题讨论会。专题讨论会上可能出现行政人员间的责备或冲突，会议主持人应该能够掌握讨论会气氛并控制会场，避免挑起项目相关人员之间的矛盾(过去的、现在的或将来的)。

专题讨论会最重要的部分就是自由讨论阶段，这种技术非常符合专题讨论会的气氛，并能营造一种创造性的、积极的氛围，同时可以获得所有风险承担人的意见。

在专题讨论会上，主持人应该分配会议时间，记录所有言论。

会议结束后，使项目成功的责任就落到开发团队的身上。4.3.3观察用户工作流程

有时客户可能无法有效地表达或只能片面地表达自己的需求，开发人员很难通过面谈和会议获得完整的信息。这种情况下，观察用户的工作流程是一种比较好的解决方法。

观察用户工作流程有两种形式：

(1)被动观察：开发人员可以在不受干扰或直接干预的情况下观察用户的业务活动。为了避免用户受影响，可以使用摄像机等设备帮助进行观察。

(2)主动观察：开发人员直接参与到用户的业务活动中，有效地成为其中的一部分。观察用户工作流程需要一段较长的时间，而且需要涉及各种不同的业务阶段。需要说明的是，用户在被观察的过程中可能表现出与平常不同的行为，从而隐藏了一些现实的工作情况。

4.3.4原型化方法

一个软件原型是所开发系统的部分实现，它比开发人员常用的技术术语更易于理解。原型化方法是需求获取过程中一种常用的方法，它通过使系统全部或者系统一部分可视化来获得客户的反馈，从而有效地解决在系统开发的早期阶段需求不确定的问题。在构造原型之前，需要充分与客户交流，结合软件的应用领域、应用复杂性、客户特点和项目特点等因素，决定在评价完原型之后是抛弃掉原型还是将其进化为最终产品的一部分，这里分别将它们称为抛弃式原型和演化式原型。

(1)抛弃式原型。抛弃式原型首先选择适当的演示功能，并描述相应的用户界面，然后构造软件原型；用户对所构造的软件原型进行评估，提出反馈意见；在达到预期目的后，抛弃所建立的原型系统。

(2)演化式原型。与抛弃式原型相对应，在已经清楚地定义了需求的情况下，该原型并不被抛弃，而是演化成最终系统的一部分，从而为开发渐增式产品提供了坚实的构造基础。从原型的用途可以看出，建造软件原型不同于最终系统，它需要花最小的代价尽快实现，因此，只要能够体现原型的作用和满足评价的要求，可以忽略一切暂时不关心的部分。正是由于这种忽略，演化型原型进化为最终系统时需要十分小心，否则会对后期的开发造成很大问题。4.3.5基于用例的方法

随着面向对象技术的发展，基于用例的方法在需求获取和建模方面应用得越来越普遍。这种方法是以任务和用户为中心的，可以使用户更清楚地认识到新系统允许他们做什么。另外，用例有助于开发人员理解用户的业务和应用领域，并可以运用面向对象的分析和设计方法将用例转化为对象模型。

在用例模型中，只是关心系统所应实现的功能，而不关心内部的具体实现细节。一般来说，用例模型的建立是由开发者和客户共同协商完成的，通过反复讨论需求的规格说明达成共识，明确系统的基本功能，为后续阶段打下基础。

(1)确定参与者。参与者代表着与系统交互的人或事。通过确认系统功能的使用者和维护者以及与系统接口的其他系统或硬件设备等，可以有效地识别出系统的参与者。

(2)确定用例。用例描述了系统完成的动作序列，产生对参与者有价值的结果。一个完整的系统包含若干个用例，每个用例都具体说明了应完成的功能。识别用例首先要确定系统所能反映的外部事件，并把这些事件与参与的执行者和特定的使用实例联系起来，最终绘制出用例图。

(3)描述用例。单纯地使用用例图不能提供用例所具有的全部信息，因此，需要使用文字描述那些不能反映到图形上的信息。用例描述实际上是关于参与者与系统如何交互的规格说明，要求清晰明确，没有二义性。

4.4可 行 性 研 究

4.4.1意义

可行性研究又叫可行性分析，它是所有工程项目在开始阶段必须进行的一项工作。可行性研究是指在项目正式开发之前，先投入一定的精力，通过一套准则，从经济、技术、社会等方面对项目的必要性、可能性、合理性以及项目所面临的重大风险进行分析和评价，得出项目是否可行的结论。

可行性研究的结果无非有三种情况：

①可行，按计划进行；

②基本可行，对项目要求或方案做必要修改；

③不可行，不立项或终止项目。可行性研究一般需要从经济、技术、社会等方面进行综合分析，把这三个方面的分析工作称为经济可行性、技术可行性和社会可行性。经济可行性分析一般要对项目进行成本和效益估算，要求效益大于成本。同时，需要综合进行比较，对一个项目应该提出几种方案，选择其中投入最小而收益最大的方案。对信息系统项目的效益分析时应该注意它的社会效益。除了经济可行之外，还需要从技术上进行论证。要论证项目所涉及到的关键技术是否已经成熟，是否还存在重大的技术风险。只有排除了重大技术风险的项目才能够立项开发。最后还要从社会角度论证项目的可行性。社会可行性包括的范围比较广泛，例如项目所要求的社会环境是否具备，项目的开发对社会公益是否会带来负面影响，是否存在与社会道德、法律、制度等有相抵触的地方。对于信息系统来讲，还需要考虑企业员工的信息知识素养、企业管理水平、人们的社会生活习惯等方面的因素。经济、技术和社会三方面互有联系，需要综合考虑，不可偏执一面。

信息系统可行性研究工作更为重要和复杂。首先对制定的信息系统总体规划要进行可行性论证；其次，要对在信息系统建设过程中，各次投入开发的信息系统项目进行可行性分析；此外，随着环境、需求和技术的发展变化，还要及时根据变化对信息系统建设带来的影响进行可行性分析。

信息系统规划的可行性研究主要分析所制定的信息系统规划是否符合企业发展的实际。信息系统规划的可行性研究也是从经济、技术和社会等方面进行分析，但需要更多地考虑所制定的信息系统规划是否符合企业战略目标的需要，是否存在近期无法排除的重大风险，规划的安排是否符合企业现状等方面的问题。由于信息系统规划是企业信息系统建设的总纲领，它要指导企业信息系统长远建设，因此，对信息系统规划的可行性研究必须慎之又慎。

信息系统建设是一个漫长的过程，需要分阶段、分步骤完成。对每一个时期计划开发的信息系统项目，也需要进行可行性分析。这是因为，信息系统规划的可行性研究是立足于长远和宏观的信息系统总体建设，每一时期所要开发的信息系统项目则比较具体，需要对本项目的可行性进行深入细致的分析。对于不可行的项目就要提前改换目标、需求或方案，否则，便会终止项目开发，以至于造成无谓的损失。4.4.2可行性研究的内容

1．经济可行性

经济可行性分析(EconomicFeasibility)也叫投资/效益分析或成本效益分析，它用来分析信息系统项目所需要的花费和项目开发成功之后所能带来的经济效益。通俗地讲，分析信息系统的经济可行性，就是分析该信息是否值得开发。显然，在可行性分析中，经济可行性应该是最重要的，企业所追求的目的就是效益和利润，如果收益小于支出，企业显然不会做这种亏本生意。投资/效益分析需要确定出所要开发的信息系统的总成本和总收益，然后对总成本和总收益进行比较，当总收益大于总成本时，这个项目才值得开发。信息系统的总成本包括开发总费用和运行管理总费用，信息系统总效益包括直接经济效益和间接社会效益。

信息系统总成本包括信息系统开发成本和运行成本。信息系统开发成本是指从立项到投入运行所花费的所有费用；而运行成本则是指信息系统投入使用之后，系统运行、管理和维护所花费的费用。例如，新建一个图书馆，需要规划、设计和施工，还需要购买所有的建筑材料。假设整个图书馆的建设成本需要8000万元人民币。图书馆一旦建成投入使用，要保证日常运行，还需要管理、操作和维护费用，像水电费、管理费、维护费和人员费用等。每年图书馆的运行管理费用也可能只是整个开发成本的一个零头，但在图书馆的使用期中，每年都需要操作管理费，所以，累计的操作管理费不一定比建设费用少。

信息系统的效益包括直接经济效益和间接社会效益。直接经济效益是信息系统能够直接获取的，并且能够用资金度量的效益。如降低的成本、提高的资金周转率、减少的人员成本以及减少的消耗等都是信息系统的直接经济效益，它们可以用资金进行计算。间接社会效益是能够整体地提高企业信誉和形象，提高企业的管理水平，但不能简单地或无法用资金计算的那部分效益。间接社会效益常常需要系统分析员根据本企业的状况和不同企业之间的类比进行概括估计。通过比较成本和效益，就可以决定将要立项的信息系统是不是值得开发。一般比较的结论有三个：

①效益大于成本，开发对企业有价值；

②成本大于效益，不值得开发；

③效益和成本基本持平。

在进行成本/效益分析时不要忽视信息系统给企业带来的间接社会效益，对信息系统开发尤其要注意间接社会效益。简单地从经济角度看，有些信息系统可能投入大于直接效益，但是它给企业带来的间接效益很大，这类系统仍然要立项开发。

2．技术可行性

技术可行性(TechnicalFeasibility)分析用来在特定条件下，技术资源的可用性和这些技术资源用于解决信息系统问题的可能性和现实性。在进行技术可行性分析时，一定要注意下述几方面问题：

(1)应该全面考虑信息系统开发过程中所涉及的所有技术问题。信息系统开发过程涉及多方面的技术、开发方法、软硬件平台、网络结构、系统布局和结构、输入输出技术、系统相关技术等，应该全面和客观地分析信息系统开发所涉及的技术以及这些技术的成熟度和现实性。

(2)尽可能采用成熟技术。成熟技术是被多人采用并被反复证明行之有效的技术，因此采用成熟技术一般具有较高的成功率。另外，成熟技术经过长时间、大范围使用、补充和优化，其精细程度、优化程度、可操作性、经济性要比新技术好。鉴于以上原因，在开发信息系统过程中，在可以满足系统开发需要、能够适应系统发展、保证开发成本的条件下，应该尽量采用成熟技术。

(3)慎重引入先进技术。在信息系统开发过程中，有时为了解决系统的一些特定问题，为了使所开发的信息系统具有更好的适应性，也需要采用某些先进或前沿技术。在选用先进技术时，需要全面分析所选技术的成熟程度。有许多报道的先进技术和科研成果实际上仍处在实验室阶段，其实用性和适应性并没有得到完全解决，也没有经过大量实践验证，在选择这种技术时必须慎重。例如，在许多文章上已经报道了指纹识别技术，而且市场上也有实验性产品，但指纹识别技术至今仍有许多重大技术难题没有突破，离实用仍有一定距离。因此，在项目开发中就要谨慎选用这种技术。如果不加分析，在项目中盲目采用了指纹识别技术，在应用中肯定会出现许多难以解决的具体问题。

(4)着眼于具体的开发环境和开发人员。许多技术总的来看可能是成熟和可行的，但是在你的开发队伍中如果没有人掌握这种技术，而且在项目组中又没有引进掌握这种技术的人员，那么这种技术对本系统的开发仍然是不可行的。例如，分布对象技术是分布式系统的一种通用技术，但是如果在你的开发队伍中没有人掌握这种技术，那么从技术可行性上看就是不可行的。

3．社会可行性

社会可行性(SocietyFeasibility)具有比较广泛的内容，它需要从政策、法律、道德、制度、管理、人员等社会因素论证信息系统开发的可能性和现实性。例如，对信息系统所服务的行业以及应用领域，国家和地方已经颁布的法律和行政法规是否与所开发的系统相抵触?企业的管理制度与信息系统开发是否存在矛盾的地方?人员的素质和人员的心理是否为信息系统开发和运行提供了准备?诸如此类问题都属于社会可行性需要研究的问题。社会可行性还需要考虑操作可行性(OperationalFeasibility)。操作可行性是指分析和测定给定信息系统在确定环境中能够有效地从事工作并被用户方便使用的程度和能力。

操作可行性需要考虑以下方面：

①问题域的手工业务流程、新系统的流程、两种流程的相近程度和差距；

②系统业务的专业化程度；

③系统对用户的使用要求；

④系统界面的友好程度以及操作的方便程度；

⑤用户的实际能力。分析操作可行性必须立足于实际操作和使用信息系统的用户环境。例如，A公司的全体收款员都能够熟练地运用收款电脑进行收款业务，并不意味着B公司的收款员也就必然能做同样的事情。可行性研究的内容之一就是要判断B公司收款员当前所具有的能力，以便于下一步为他们的改变做出适中的决定。

4.4.3可行性研究报告

可行性研究完成之后要编写可行性研究报告。可行性研究报告包括信息系统概要介绍、可行性研究过程和可行性研究结论等内容。下面给出了可行性研究报告的简要提纲。 4.5需求建模

4.5.1需求建模方法

需求分析是解决软件做什么的问题，即定义要解决的问题，而不涉及怎么做的问题。需求分析建立的系统模型是用软件工程的“语言”来描述要开发项目的数据、功能和控制需求的。在结构化分析设计中它们是下一步设计的基础。需求分析要产生软件运行特征的规约，指明软件和其他系统元素的接口并建立软件必须满足的约束，还要为软件提供一份系统建成后评估其质量的依据。书写文档是系统分析规约的方式，只有变成规约文档才能消除歧义。但是计算机需求的最好表示方式是文档和图表相结合，这样不但容易理解，而且更重要的是可以直接通过评审正确性、完整性和一致性的方式来描述数据、功能和行为的需求。

形式化的语言，甚至一些计算机术语都使用户难以理解，因此，用文字表达很难清楚展现系统的体系结构，表示系统的需求。而采用图表的形式，可以使用户比较容易看懂，很容易和用户交流，有利于需求分析的评审。用图表来表示系统需求，其本身就是一个建模过程。在技术层次上，软件工程是从一系列建模任务开始的，这些任务的完成才定义了将被建立的软件的完整需求。换句话说，所谓建模，实际上就是使用图表的形式来表示系统的各个方面以及各个视图。

常用的系统分析建模方法有两种：一种是结构化分析方法，一种是面向对象的分析方法。结构化的系统分析方法是传统的建模方法。所谓结构化分析，就是有规则地进行分析，有规则地表达出来。结构化分析从数据流进行分析，用数据流程图把要开发的软件功能结构表示出来，这种图形就是软件的功能模型，所以它是一种建模活动。结构化分析的“结构化”表现在把要解决的问题抽象出来，抓住本质的东西，忽略细节，逐层分解到可理解的程度，越高层的抽象级别越高，这就是常说的自顶向下的分解。而表达的工具就是数据流程图、实体关系图和数据字典。结构化分析的核心就是自顶向下的分解和自底向上的抽象。

术语结构化分析最初由DouglassRoss提出，DeMarco对其进行了推广，引入了使得分析员可以创建信息流模型的关键图形符号，提出了使用这些符号建立模型的方法。以后结构化系统分析方法又被扩展，引入了适用于实时系统的行为模型、状态图等。4.5.2实体—关系图

数据模型包含三种相互关联的信息：数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。

1．数据对象

数据对象是对软件必须理解的复合信息的表示。所谓复合信息，是指具有一系列不同性质或属性的事物，因此仅有单个值的事物(例如宽度)不是数据对象。

数据对象可以是外部实体(例如产生或使用信息的任何事物)、事物(例如报表或屏幕显示)、行为(例如打电话)或事件(例如响警报)、角色(例如销售员)、单位(例如会计科)以及地点(例如仓库)或结构(例如文件)等。例如，教师、学生、课程和汽车等都可以认为是数据对象，因为它们都可以由一组属性来定义。“数据对象描述”中包含了数据对象及其所有属性。

数据对象彼此间是有关联的，例如，教师“教”课程，学生“学”课程，教或学的关系表示教师和课程或学生和课程之间的一种特定的连接。

数据对象只封装了数据而没有对作用于数据上的操作进行引用，这是数据对象与面向对象范型中的“类”或“对象”的显著区别。

2．属性

属性定义了数据对象的性质。属性可以具有下述三种不同的特性之一，也就是说，可以用属性来：①为数据对象的实例命名；②描述该实例；③引用另一个数据对象的实例。此外，必须把一个或多个属性定义为“标识符”，即当我们希望找到数据对象的一个实例时，标识符属性成为“关键字”。

应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。例如，为了开发机动车管理系统，描述汽车的属性应该是制造商、品牌、型号、发动机号码、车体类型、颜色、车主姓名、住址、驾驶证号码、生产日期以及购买日期等。但是，为了开发设计汽车的CAD系统，用上述这些属性描述汽车就不合适了，其中车主姓名、住址、驾驶证号码、生产日期和购买日期等属性都应该删去，而描述汽车技术指标的大量属性应该增添进来。

3．关系

数据对象彼此之间相互连接的方式称为关系，也称为联系。

客观世界中的事物彼此间往往是有联系的。例如，教师与课程间存在“教”这种联系，而学生与课程间则存在“学”这种联系。联系可分为以下三类。

(1)一对一联系(1∶1)。如果对于实体集A中的每一个实体，实体集B中至多有一个(也可以没有)实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。

例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的，如图4.5所示。图4.51∶1关系

(2)一对多联系(1∶N)。如果对于实体集A中的每一个实体，实体集B中有N个实体(N≥0)与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1∶N。

例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教，如图4.6所示。图4.61∶N关系

(3)多对多联系(M∶N)。如果对于实体集A中的每一个实体，实体集B中有N个实体(N≥0)与之联系，反之，对于实体集B中的每一个实体，实体集A中也有M个实体(M≥0)与之联系，则称实体集A与实体集B具有多对多联系，记为M∶N。

例如，图4.7表示学生与课程间的联系“学”是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。图4.7M∶N关系如图4.8所示，联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以这是学生与课程之间的联系“学”的属性。图4.8联系的属性

4．实体-关系图的符号

通常，使用实体-关系图(EntityRelationshipDiagram)来建立数据模型，我们常把实体-关系图简称为E-R图，相应地，用E-R图描绘的数据模型也称为E-R模型。

E-R图中包含了实体(即数据对象)、关系和属性等三种基本成分。通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用无向边把实体(或关系)与其属性连接起来。例如，图4.9是某校教学管理的E-R图。图4.9某校教学管理的E-R图4.5.3数据流图

当信息在软件中移动时，它将被一系列“变换”所修改。数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理元素，它只是描绘信息在软件中流动和被处理的情况。因为数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，所以它是分析员与用户之间极好的通信工具。此外，设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需考虑怎样具体地实现这些功能，因此，它也是今后进行软件设计的很好的出发点。可以在任何抽象层次上，使用数据流图表示系统或软件。事实上，可以分层次地画数据流图，层次越低表现出的信息流细节和功能细节也越多。数据流图既提供了功能建模机制，也提供了信息流建模机制。

1．数据流图符号

如图4.10(a)所示，数据流图有四种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数据流，即特定数据的流动方向。注意，数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。图4.10数据流图的符号(a)基本符号的含义；(b)附加符号的含义处理并不一定是一个程序。一个处理框可以代表一系列程序、单个程序或者程序的一个模块；它甚至可以代表用穿孔机穿孔或目视检查数据正确性等人工处理过程。一个数据存储也并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等，数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上(包括人脑)。

数据存储和数据流都是数据，它们的区别仅是所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。

通常在数据流图中忽略出错处理，也不包括诸如打开或关闭文件之类的内务处理，数据流图的基本要点是描绘“做什么”，而不考虑“怎样做”。有时数据的源点和终点相同，这时如果只用一个符号代表数据的源点和终点，则将有两个箭头和这个符号相连(一个进一个出)，可能其中一条箭头线相当长，这将降低数据流图的清晰度。另一种表示方法是再重复画一个同样的符号(正方形或立方体)表示数据的终点。有时数据存储也需要重复，以增加数据流图的清晰程度。为了避免可能引起的误解，如果代表同一个事物的同样符号在图中出现在n个地方，则在这个符号的一个角上画n-1条短斜线做标记。

除了上述四种基本符号之外，有时也使用几种附加符号。星号(*)表示数据流之间是“与”关系(同时存在)；加号(+)表示“或”关系；

号表示只能从中选一个(互斥的关系)。图4.10(b)所示为这些附加符号的含义。

2．数据流图例子

下面通过一个简单的例子来具体说明怎样画数据流图。

假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。

数据流图有四种成分：源点或终点、处理、数据存储和数据流。因此，画出上述订货系统的数据流图可采用以下步骤：

(1)从问题描述中提取数据流图的四种成分。首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。

(2)考虑处理。再一次阅读问题描述：“采购部需要报表”，显然他们还没有这种报表，因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。

(3)考虑数据流和数据存储。系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配——每当有一个事务发生时立即处理它，然而每天只产生一次定货报表。

因此，用来产生定货报表的数据必须存放一段时间，也就是应该有一个数据存储。

注意，并不是所有数据存储和数据流都能直接从问题描述中提取出来。例如，“当某种零件的库存数量少于库存量临界值时就应该再次订货”，这个事实意味着必须在某个地方有零件库存量和库存量临界值这样的数据。因为这些数据元素的存在时间看来应该比单个事务的存在时间长，所以认为有一个数据存储来保存库存清单数据是合理的。表4.5列出了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。表4.5组成数据流图的元素可以从描述问题的信息中提取一旦把数据流图的四种成分分离出来，就可以着手画数据流图了。但是要注意，数据流图是系统的逻辑模型，而任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。因此，任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。对于上述的订货系统可以画出如图4.11所示的基本系统模型。

图4.11订货系统的基本系统模型从基本系统模型这样非常高的抽象层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点/终点是一目了然的，因此它是很有价值的通信工具。然而，图4.11毕竟太抽象了，从这张图上所能了解到的订货系统的信息非常有限。下一步应该把基本系统模型细化，描绘系统的主要功能。由表4.5可知，“产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替图4.11中的“订货系统”。此外，细化后的数据流图中还增加了两个数据存储：处理事务需要“库存清单”数据；产生报表和处理事务在不同时间，因此需要存储“订货信息”。除了表4.5中列出的两个数据流之外还有另外两个数据流，它们与数据存储相同。这是因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同，也就是说，数据存储和数据流只不过是同样数据的两种不同形式。在图4.12中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。图4.12订货系统的功能级数据流图接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。考虑通过系统的逻辑数据流，当发生一个事务时必须首先接收它，随后按照事务的内容修改库存清单，如果更新后的库存量少于库存量临界值，则应该再次订货，也就是需要处理订货信息。因此，把“处理事务”这个功能分解为下述三个步骤：“接收事务”、“更新库存清单”和“处理订货”(见图4.13)，这在逻辑上是合理的。图4.13把处理事务的功能进一步分解后的数据流图我们为什么不进一步分解“产生报表”这个功能呢？因为订货报表中需要的数据在存储的订货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理，对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体地实现一个功能时，就不应该再分解了。

在对数据流图分层细化时必须保持信息连续性。也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。例如，图4.11和图4.12所示的输入/输出数据流都是“事务”和“订货报表”；图4.13中“处理事务”这个处理框的输入/输出数据流是“事务”、“库存清单”和“订货信息”，分解成“接收事务”、“更新库存清单”和“处理订货”三个处理之后，它们的输入/输出数据流仍然是“事务”、“库存清单”和“订货信息”。

此外还应该注意在图4.13中对处理进行编号的方法。处理1.1、1.2和1.3是更高层次的数据流图(见图4.12)中处理1的组成元素。如果处理2被进一步分解，它的组成元素的编号将是2.1，2.2……如果把处理1.1进一步分解，则将得到编号为1.1.1，1.1.2……的处理。

3．命名

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题。

(1)为数据流(或数据存储)命名。

①名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。

②不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。

③如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。

(2)为处理命名。

①通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。

②名字应该反映整个处理的功能，而不是它的一部分功能。

③名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。

④通常名字中仅包括一个动词。如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。⑤如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。

数据源点/终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常，为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”等)。4.5.4状态转换图

状态转换图(简称状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指出了作为特定事件的结果系统将做哪些动作(例如处理数据)。因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。

1．状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式，系统对事件的响应既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。在状态图中定义的状态主要有初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。

状态图既可以表示系统循环动作过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的；当描绘单程生命期时，需要标明初始状态(系统启动时进入初始状态)和最终状态(系统运行结束时到达最终状态)。

2．事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。

3．符号

在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。

中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。活动表的语法格式如下：

事件名(参数表)/动作表达式

其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry、exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。事件表达式的语法如下：

事件说明[守卫条件] / 动作表达式

其中，事件说明的语法为：事件名(参数表)。

守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生；如果只有守卫条件没有事件说明，则只要守卫条件为真，状态转换就发生。

动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

图4.14所示为状态图中使用的主要符号。图4.14状态图中使用的主要符号

4．状态图例子

为了具体说明怎样用状态图建立系统的行为模型，下面举一个例子。图4.15是人们非常熟悉的电话系统的状态图。图4.15电话系统的状态图4.5.5数据字典

如前所述，分析模型包括数据模型、功能模型和行为模型。在上述任何一种模型中，数据对象或控制信息都有重要作用。因此，需要有一种系统化的方式来表示每个数据对象和控制信息的特性，数据字典正是用来完成这项任务的。

数据字典是在描述结构化分析过程中定义对象的内容时所使用的一种半形式化的工具。下面是对这个重要的建模工具的定义。

数据字典是所有与系统相关的