中科院需求工程 8D讲)多视点需求工程与矛盾需求处理_解析.ppt

需 求 工 程 金芝 中国科学院数学与系统科学研究院 zhijin@amss.ac.cn 什么是视点？ 理解系统的需求，需要理解： 系统提供的服务 系统的应用领域 系统将处于的环境 影响系统的组织问题 等等 因此，需求工程过程涉及： 捕获、分析和决定——各种意见 什么是视点？ 视点： 出自一个特定角度的，关于系统或相关问题、环境和应用领域的一组信息 角度： 系统的最终用户 其它的系统 涉及系统开发的工程师 任何系统相关者 什么是视点？ 假设： 针对整个系统而言，每个视点都是不完整的 整个系统的需求将通过集成各个视点信息得到 由于一般而言视点之间会包含不同的需求，因此特别地要涉及矛盾的归结过程 什么是视点？ “火车自动控制系统”中的可能视点和需求来源： 司机：来自火车司机的需求，可能大部分是涉及可用性的非功能性需求 轨道设备：来自轨道设备的需求，这些轨道设备将与系统发生交互 已有的其它系统：来自已经存在的其它系统的兼容性需求 安全工程师：来自于铁路安全工程师的系统安全性需求 火车制动装置的特征：从火车制动装置的特性中导出的需求 什么是视点？ 视点：需求相关者对问题某个方面的观点，显式区别不同的需求来源 视点是分离关注点的一种方法，让参与者仅仅关注他们感兴趣的问题，忽略与他们无关的问题 提供组织和结构化这些不同信息的机制 提供手段，让需求源或需求相关者标识和检查他们对需求的贡献 第十讲：面向视点的需求方法 结构化分析和设计技术（SADT） 控制需求表达（CORE） 面向视点的系统工程（VOSE） 面向视点的需求定义（VORD） 面向视点的需求验证 “问题”需求的处理框架 从结构化分析和设计技术（SADT）中谈起 SADT方法 SADT方法中的视点 没有显式的视点定义，是其建模技术的直观推广 由它的数据和来源和去向决定视点 SADT方法中的视点 SADT方法中的视点 视点只是一种直觉,而没有明确的表示 没有关注视点定义的专门步骤 视点只出现在上下文层 没有超出只将视点作为数据的来源和出处的视点分析 控制式需求表达（CORE） CORE方法概述 英国宇航局，七十年代末期 关注功能分解（与SADT相同），但不同的是，它显式地以视点为基础 用于欧洲宇航工业界，著名的项目包括： 八十年代中旬的实验飞行器计划，CORE用于系统和软件定义 最近的欧洲战斗机计划，CORE作为标准的需求分析方法 CORE方法中的视点 分两层考虑视点 第一层次：识别与目标系统交互的或者影响目标系统的实体 CORE提供识别功能性和非功能性视点的指南 第二层次：区别定义视点和边界视点 定义视点：系统的子过程，采用自顶向下的方式 限界视点：间接地与目标系统发生交互的实体 CORE方法的步骤 迭代式过程 视点识别 视点结构化 表表示的采集 数据结构化 单视点建模 组合视点建模 约束分析 举例（图书馆管理） 举例（图书馆管理） 举例（图书馆管理） 举例（图书馆管理） 第三步：表表示法 采集视点信息的一种机制 包括：执行的行为、这些行为要使用的数据、导出的输出数据、数据的来源、数据的目的地 主要侧重在信息流建模，便于视点间数据流冲突的检测，包括数据来源和目的地的一致性等 举例（图书馆管理） CORE方法的其余步骤 第四步，数据结构化：将数据项分解为其组成部分，创建数据字典 第五步和第六步，单视点建模和多视点组合建模：采用活动图为视点活动建模，类似于SADT，说明活动的过程，以及关联到的表集 第七步，约束分析：将系统看作一个整体进行分析 CORE方法的问题讨论 任何实体都可以是视点，对什么是视点缺少明确的界定 定义视点和限界视点使视点的识别更加复杂 限界视点是将与目标系统发生信息交互的外部实体 定义视点是目标系统的子过程 分析比较薄弱，仅关注于内部视点（定义视点），对限界视点不进行分析，它们只是作为与系统交互的数据来源和目的地 面向视点的系统工程（VOSE） VOSE概述 九十年代早期，Imperial College London 基本原理： 软件开发涉及许多专家的参与 这些专家关注于软件开发和应用领域的不同方面 每个专家都只负责或关注他所关心的方面 VOSE视点 使用视点来捕获上述不同的方面，划分和分布参与者的活动和知识 捕获参与者在软件开发特定阶段的角色和职责 通过参与者的角色来识别视点 不同角色的知识封装在一个视点内，VOSE提供了视点的表示风格 什么是视点? 松耦合、局部管理、分布的对象，它封装了关于系统及其领域的： 部分表示知识 开发过程知识 规格说明知识 标准视点框架 视点类型 一个视点框架就是一个视点类型，它只包含 风格（style）槽 工作计划（work plan）槽 按照工作计划槽中定义的行为开发视点，得到视点类型的一个实例 主要研究的问题 视点的表示 视点内