毕业论文－需求分析的方法与建模(编辑修改稿)

毕业论文－需求分析的方法与建模(编辑修改稿)内容摘要：

关建模技术之间的最重要区别在于他们是构成系统的外部模型还是构成系统的内部模型。 表 建模技术对比 外部建模 内部建模 功能的 结构的 黑盒 白盒 行为的 非行为的 外部模型 外部模型可进一步划分为建模系统外观的模型和建模系统行为的抽象模型。 表示建模 表示模型是对系统外观进行的模仿，相当于描述可见的输出，最有效的表示法通常是画图。 这种技术特有的优点是易于获得工具支持、模糊性低、不易出错和可理解性高。 对软件系统定义而言，它并不是全部的内容，只是一个从中起着有效作用的基本元素。 原型法 原型在其他工程领域有着历史悠久的传统，但在软件工程中，使用原型是最近几年的事情。 合算的开发原型需要相对强有力的开发平台，好在现在已 经没有了技术障碍，原型开发得到了快速的采用。 原型可以为各种目的而购造，与需求工程相关的是那些试图绘制所需系统的外观和一些可能的行为的原型。 对原型一个普遍认同的分类： 探索性原型 —— 帮助需求获取或细化需求，也称为一次性原型，一旦需求工程完成后，它便没有用处。 定义原型 —— 形成部分所需行为的定义，即部分规格说明。 建模技术 11 结构原型 —— 用于评价可能的内部设计方案，例如检查性能。 虽然是用于设计阶段，但也用于需求阶段可行性的检查。 演化原型 —— 通过逐步求精过程，原型最终成为了产品。 需求工程主要关注的是前两种原型，原型开发 隐含着迭代。 如在需求获取中：初始原型将向用户演示，获得的反馈将用于细化原型，在实践中这种迭代会出现好几次。 迭代中可能会增加新内容，也可能减少内容。 原型在需求工程中主要作用是对用户接口进行建模，尤其是当这些接口相当复杂、关键、新鲜时。 原型开发的一个潜在好处是：可以促进潜在用户的参与和客户的承诺，但有个副作用：真实原型的早期外观会误导人们认为该项目比实际情形先进得多，随着最终产品的出现就会感到失望。 行为（功能）建模 行为模型只是系统行为的抽象。 行为建模有很多种，我们就较一般的可能用到的简单介绍几 个 ： 1. 功能声明与分解 功能声明也许是最简单、常用的行为定义技术。 声明使用文本方式，描述输入和输出之间的因果关系。 功能分解可以说是一种高级策略，通过许多其他方式实现，如 UseCase 、 DFD 、结构图。 基本思想相当简单，通常系统功能性的详细定义是按层次结构来实现的，即通过把功能分解为若干低层的、更为详细的功能集。 该技术也称为功能求精或功能组合。 2. 任务分析 任务分析，涉及的是人的任务性能的分析或外部设计，特别用于人机接口（ HMI）。 任务分析从人们所希望获得的目标开始。 任务是获得这些目标的高级机制 ，操作是实现任务的交互。 3. 用例与脚本 用例（ usecase）描述所设计的解系统与一个或多个端子之间的某种特定的交互。 用例在面向对象领域主要作为一种分析和规格说明的技术。 对新系统将投入使用的环境进行分析相当于研究该系统所必须满足的要求。 事实上，情形可能是客户和潜在用户确实发现用例易于理解，因此，用例就有助于客户 /用户与开发建模技术 12 者之间的交流。 大多数用例都有“执行者”，可以是人，也可能是系统的软硬件设施。 用例文档可以用文本或 UML 图来描述。 用例的应用和构造具有相当大的灵活性，人们可能认为它不够严格，但 是 应用 指定的 合适的指导原则可以解决这个问题。 4. 有限状态机 有限状态机（ Finite State Machines， FSM）通过输入与输出之间的因果关系对系统的行为进行建模。 (1) 系统可看作有若干个相互区别的稳定状态； (2) 当条件改变时，系统从一个状态改变到另一个状态； FSM 的设计规则  转移总是起始于一个状态并终止于一个状态。  一个转移总是有一个相关的触发器。  一个转移可以有一个或多个相关动作。  同一个触发器可能对多个状态有效。 内部模型 内部模型是对系统内部的构造或体系结构的建模技术。 可以很简单的 把 解 系统的内部分成两方面：数据和操作。 根据建模所侧重的方面，可以划分为三种内部建模技术。 1. 面向处理技术 抽象的把所考虑的系统建模成一组通信子系统，重点放在它们实施的处理上。 (1) 通信并发处理 这个模型把子系统看成是并行运行的，现实世界中的各种事物也是通常是如此的，因此 它 具有相当的直观性。 最常采用的方法是“数据流图”，即 DFD。 DFD 的开发需要大量的专门知识，以消除建模中可能导致的二义性和错误。 好的 DFD 后面的解释是较为直观的，因而可理解性是比较良好的。 以下规则可以用来检查 DFD 的有效性：  数据不能直接在数据存储之 间流动；  数据在端子之间的流动不显示； 建模技术 13  处理和数据存储通常至少有一个输入和一个输出。 (2) 通信顺序处理 虽然真实事物一般都是 一个 并行的系统， 就 如 同 一个人可 以同时做很多事情一样。 但是，大部分计算机以顺序的方式处理，特别的 在 软件 设计的时候（即使是面向对象设计）。 对通信顺序处理建模的常用表示法有树状图或结构图，另一种主要方法是伪码。 2. 面向数据结构的技术 数据结构建模是 所有 信息系统最重要的 技术 ， 也 常称为数据分析，关注的是静态数据的结构。 实体属性关系建模 ，则是数据库应用系统的通用方法。 当进行数据分析时，通常起 始点是搜索需求获取记录，选出候选实体。 识别有意义实体的好方法是问问：“哪些相关信息与这个实体相联系。 ”。 与实体相关联的信息即为实体的属性。 实体间的关系有三种：一对一，一对多，多对多。 3. 处理 /数 据相结合 该技术集中在对发生的处理和处理的数据的建模上，采用了一种完整的观点，却抽象更加复杂。 主要的两种模型是实体生命历史（ ELH） 和面向对象建模。 实体生命历史建模起的是辅助性的作用，它从数据分析和数据流建模继续而来，实体来自于 ERD，实体处理来自 DFD，然后为每个实体的有关处理顺序进行建模。 ELH 的作用是在其他模型 之间充当一个交叉的检查和一种集成。 面向对象建模把所考虑的系统建模为一组相互通信的对象。 一个对象是存储数据和对其数据上的操作进行抽象。 识别和定义对象只是一部分工作。 还必须探讨对象间的关系。 选择技术 可以从两个方面来选择技术： 1. 特定的目的需要什么技术 2. 特定的技术适合什么目的 特定的目的或许更多的需要我们去挖掘、思考，而熟悉各种技术的常见应用领域将会有很大帮助。 建模技术 14 表 常见应用领域表 上下文图 问题框架 一次性原型 功能分解 用例 任务动作法 F S M D F D 结构图 E R D E L H 面向对象 D D (B N F) 需求获取 √ √ 问题域（ PD）概述 √ √ 问题域结构 √ √ √ PD 数据模型 √ √ √ I/O 问题数据 √ √ 子域行为 √ 子域状态 √ √ 功能需求 √ 性能需求 √ 约束 SS 外观 √ I/O 解数据 √ SS 行为（ ER 动作） √ √ √ √ √ SS 状态 √ √ 定时 √ √ 需求分析实践 15 第四章 需求分析实践 项目介绍 在现有《中远船员综合管理信息系统》操作平台的基础上， 用不到一年的时间，设计开发中远通用、技术先进、功能全面、人性化与智能化突出的“中远船员信息系统”（以下简称 CSIS），同时建立起以集团为核心的，联结各家系统的中远船员信息管理网络，在中远系统内实现船员信息的高度共享。 按照系统功能划 分，工作小组下设 7 个业务组，分别为调配管理组、证件培训组、劳动工资组、工资核算组、费用报销组、集团平台组、船员平台组。 （由于在做需求过程种，发现报销与工资有很多相近之处，因此已经合二为一） 进度 20xx 年 4 月 – 6 月，完成系统需求调查； 20xx 年 7 – 8 月中旬，在前期需求调查基础上，拿出系统设计初步方案； 20xx 年 8 月中旬 – 8 月底，征求各家单位对初步方案的意见，修订方案； 20xx 年 912 月，进入系统实质开发阶段，在此期间 还需反复征求各家单位意见。 需求调查阶段分四个小组： 调配、工资、劳资、证培。 我所在的小组是工资（包含报销）。 获取需求 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。 需求获取只有通。