《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著010》由会员分享，可在线阅读，更多相关《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著010（12页珍藏版）》请在金锄头文库上搜索。
1、下载第 1 0章 需求的图形化分析“化学制品跟踪系统”的项目开发组正在进行第一次软件需求规格说明的评审。参加者有 D a v e（项目经理） ， Lori （需求分析者） ， H e l e n (高级程序员 )， Ramesh (测试专家 )， Ti m (化学制品的产品代表者 )，还有 R o x a n n e (化学制品仓库的产品代表者 )。Ti m开始说： “我阅读过整个软件需求规格说明。大部分都符合我的需求，但是有几个部分我很难同意。我不能确信在化学制品请求过程中，我们是否确定了这些步骤。 ”R a m e s h又补充说： “当一个请求通过系统时，我很难想象用于覆盖该请求状态变化
2、的所有测试用例。我发现许多关于状态变化的需求散布在整个软件需求规格说明中，但我无法确定是否有一些需求遗漏了或存在不一致性。 ”R o x a n n e有一个类似的问题。 “当我阅读了如何真正请求一种化学药品时，我感到困惑” ，她说， “单个需求是能感觉到的，但我难以想像我所要完成的步骤顺序。 ”在各评审员提出其它相关的问题后， L o r i做出了总结： “看来软件需求规格说明似乎没有完全告诉我们对于理解系统所需的各个方面，也不能确保我们没有错过一个需求或不犯任何错误。我将画一些图来帮助我们想像这些需求，并看一下能否澄清这些问题域。谢谢你们的反馈意见。 ”根据在需求方面的权威 Alan Da
3、vis的见解，仅仅单一来看需求并不能提供对需求的完全理解（ Davis 1995） ，你需要把用文本表示的需求和用图形表示的需求结合起来，绘制出对预期系统的完整描述，并可帮助你检测不一致性、模糊性、错误和遗漏。这些图形化的表示或者分析模型可以增强你对系统需求的理解。在项目的参与者之间，对于某些类型的信息，图形化交互比文本交互更高效，并且可以在不同的开发组成员之间扫清语言和词汇上的障碍。本章将提供对需求建模技术的简要概述，在我看来，这些技术有助于理解用户的业务问题和软件需求。10.1 需求建模许多年前，当我开始绘制分析模型时，我希望找到一种技术，可以把所有的内容都包容进一个完整的需求描述中。最终
4、我得出一个结论：不存在一个包罗万象的图。早期的结构化系统分析的目标是用比叙述文本更正式的图形表示来替换整个分类功能规格说明 (DeMarco 1979)。然而，经验告诉我们：分析模型应该增强自然语言的需求规格说明，而不是替换之 (Davis 1995)。需求的图形化表示的模型包括数据流图（ D F D） 、实体关系图（ E R D） 、状态转化图（ S T D） 、对话图和类图。还有一些非常规的建模方法也是有价值的。一个项目开发组利用项目规划工具为嵌入式软件产品成功地画出时间需求，其工作在毫秒级，而不是以天或星期计算。这些模型有助于解决设计软件的问题，而且对详述和探索需求也是有益的。作为需求分
5、析工具，你可以用这些图对问题域进行建模，或者创建新系统的概念表示法。图形有助于分析者和客户在需求方面形成一致的、综合的理解，并且还可以发现需求的错误。在需求分析方面或设计方面是否使用模型取决于建模的定时和目的（ timing and intent ofthe modeling） 。在需求开发中通过建立模型来确信你理解了需求。模型描述了问题域的逻辑方面，如数据组成、事务和转换、现实世界对象和允许的状态。或者可以从文本需求出发来画模型，从不同的角度来表示这些需求，或者可以从所画的基于用户输入的模型来获得功能需求。在设计阶段，要从物理上而不是从逻辑上画出模型来明确说明将如何实现该系统：规划建立的数据
6、库，将举例说明的对象类，还有你将开发的编码模块。本章所叙述的分析建模技术是由各种商业计算机辅助软件工程或 C A S E工具支持的。C A S E工具提供了普通画图工具所没有的许多性能。首先，这些工具通过交互画图使你易于对模型进行改进。决不可能第一次就画出一个正确的模型，因此，在系统建模中提供交互功能是成功的一个关键（ Wiegers 1996a） 。第二， C A S E工具知道它们所支持的每一种建模方法的规则。它们可以验证模型，并且识别人们在评审图形时没有发现的语法或逻辑错误。该工具还可以把多系统图形一起连接到数据字典中以共享数据定义。 C A S E工具有助于你保持模型之间的一致性并使模
7、型与软件需求规格说明中的功能需求保持一致。分析模型方便了项目参与者在系统的某些方面的交流。可能不需要整个系统的模型集，只需关注建模中系统最复杂和最关键的部分，因为这部分最容易产生模糊性和不确定性。这里所表示的符号为项目的参与者提供了统一的语言，但是也可以使用非正式的图来增强口头和书面的方案交流。10.2 从客户需求到分析模型通过认真听取客户如何陈述它们的需求，分析者可以挑选出关键字，这些关键字可以翻译成特定的分析模型元素。表 1 0 - 1建议了一些可能的映射，根据客户输入，把重要的名词和动词映射成特定的模型组件，这将在本章的后面部分介绍。当把客户输入转变为书面的需求或模型时，还可以根据模型的
8、每个组件回溯到需求部分。表 10-1 把客户的需求关联到分析模型的组件单词类型 例 子 分析模型组件名词 人、组织、软件系统、 端点或数据存储（ D F D）数据项或者存在对象 实体或它们的属性（ E R D） 类或它们的属性（类图）动词 行为、用户可做的事 过程（ D F D）或可发生的事件 关系（ E R D） 转化（ S T D） 类操作（类图）在整本书中，我已经使用“化学制品跟踪系统”作为一个学习的例子。基于此例子，考虑如下用户需求部分，这些需求是由代表化学制品用户类的产品代表者提供的。由于用图示例的缘故，一些模型所示的信息可能会超出这部分所包含的信息，而另一些模型可能只描述部分信息。
9、“一位化学家或化学制品仓库人员可以提出对一种或多种化学制品的请求。对该请求的执行可以有两种途径：一是传送一个存在于化学制品仓库清单上的化学制品容器，二是向外界供应商提交一份订购新的化学制品的订单。提出请求的人在准备他 /她的请求时应该可以通过在线查找供应商目录表找到特定的化学制品。系统需要从请求准备直到请求执行或取消这一阶段跟踪每一个化学制品的状态。系统还必须保持跟踪每个化学制品容器的历史记录，从化学制品容器到达公司到它完全被消耗或废弃为止。 ”86 第二部分 软件需求工程 下载10.3 数据流图数据流图（ data flow diagram， D F D）是结构化系统分析的基本工具（ DeM
10、arco 1979；Robertson and Robertson 1994） 。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集（存储） ，还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上，这种方法很适用于事务处理系统和其它功能密集型应用程序。通过加入控制流元素后，数据流图技术就可以扩充到允许实时系统的建模。数据流图是当前业务过程或新系统操作步骤的一种表示方法。数据流图可以在一个抽象的广泛范围内表示系统。在一个多步骤的活动中，高层数据流图对数据和处理部分提供一个整体的统览，这是对包含在软件需求规格说明中的精确、详细叙述的补充。数据流图描述了
11、软件需求规格说明中的功能需求怎样结合在一起使用户可以执行指定的任务，例如请求一种化学制品。在与用户一起讨论业务过程时我经常绘制数据流图。从图中迅速反馈的信息有助于对所探讨的任务流的理解进行提炼加工。图 6 - 2所示的关联图是数据流图最高层的抽象。关联图把整个系统表示成一个简单的黑匣子的过程，并用一个圆圈表示。关联图还表示出外部实体或与系统有关的端点，以及在系统与端点之间的数据和物质流。在关联图中，元素之间的流往往代表了复杂的数据结构，这些数据结构在数据字典中定义。你可以把关联图详述成 0层数据流图，这时将系统划分为主要部分或过程。图 1 0 - 1展示了“化学制品跟踪系统”的 0层数据流图（
12、略作简化） 。在关联图中代表整个“化学制品跟踪系统”的单一过程圆圈被细分成 7个主要过程（圆圈） 。在关联图中，端点用矩形框表示。关联图中所有的数据流也出现在 0层数据流图上。此外， 0层数据流图包含了许多数据存储（ data store） ，它是用一对水平的平行线表示，由于数据存储在系统内部，因此它们并不出现在关联图中。从圆圈到数据存储的流表示数据放入数据存储器，从数据存储器出来的流表示一个读操作，而数据存储器和圆圈之间的双向箭头则表示一个更新操作。在 0层图中，每个独立的圆圈所代表的过程可以进一步扩展成一个独立的数据流图，以揭示系统中程序的细节部分。这种循序渐进的细化过程可以继续进行，直到
13、最低层的图仅描述原子过程操作为止，这些原子操作可以清楚地表示所叙述文本、伪码、流程图或程序代码。软件需求规格说明中的功能需求将精确地定义每个原子过程的行为。每一层数据流图必须与它上一层数据流图保持平衡和一致，因此，子图的所有输入输出流要与其父图相匹配。高层图中复杂的数据流可以分解到低层数据流图中，并把这些数据结构写入数据字典中。初看起来，图 1 0 - 1可能有点混乱。然而，如果你仔细观察每一个过程的周围环境，你就会看到该过程的输入和输出数据项，还有它们的源和目的地。与数据存储相连的流可以引起建立或消耗数据存储内容的过程。为了看清一个过程如何使用数据项，你需要画出更详细的D F D子图或者参考
14、系统有关部分的功能需求。以下是绘制数据流图的一些规则。并不是每个人都要遵循这些规则，但是我发现这些规则很有用。利用模型以增进项目参与者之间的交流比生搬硬套这些规则更为重要。 把数据存储放在 0层数据流图或更低层子图上，不要放在关联图上。 过程是通过数据存储进行通讯，而不是从一个过程直接流到另一过程。类似地，数据不能直接由一个数据存储直接流到另一个数据存储，它必须通过一个过程圆圈。 使用数据流图时，不要试图让数据流图反映处理的顺序。第 1 0章 需求的图形化分析 87下载图 10-1 “化学制品跟踪系统”的 0层数据流图 用一个简明的动作命名过程：动词 +对象。数据流图中所用的名字应对客户有意义
15、，并且与业务或问题域相关。 对过程的编号要唯一且具有层次性。在 0层图上，每个过程的编号用整数表示。如果你为过程 3创建子图，则子图中的过程编号应表示为 3 . 1， 3 . 2等等。 不要在一个图中绘制多达 7 1 0个以上的过程，否则就很难绘制、更改和理解。 不要使某些圆圈只有输入或只有输出。数据流图中圆圈所代表的处理过程通常要求既有输入又有输出。10.4 实体联系图与数据流图描绘了系统中发生的过程一样，实体联系图（ entity-relationship diagram，E R D）描绘了系统的数据关系（ Wieringa 1996） 。如果你的实体联系图表示来自于问题域及其88 第二部
16、分 软件需求工程 下载7查询供应商目录 查询供应商目录表供应商目录表信息供应商目录表 供应商目录表1提出化学制品请示化学家 化学制品仓库人员训练数据库采购部门 健康与安全部门供应商目录表信息化学制品容器化学制品容器化学制品请求化学制品请求存货清单更新6存货清单更新2在仓库中完成请示信息训练记录请求危险训练记录 请示信息仓库请求 化学制品容器化学制品请求供应商订单状态供应商化学制品请求3请求一供应商化学制品供应商订单状态供应商化学制品请求4产生政府报表化学制品使用报表请求化学制品使用报表存货跟踪数据5生产存货报表 存货报表存货状态化学制品容器存货更改制品仓库存货联系的逻辑信息组，那么你正在利用实体联系图作为需求分析的工具。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。相反，当你在系统设计阶段建立实体联系图时，通常要定义系统数据库的物理结构。图 10-2 “化学制品跟踪系统”的实体联系图实体（ e n t i t y）是物理数据项（包
