需求工程讲稿-第三讲需求工程的方法.pptVIP

需求工程的方法 过程、方法和技术 描述的重要性 建模的作用 需求工程的维度 表示维（代表需求的可维护、可验证的程度） 非形式的：自然语言 半形式的：图形语言（如：UML，DFD，等） 形式的：数学或逻辑语言（如：Z，等） 内容维（代表需求工程的进行程度） 模糊的客观世界现象 明确的需求规格说明 一致性维 代表某个投资者的观点 得到全部投资者的认可 需求工程的三维视图 再论描述的重要性 软件开发：获取描述+逐步精化 需求：是过程的起点 什么、怎样、相互转化 传统地，需求应该说明‘什么’而不说明‘怎样’ 但是这不很容易区分： 一辆小汽车做什么？ 一个WEB浏览器做什么？ 在某个抽象层次上的‘怎样’形成下一个层次上的‘什么’ JacksonZave的工作提供了一个区分： ‘什么’涉及系统的目的 对系统来说是外部的 是应用领域的特性 ‘怎样’涉及系统的结构和行为 对系统是内部的 是机器领域的特性 关注于问题 问题先于解决方案 硬件和软件都能正常运行，但它起的作用却不是所想要的 对提早发现潜在的困难有帮助，困难越后发现越难解决 计算机系统和现实世界的关系 需求处于环境之中 机器 我们称要被开发出来的软件系统为机器 硬件是为了运行软件而存在的，因此是机器的一部分 应用领域 机器将与它所处的环境发生交互 建立机器为了实现现实世界中的某个目的 定义机器的环境，就是定义应用领域 应用领域常常是人类活动的系统 实现的决策是出于那些在应用领域中没有基础的需求 例子：字典要存放在Hash表中；病人记录要存放在一个面向对象数据库中 需求的环境 需求的环境 需求就是描述 指代： 环境中的实体：为它规定一个名字 观察到的现象：告诉你怎样识别它，并为它规定一个名字 指代通常是非形式的，但它将一个模糊的现象映射到一个形式的（或者说可表达的）语言上 定义 为一个术语给出形式的定义，使这个术语能在其它描述中使用 定义或多或少是有用的，但它却是没有对错的 需求就是描述 可反驳的描述：领域的特性 陈述领域的某种特性，这种特性在原理上是可反驳的 可能实际上并不会去反驳它，但应该有这样的意识 可反驳性依赖于对我们正在描述的领域中的这个被指代的现象的一种询问 一个粗略的框架 是要被开发出来系统描述的一个尝试性描述 允许包含未定义的术语 例子 指代： MOTHER(X,M)：表示M是X的母亲 定义： CHILD(X,Y) ::= MOTHER(Y,X)?FATHER(Y,X) 可反驳的描述： 对所有M和X有，MOTHER(X,M) ? ?MOTHER(M,X) 粗略的框架： 每个人实际上都只属于一个家庭 描述的语气问题 描述的不同语气 直述：给出一个事实 询问：问一个问题 命令：传递一个命令 假设：陈述一种可能 希求：表达一种愿望 需求是希求式的 需求一定包含“应该做什么” 对需求工程来说，一般应该有的语气： 领域特性：直述式语气 需求：希求式语气 语气随开发进程不断变化 需求的内容维：模型 现实中的三类模型 图示模型：一个雕塑，可视化 类比模型：一架模型飞机，使能测试经验的决策 分析模型：表示社会经济的一组数学方程，使能分析所描述的系统的可能行为 需求中的模型 模型的抽象性 模型不仅仅是描述 它具有自己的现象，和它自己的关于这些现象之间的关系 只有当模型的现象按一种系统的方法对应到要被建模的领域的现象时，这个模型才是有用的。 模型是描述的抽象 模型的抽象性 建模中隐含的危险 一个模型绝对不会是完美的：两个方面的危险 存在模型中的现象不在应用领域中出现 存在应用中的现象不在模型中出现 如何应对现实世界的复杂性 结构化原理之一：划分 划分：捕获聚合/part-of关系 例子： 目标：开发一个航天飞机 划分： 引导和导航 数据处理 命令和控制 环境控制 仪表 …… 注意：这不是设计，这只是一个问题分解 实际的设计还有一些组件，这些组件和这些子问题没有关系 然而，问题分解的选择可能将反映在设计中 结构化原理之二：抽象 抽象： 通过忽略一些细节来发现概念之间的相似性的方法 关注于现象之间的“普遍/特殊”关系 分类：将具有某个相似点的实体定义成一组，作为一个单一的类的成员 泛化：表示“is-a”关联中的不同类之间的相似性 例子 需求：处理航天飞机的故障 可以将不同故障按不同故障类来组织 按照故障的位置 仪表故障 通讯系统故障 处理器故障 …… 按照故障的表象 没有来自设备的响应 不正确的响应 自检失效 …… …… 结构化原理之三：投影 投影 分离模型的不同方面为多个视点 与建筑图纸中使用的投影概念相同 例子 需求：为航天飞机和地面系统之间的通讯系统建模 独立的模型： 消息序列 数据包格式 错误校正行为 …… 注意 投影和划分是相似的 划分定义part-of关系 投影定义view-of关