软件需求--第10章需求的图形化分析.pdfVIP

下载 第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又补充说：“当一个请求通过系统时，我很难想象用于覆盖该请求状态变 化的所有测试用例。我发现许多关于状态变化的需求散布在整个软件需求规格说明 中，但我无法确定是否有一些需求遗漏了或存在不一致性。” R o x a n n e有一个类似的问题。“当我阅读了如何真正请求一种化学药品时，我感 到困惑”，她说，“单个需求是能感觉到的，但我难以想像我所要完成的步骤顺序。” 在各评审员提出其它相关的问题后，L o r i做出了总结：“看来软件需求规格说明似乎 没有完全告诉我们对于理解系统所需的各个方面，也不能确保我们没有错过一个需求或 不犯任何错误。我将画一些图来帮助我们想像这些需求，并看一下能否澄清这些问题域。 谢谢你们的反馈意见。” 根据在需求方面的权威Alan Davis 的见解，仅仅单一来看需求并不能提供对需求的完全理 解（Davis 1995 ），你需要把用文本表示的需求和用图形表示的需求结合起来，绘制出对预期 系统的完整描述，并可帮助你检测不一致性、模糊性、错误和遗漏。这些图形化的表示或者分 析模型可以增强你对系统需求的理解。在项目的参与者之间，对于某些类型的信息，图形化交 互比文本交互更高效，并且可以在不同的开发组成员之间扫清语言和词汇上的障碍。本章将提 供对需求建模技术的简要概述，在我看来，这些技术有助于理解用户的业务问题和软件需求。 10.1 需求建模 许多年前，当我开始绘制分析模型时，我希望找到一种技术，可以把所有的内容都包容进 一个完整的需求描述中。最终我得出一个结论：不存在一个包罗万象的图。早期的结构化系统 分析的目标是用比叙述文本更正式的图形表示来替换整个分类功能规格说明(DeMarco 1979) 。然 而，经验告诉我们：分析模型应该增强自然语言的需求规格说明，而不是替换之(Davis 1995) 。 需求的图形化表示的模型包括数据流图（ D F D ）、实体关系图（ E R D ）、状态转化图 （S T D ）、对话图和类图。还有一些非常规的建模方法也是有价值的。一个项目开发组利用项 目规划工具为嵌入式软件产品成功地画出时间需求，其工作在毫秒级，而不是以天或星期计 算。这些模型有助于解决设计软件的问题，而且对详述和探索需求也是有益的。作为需求分 析工具，你可以用这些图对问题域进行建模，或者创建新系统的概念表示法。图形有助于分 析者和客户在需求方面形成一致的、综合的理解，并且还可以发现需求的错误。 在需求分析方面或设计方面是否使用模型取决于建模的定时和目的（ timing and intent of the modeling ）。在需求开发中通过建立模型来确信你理解了需求。模型描述了问题域的逻辑 方面，如数据组成、事务和转换、现实世界对象和允许的状态。或者可以从文本需求出发来 86 第二部分 软件需求工程 下载 画模型，从不同的角度来表示这些需求，或者可以从所画的基于用户输入的模型来获得功能 需求。在设计阶段，要从物理上而不是从逻辑上画出模型来明确说明将如何实现该系统：规 划建立的数据库，将举例说明的对象类，还有你将开发的编码模块。 本章所叙述的分析建模技术是由各种商业计算机辅助软件工程或 C A S E 工具支持的。 C A S E工具提供了普通画图工具所没有的许多性能。首先，这些工具通过交互画图使你易于对 模型进行改进。决不可能第一次就画出一个正确的模型，因此，在系统建模中提供交互功能 是成功的一个关键（ Wie