| 需求工程:基础、原理和技术8 |
| 波尔(Klaus Pohl) |
| 计算机科学丛书 |
| 33：需求变更管理、34：COSMOD-RE基础、35：COSMOD-RE方法、36：实施COSMOD-RE方法：一个实例 |
第33章 需求变更管理
需求工程中变更管理的任务就是管理需求的变更，并确保每个变更都能被正确地实现以及该变更是可追踪的。
33.1 配置管理
通过两个维度来刻画配置管理
产品（制品）维度：目标、场景，以及面向方案的需求。
版本维度：在版本维度中，版本控制（作为配置管理的一部分）管理产品维度中制品的不同变更状态。
**注：产品维度是需求产品的具体内容层级，版本维度是时序上的变化，版本和基线的流变。
33.1.1 配置管理的层次
需求制品的配置管理分为3个层次：
文档层：需求文档是进行配置管理时所要考虑的最小单元。
需求制品层：需求制品（例如目标、场景、面向方案的需求，以及需求制品之间的关系）是被管理的最小单元。
属性层：需求制品的单个属性（或者一组属性）是进行配置管理时所要考虑的最小单元。通常无法在属性层上进行配置管理。
33.1.2 软件制品的版本
需求制品通常会在需求工程阶段发生变化，通过需求工程的3个维度进行解释。
（内容维度）。（共识维度）。（文档化维度）。
一个需求制品的一个版本可以被看作该需求制品的一个已定义的状态。需求制品的一个版本反映了该制品的一个特定状态。
需求制品的每个版本通过一个唯一的数字进行标识。
33.1.3 需求制品的配置
需求制品的一个配置由一组相关的需求制品组成，由一组相关的需求制品的版本组成。具有如下属性：
❑一致性：在该配置中的需求制品版本之间不存在冲突。
❑唯一标识（ID）；每个配置具有一个唯一标识符（ID）。
❑不可变：一个配置冻结了一个特定状态。
❑回滚的基础：配置及其潜在的制品版本为在处理过程中回滚到先前的状态提供了基础。如果需求制品的变更将导致不一致，并且该不一致无法通过未进行的单个变更被解决时，就需要进行回滚。
33.1.4 需求制品的基线
一条需求制品的基线是一个被选择的需求制品配置。术语“需求基线”是指一个稳定的需求制品版本的配置。
需求基线具有需求配置的所有性质。此外，需求基线还具有如下性质：
❑定义系统发布的基础：一条需求基线定义了在一个系统发布中所要实现的需求制品。
❑对客户可见：是对客户可见的一个需求配置。
❑变更管理的主体：需求基线所包含的需求不能随意更改。
需求基线支持开发过程中的许多重要活动：
❑系统发布计划的基础：基线是计划和定义系统发布的基础。
❑估算实现工作量：一条需求基线可作为估算特定系统发布所需工作量的基础。
❑与竞争产品的比较：需求基线可用来将计划发布的系统与市场上现有的竞争系统进行比较。
术语“需求发布”和“需求基线”通常可互换使用。
33.2 需求变更
需求变更贯穿了系统的整个生命周期。
两类变更原因：①系统运行阶段遇到的问题；②系统上下文（包括系统的开发）的改变。
33.2.1 系统运行过程中遇到的问题
33.2.2 上下文中的改变
主体刻面中的变更
导致对定义输入或输出数据的需求制品的调整需要。
使用刻面中的变更
可能导致需求关注的变化，涉众和其他系统对本系统的使用的变化。
IT系统刻面中的变更
IT系统刻面中的变化是指IT设施或者系统嵌人和执行的技术环境的改变。IT系统刻面的变更尤其由技术进步所引起，同时也可能要求对需求制品进行变更和调整。
开发刻面中的变更
系统开发过程也会导致需求制品的变更。需求不能被实现、不一致情况、无法被测试。
提示33-1：对上下文变更的分析
确保已检查管理活动所识别的上下文变更对需求的影响。如果必要的话，咨询开发团队中的专家或者领域专家来分析所遇到的上下文变更可能产生的影响。
33.3 系统化的变更管理
应该定义并建立一套系统化的变更管理过程。
对属于需求基线的需求而言，系统化的变更管理过程是必需的。
33.3.1变更控制委员会
在每个项目中应该清晰地定义谁来负责对变更请求进行决策。
变更控制委员会通常具有如下职责：
❑对传入的变更请求进行分类：
❑变更集成的预估工作量：
❑变更请求的评估和决策制定：
❑已接受的变更请求的优先级排序：
提示33-2：变更管理委员会的组成
注意，变更控制委员会应该包含属于4个上下文刻面的每一个刻面中的至少一位涉众。
当为变更控制委员会选择涉众的时候，必须考虑项目的细节并引入额外的角色，或者细化角色。
在小型项目中，甚至可以将大多数的角色指派给两个或三个涉众。
变更控制委员会是系统化的变更管理过程的基石，因此在任何情况下都应建立变更控制委员会。
33.3.2文档化变更请求
需求制品的变更请求应该以一种能够支持变更控制委员会决策的方式予以记录。
| 内容 | 描述 |
| 项目名称 | 将实行变更的项目的名称 |
| 请求编号 | 变更请求的连续编号 |
| 标题 | 变更请求的标题 |
| 日期 | 变更请求的日期 |
| 发起人 | 发起人姓名 |
| 起源 | 变更的起源（例如发生变更的市场、管理、客户、架构设计和上下文刻面） |
| 状态 | 变更请求的当前状态（如提交状态、评估状态、拒绝状态、待集成状态、已验证状态、终止状态） |
| 发起人的优先级 | （由变更发起人定义的）变更请求的优先级 |
| 实现的优先级 | （由变更管理委员会定义的）变更请求的优先级 |
| 变更的验证者 | 在变更集成后负责验证变更的人员的名字 |
| 最新的更新日期 | 变更请求的最新的更新日期 |
| 发布版本 | 被指定的、将要集成变更的发布版本 |
| 集成工作量 | 变更集成所需的估算工作量 |
| 变更请求的描述 | 变更请求的文本描述 |
| 备注 | 与变更请求有关的备注，如来自于其他涉众、变更委员会等 |
| 提示33–3：变更请求模板的剪裁应剪裁用于记录变更请求的模板，以满足特定项目或组织的需要。 |
33.3.3变更管理活动
需求变更请求针对已建立的需求基线。区分5种需求变更请求：
❑新需求的集成：一项新的需求已经被抽取出来，并且应被集成到需求基线中。
❑己有需求的移除：一项已有的需求变为无效，因此应将它从需求基线中删除。
❑己有需求的扩展：一项已有的需求应从特定的方面被扩展。
❑已有需求的压缩：一项已有需求的某些方面应被移除。
❑已有需求的改变：一项需求发生变化。
为了在系统的整个生存周期内处理需求的变更，建立起一套发掘与管理变更的变更处理过程是干分必要的。
①新的变更请求分类
❑修正型变更：系统错误或运行时的错误行为导致的，并且至少有一个需求制品对该错误负有责任
❑调整型变更：必须调整需求制品以集成该变更请求。
❑例外变更（即所谓的热修复）：如果变更是绝对必要，并且立即集成。
例外变更不遵循下文所述的修正型变更和调整型变更的变更管理步骤。它们是作为异常进行处理的，并且需要尽快地集成。
②影响分析
影响分析的目标是评估集成变更请求所需花费的工作量。
为了评估这个工作量，需要识别出变更请求所影响到的所有需求。应进一步识别出可能需要进行调整的该需求的后继制品。对每一个受影响的制品，估算变更集成的工作量，并确定所需的整体开销。
可使用已记录的可追踪性信息自动化地识别出受到一项变更请求影响的需求及其后继制品。
③变更请求的评估
基于影响分析得到的工作量估算，对实现这个变更请求的成本与收益进行评估。
在这个评估的基础上，变更控制委员会可以决定是接受还是拒绝变更请求。
提示33-4：对变更请求的拒绝
如果变更控制委员会决定拒绝某一个变更请求，那么应把拒绝情况及拒绝理由告知该变更请求的发起者以及所有的相关涉众。
④变更请求的优先级排序
根据优先级排序的结果，变更请求被集中起来并被指派给一个变更项目，或被指派给实现这些变更请求的一个系统发布版本。
⑤变更集成的监控
变更控制委员会不负责实现变更请求。但是，变更控制委员会监控变更请求的实现以及变更集成的结果，并持续地将变更请求的当前状态告知给相应的变更请求发起者。
第34章 COSMODE-RE基础
当开发复杂的软件密集型系统的需求和体系结构制品时，两个关键挑战：
❑对需求和体系结构制品的复杂性进行管理：COSMOD-RE方法的基础是层次化的、被清晰定义的抽象层。
❑对需求和体系结构制品之间的相互影响进行处理：COSMOD-RE方法支持需求和体系结构的交织、协同开发。
34.1 抽象层
使用抽象层在处理和管理软件密集型系统复杂性问题上的好处包括：
❑层次分解：使用抽象层定义需求和体系结构制品时，一个软件密集型系统被分解为不同层次的抽象，即抽象层定义了分解层次结构。
❑关注点分离：整个系统的不同关注点可以被分配到不同的抽象层中。不同的关注点是相互独立的。更容易地被定义、访问和修改。
❑需求的分类：所得到的系统的清晰分解有助于对需求进行分类。根据一条需求的内容和范围，该需求被分配到一个特定的抽象层。
❑需求的稳定性：高抽象层中需求(以及部分的体系结构决策)的定义独立于它们的技术实现。由于系统层中定义的需求完全独立于技术实现，因此它们通常不会受到技术实现改变的影响，即构件层的改变。
❑可追踪性和依据：在较低抽象层中定义的需求可以关联到在较高抽象层中定义的需求。因此，在较低抽象层中定义的需求可以反向追溯到更高层次的需求。在较高抽象层中定义的需求为较低抽象层中的需求提供了依据。
34.2需求和体系结构制品的协同开发
必须要完成两项不同的、但紧密关联的任务:
❑需求的具体化：需求的具体化程度必须能足够地支持系统的实现以及所有开发制品的质量保证。
❑系统的分解：必须将整个系统分解为一组交互的部分(子系统或者构件)。必须定义一个具体的体系结构，以满足所定义的(具体)需求。
需求影响并部分决定着体系结构，设计决策强烈影响着基于特定高层需求的具体需求的定义
因此，所采取的设计选择明显影响着具体需求的开发。
一个新的体系结构方案甚至会导致全新的需求，也因此影响了更高抽象层中的需求定义。
34.2.1 体系结构对需求的影响
支持需求和体系结构交织开发的必要性
需求工程和体系结构设计过程是固有地交织在一起的。
具体化的需求经常会隐藏那些涉众在具体需求定义时所制定的隐式和显示的设计决策和假设。
一个开发方法应该促进和系统化支持需求和体系结构制品的交织开发，应该有助于：
❑需求和方案概念同时地和紧密交织地协同开发。
❑需求文档、方案概念、设计决策以及这些决策所产生的系统结构之间的清晰分离。
❑一种需求和体系结构制品之间的恰当的关联，从而支持制品的协同开发。
34.2.2协同设计过程
软件密集型系统可以根据抽象层的结构来构建。每一个抽象层同时包含需求和体系结构制品。
在每一个抽象层中，体系结构必须满足定义在这一层中的需求。
定义在较低层中的需求必须满足定义在较高层中的需求。
较低层中的体系结构满足定义在较高层中的体系结构。
图34-4 协同设计过程和抽象层
第35章 COSMOD-RE方法
COSMOD-RE方法概览
目标是支持软件密集型嵌入式系统的需求和体系结构制品的交织协同开发。
COSMOD-RE方法包括3个主要组件:
❑4层抽象层：系统层、功能分解层、硬件/软件分割层和部署层。
❑4种制品类型：目标、场景、面向方案的需求和体系结构制品。
❑3个协同设计过程：系统级别的协同设计、功能级别的协同设计和硬件/软件级别的协同设计。每一个协同设计过程关注两个相邻的抽象层。并包含5个子过程。
35.1 COSMOD-RE的4层抽象层
COSMOD-RE方法基于一个4层抽象层结构。
每一层都有一个良好定义的关注点，同时定义了一个特定的系统视角。
35.1.1 概览
图35-2描绘了COSMOD-RE方法的4层抽象层。从最高层到最底层，每一层以增加的细节程度定义了需求和体系结构制品：
❑系统层：系统层(最高抽象层)定义与实现技术和系统内部结构(分解)完全无关的需求和体系结构制品。关注点是系统在所处环境中的嵌入情况。
❑功能分解层：在功能分解层，系统被分解为粗粒度的逻辑组件。组件以及组件之间的关联和交互需求均在这一层中被定义。
❑硬件/软件分割层：系统被分解为硬件和软件组件。决定哪些系统属性使用硬件构件来实现，哪些属性通过软件构件来实现，关联和交互需求均在这一层中被定义。
❑部署层：系统到硬件/软件平台(物理单元的网络)的部署方案被定义。定义包括决定哪些软件构件运行在哪些物理单元上。
图35-2 COSMOD-RE方法的抽象层
图35-3 自顶向下、自内向外以及自底向上策略
35.1.2 系统层
系统层定义系统在所处环境中的嵌入情况、系统和环境之间的交互，以及系统的外部可见属性(关于功能和质量)。系统自身被看作一个黑盒。
系统需求
系统与其所处环境之间的交互以场景的方式被定义。系统的高层目标或者属性以目标的方式被定义。
使用面向方案的需求模型来详述。
系统体系结构(系统接口)
在系统层，系统被看作一个通过定义的接口与所处环境进行交互的黑盒。系统层定义的系统接口说明了系统在所处环境中的嵌入情况。
这些接口的定义与技术方案无关。
在体系结构模型中应该加入外部系统和参与者。
影响整个系统的设计约束可以在这一层中被说明。
35.1.3 功能分解层
关注点是系统的功能分解。系统被分解为逻辑组件或者构件。
每个逻辑构件都表示一个内聚功能的单元，被称作“功能构件”。
功能分解层中对需求和体系结构制品的定义独立于特定的实现技术。
功能构件的需求
在功能分解层，定义了每一个功能构件的需求(目标、场景、面向方案的需求)。
在定义功能构件的需求时，上一层定义的系统需求会被考虑。
在这一层中，功能构件的新需求也能够被抽取和定义。
逻辑(功能)体系结构
体系结构制品定义了系统的逻辑构件、逻辑接口以及构件之间的逻辑关联。
功能(逻辑)体系结构定义了问题的结构。
是除需求之外，在硬件和软件分割层定义一个更加具体的系统结构的一个关键输入。
也应该定义体系结构的质量需求。
35.1.4 硬件/软件分割层
定义了系统功能到硬件和软件构件的分割以及这些构件的需求。
硬件/软件接口(采用接口需求和粗粒度的接口设计的方式)在硬件/软件分割层中被定义。
硬件和软件需求
硬件/软件分割层的需求在功能分解层所描述的需求基础上被定义，同时它们与本层中的硬件和软件构件相关。
还有一些额外需求被抽取和定义，这些需求依赖于系统到硬件和软件构件所选的分解方式。
结构化的硬件和软件构件
系统分解会定义一个粗粒度的体系结构，包含硬件和软件构件、它们的接口，以及定义硬件和软件构件通信渠道的连接器。
会考虑典型的质量需求，如性能和成本。
只定义那些用来实现功能分解层中所定义功能构件的硬件和软件构件。
属于基础硬件和软件平台的硬件和软件构件不在硬件/软件分割层中定义。
在硬件/软件分割层也不将硬件和软件构件指定到具体的物理单元。
35.1.5 部署层
在部署层，硬件/软件分割层中定义的需求和体系结构制品被聚合。
基于项目的类型，以下3种情况中的一种将出现：
❑硬件和软件构件被部署在一个已有的物理单元的布局上，该布局已被定义并保持不变。
❑一个在部署期间被修改的已有物理单元布局。
❑创建一个全新的物理单元布局，没有使用已定义好的布局。
将硬件和软件构件部署到物理单元布局上时，会要求对硬件/软件分割层中定义的需求进行精化和调整。
可能有必要对一个需求进行修改。同样，可能要求对硬件和软件构件进行调整。
35.2 COSMOD-RE的4种制品类型
需求和体系结构制品在COSMOD-RE 4个抽象层的每一层中被定义。
每一个抽象层中区分了4种制品的基本类型：
❑目标;
❑场景;
❑面向方案的需求;
❑体系结构制品。
35.2.1 目标
并非从高层目标精化而得到的新目标能够在较低抽象层中被识别。
如果一个新的目标被识别，那么可能出现以下4种基本情况中的任何一种：
❑情况1:新的目标可以被关联到定义在较高抽象层中的一个超目标上。
❑情况2:新的目标指出了较高抽象层中的缺陷。在定义了之前被忽视的超目标后，这个新的目标被关联到这个超目标上。
❑情况3:新的目标不能被关联到定义在一个较高抽象层中的超目标，因为这个新目标和系统是不相关的。
❑情况4:新的目标不能被关联到定义在一个较高抽象层中的超目标，因为这个新目标是特定于较低抽象层的。
如果可能，在较低抽象层中识别的新目标应该与较高抽象层中定义的目标相统一。
也存在特定于抽象层的目标(情况4)。这些目标是和系统相关的，但是不能被关联到较高抽象层中的超目标上，因为在较高抽象层中定义相应的超目标会超出这个抽象层的范围。
依赖于特定系统分解的目标应该只在定义分解的抽象层中被定义。
与期望方案有关的限制应该被定义为明确的设计约束，同时不应在目标定义中被隐藏。
系统目标
系统目标涉及系统提供给它的外部参与者的功能和质量。
一个系统目标应该有助于发掘全局的系统愿景。系统愿景通常被精化为一组系统目标集合。
每一个目标应该使用一个目标模板对其进行更加详细的定义（目标模板：8.1）。
一个在系统层中被定义的目标可以被分配到系统或者一个外部参与者上。
功能构件目标
被定义在系统层的目标(称作终端目标)会在功能分解层中被精化为更细粒度的目标。
一个精化后的目标可以被分配到一个功能构件上。目标关联到特定的功能构件，构件就要负责满足这个目标。
如果所有被精化后的目标都被满足，那么终端系统目标也要同样地被满足。
可以抽取和文档化与系统目标无关的新功能构件目标。如果一个新的功能构件目标被识别，则会出现前文所提到的4种情况：（参考前文，此处略）
硬件/软件分割层
定义在功能分解层的终端目标在硬件/软件分割层中被精化为可以被分配到单独硬件或者软件构件上的子目标。定义在硬件/软件分割层的目标必须满足所定义的功能构件目标。
部署目标
当一个硬件/软件构件被分配到一个特定的物理单元上时，这个硬件/软件构件的操作环境就被确定了。
精化得到的目标将在部署层中被定义为特定于平台的目标。
35.2.2 场景
COSMOD-RE在系统层中使用交互场景,在较低抽象层中使用系统内部场景。
交互场景用来描述和分析发生在系统与外部参与者之间的交互，而系统内部场景定义了系统中构件之间的交互。
定义了系统和外部环境之间交互的系统场景在较低抽象层中被逐步精化。
当一个场景被精化时，系统被分解为一组构件集合。
在被精化的场景中，除了在较高抽象层的场景中所定义的交互之外，还要添加分解后得到的实例之间的交互。要求新的交互能实现那些定义在较高抽象层中的场景。
较高抽象层中的场景在较低抽象层中可以被精化为一个或多个场景。
在较低抽象层中，除了对定义在较高抽象层中的场景进行精化外，还可以识别额外的交互以及全新的场景。
如果一个新的场景在较低抽象层中被识别，那么会出现以下4种情况中的任何一种：
❑情况1:新的场景可以被关联到定义在较高抽象层中的一个场景上(精化)。
❑情况2:新的场景指出了较高抽象层中的一个缺失的场景。在定义了缺失的场景后，这两个场景使用“精化”关系进行关联。
❑情况3:新的场景不能被关联到一个在较高抽象层中定义的场景上，因为这个新的场景和系统是不相关的。
❑情况4:新的场景不能被关联到一个在较高抽象层中定义的场景上，因为这个新的场景是特定于较低抽象层的。
系统场景
系统场景被定义在系统层中，它关注系统和外部参与者之间的交互。
建议使用用况模板来抽取初始的系统场景集合并且文档化这些场景。被文档化的场景应使用顺序图进行详述。
使用顺序图详述场景能将焦点指引到场景中的参与者以及参与者之间的交互上。利于较低抽象层中的场景精化。
场景既要用来说明所需要的交互序列，同时也要用来说明不期望的和禁止的交互序列。
外部参与者(actor)的定义对系统层的场景具有决定性的影响。
既要保证系统所有必需的交互可以被捕获，同时也要忽略交互的技术细节。
功能构件场景
关注于功能构件之间逻辑交互的系统内部场景。
由于功能构件场景是在逻辑层面进行定义的，因此其中的交互定义应独立于可能的实现方式。
功能构件场景是基于定义在系统层的交互场景而被定义的。
一个功能构件场景应该表示功能构件之间一个典型的、线性的交互过程。
硬件/软件场景
硬件/软件场景关注于硬件和软件构件之间的交互，这些构件包括应用软件构件、传感器、传动器、计算设备、网络构件、人机界面设备等。
硬件/软件场景可以基于功能构件场景进行开发。
通常需要定义没有相对应功能构件场景的、特定于硬件/软件层的硬件/软件场景。
部署场景
部署场景定义已经被部署到特定硬件/软件平台上的硬件和软件构件之间的交互。
定义硬件/软件平台中单独的物理单元内的本地交互，也定义不同物理单元之间的远程交互。会考虑平台的特性。
35.2.3 面向方案的需求
具体化的需求包括诸如功能、数据、行为的功能需求，以及诸如性能、安全性或安全需求和约束的质量需求。
一个面向方案的需求制品的粒度和范围，取决于需求制品所在的抽象层。
影响整个系统的功能和质量需求被定义在系统层。
与单独功能构件相关的需求被定义在功能分解层。
硬件和软件构件的需求被定义在硬件/软件分割层。
在部署层物理单元的需求在上层的硬件和软件构件需求的定义基础上被定义。
出于简单性，这里主要关注于行为需求。基本概念可以简单地适用于所有其他类型的面向方案的需求。
系统需求
系统层的行为需求定义了系统的外部可见行为。
系统层的需求行为模型包含主要输入、主要输出和系统的主要状态。非常粗粒度的。
系统层的行为需求模型不应该包括系统内部行为的定义。
功能构件需求
在功能分解层，每一个功能构件的行为需求被定义。
使用自动机或者状态机来定义行为需求。
每一个状态机应该详述一个单独的功能构件的外部可见行为，状态机不应该定义功能构件的内部行为。
如果一个状态机过于复杂，那么很可能说明涉众定义了功能构件的内部细节。
硬件/软件需求
每一个单独硬件和软件构件的行为需求被定义。
专注于硬件和软件构件的外部可见行为旨在避免过早的设计决策。
软件和硬件构件的行为模型一起构成了一个相互通信的自动机(状态机)网络。
部署需求
通过将定义在硬件/软件分割层的硬件和软件构件连同其需求分配到物理单元上，来定义物理单元的行为需求。
同时也可以通过对基于分配到物理单元上的需求进行精化来实现对物理单元行为需求的定义。
35.2.4 体系结构制品
COSMOD-RE方法使用结构化的体系结构模型。
每一层体系结构构件的内部行为可以通过状态机行进详细定义。
结构化体系结构模型由构件、接口和连接器组成。
构件具有已定义的接口，并通过连接器与其他构件连接。
系统接口
系统层的结构化体系结构模型专注于系统在其所处的操作环境中的嵌入情况。
将系统建模为一个单独的黑盒构件，即系统不分解为子构件。
单独构件的接口定义了系统与环境之间，即系统和外部参与者之间(人或者系统)交互的位置。
一个复杂的软件密集型系统通常需要几种不同类型的接口。
系统层中体系结构模型所定义的接口是逻辑接口，即它们实现系统和环境之间的逻辑(实质)交互。
功能体系结构
系统功能体系结构定义了系统到一组逻辑、功能构件的分解。
功能体系结构定义了系统的一个逻辑的、本质的体系结构模型。
功能构件具有良好定义的接口，通过接口构件可以同其他功能构件或外部参与者(人或系统)进行交互。
连接器表示两个或多个构件之间的逻辑连接。
通过连接器和相应的分配到连接器的接口，功能构件可进行数据和/或控制信号的交换。
功能构件和连接器可能会被层次化地分解为子构件和子连接器。
分解得到的子构件和子连接器的定义必须仍然是独立于实现技术。
硬件/软件体系结构
硬件/软件分割层中的体系结构模型定义了系统到硬件和软件构件的分解。
硬件/软件连接器表示硬件和软件构件之间的连接。
为进一步降低硬件/软件分割层中模型的复杂性，技术方面的具体细节不应该在这一层中被定义。
一个功能构件可以通过几个硬件或者软件构件来实现，反之亦然，一个硬件或者软件构件可以实现多个定义在功能分解层的功能构件的功能。
部署体系结构
物理单元拥有(物理)接口，通过(物理)通信频道相互连接。
所得到的物理单元配置、它们的接口和通信频道被称作系统布局。
每一个物理单元拥有它自己的软件设施，由诸如操作系统和设备驱动等组成。
系统布局和物理单元的软件设施构成了系统的硬件/软件平台。
硬件/软件体系结构和部署体系结构之间的关联必须被相应地文档化。
35.2.5 制品之间的关联
目标和场景之间的关联
定义在特定抽象层中的每一个(终端)目标必须至少与这一层中的一个具体化了该目标的场景相关联。
定义在这一层中的目标可以被用来帮助该层场景的抽取和确认。
目标/场景和面向方案的需求之间的关联
场景连同与其关联的目标有助于在每一个抽象层中对面向方案的需求的识别和定义。
可以从每一个目标和相关联的场景中得到几个(具体的)面向方案的需求。
目标和场景可以被用来确认每一层中的面向方案的需求。
禁止的、负面的场景应该被排除在面向方案的需求之外。
目标和体系结构之间的关联
目标的分解和系统构件的分解是相互交织的。
可以使用OR分解来表示目标的可选分解，这种分解与系统的不同分解相关。
各个抽象层次上定义的目标还可以支持体系结构评估。
场景和体系结构之间的关联
该层中的场景定义可以支持构件、构件接口和构件间连接的识别和定义。
反之亦然，在特定抽象层中定义的(草拟的)体系结构会影响这一层中场景的定义。
场景也可以被用来探索、确认和改善体系结构的草案。
在每一层，场景的定义和体系结构的开发通常是相互交织的。
35.3 COSMOD-RE的协同设计过程
COSMOD-RE提供3个独立的协同设计过程，这些设计过程构建了跨越4个抽象层次的开发过程。
35.3.1 概览
每一个协同设计过程主要关注两个抽象层次。
每一个协同设计过程在一个特定的抽象层中都与另一个协同设计过程存在部分的重叠。
可简要概括为：
❑功能级协同设计:功能构件需求的定义以及初始的硬件/软件分割。
❑硬件/软件级协同设计:定义硬件/软件需求，以及硬件/软件构件到硬件/软件平台的初始部署。
每一个协同设计过程都支持需求和体系结构制品的交织开发。
如果协同设计过程是被不同的小组、部门或组织执行，不同的协同设计过程可能会被(部分)并行执行。功能级协同设计过程的多个实例也可以并行执行。
35.3.2 系统级协同设计
系统级协同设计过程的目标是系统层需求制品和功能分解层体系结构制品的协同开发。
因而，系统级协同设计过程的关键结果包括系统层的所有制品类型以及功能分解层的部分制品。
35.3.3功能级协同设计
功能级协同设计过程的目标是功能分解层需求制品和硬件/软件分割层体系结构制品的协同开发。
在系统级协同设计过程中所开发的一个初始功能体系结构、初始功能构件目标和初始功能构件场景是可用的。这些制品在功能级协同设计时被扩展和调整。
功能级协同设计过程在功能分解层的结果包括：已修订、补全的功能构件目标和场景、面向方案的功能构件需求，以及修订后的功能体系结构。
在硬件/软件分割层，开发初始的、初级的硬件/软件目标、场景以及一个初始的硬件/软件体系结构。
35.3.4 硬件/软件级协同设计
硬件/软件级协同设计过程的目标是硬件/软件层需求制品和部署层体系结构制品的协同开发。
该协同设计过程的关键结果是为每一个硬件和软件构件定义的，经过调整和扩展的硬件/软件目标、场景和面向方案的硬件/软件需求，以及硬件和软件构件到硬件/软件平台中物理单元的一个初始的、初级的部署。
35.3.5 协同设计过程之间的重叠
重叠的原因是，前一个协同设计过程的输出明显作为后一个协同设计过程的输入。
35.4 每一个协同设计过程的5个子过程
COSMOD-RE为每一个协同设计过程提供了5个相互关联的子过程，由此在每一个协同开发过程中构造了需求和体系结构制品之间的协同开发。
35.4.1 概览
图35-17包括输入、主要信息流和关键结果的子过程的概览
35.4.2 开发初始目标和场景(SP₁)
目标是开发系统的初始目标和初始场景。
过程初始阶段，该子过程的输入通常是系统的愿景以及涉众对于类似系统的经验和知识。
之后的过程中，已定义的目标和场景作为输入。输出是一组(新的或扩展的)系统使用场景和系统目标。
系统目标表示为了实现系统愿景所需的系统关键属性。
系统(使用)场景则文档化系统和外部参与者之间典型的交互序列，以实现系统目标。
目标和场景的开发是一个迭代的过程，其中场景会引起新目标的定义，目标会引起新场景的定义。
目标和场景的抽取和文档化过程应该持续进行，直到获得一组足够稳定的目标和场景。
足够稳定的目标和场景应该用适当的模型进行描述。
应该使用一种目标建模语言对目标及其之间的关联进行文档化。
应该使用一种模型语言对每一个用况场景进行文档化。
应该创建一个或多个用况图来提供系统用况的概览。
目标模板
表35-1 COSMOD-RE方法使用的目标模板
| 目标[ID] | [目标的简短名称] |
| 抽象层 | [目标定义所在的抽象层的名称] |
| 范围 | [目标定义的系统或者构件的名称] |
| 目标分类 | [软目标或者硬目标] |
| 目标描述 | [使用自然语言对目标的精确描述] |
| 目标责任 | [负责满足这一目标的主体的名称] |
| 超目标 | [对精化出该目标的目标的引用以及精化类型] |
| 子目标 | [对精化该目标的目标的引用以及精化类型] |
| 冲突目标 | [对与该目标发生冲突的目标的引用] |
| 相关场景 | [对文档化实现这一目标的场景的引用] |
用况模板
表35-2 COSMOD-RE方法使用的用况模板
| 用况[ID] | [用况的简短名称] |
| 抽象层 | [用况定义所在的抽象层] |
| 范围 | [用况记录的交互主体，即系统或者构件的名称] |
| 主要参与者 | [以执行这一用况为实现目标的参与者的名称] |
| 次要参与者 | [其他参与者，即该用况涉及的人、系统、构件、设备等] |
| 输入和输出变量 | 输入：[在执行用况过程中，其值被度量或读取的外部变量的名称] 输出：[在执行用况过程中，其值被改变或影响的外部变量的名称] |
| 相关目标 | [对执行这一用况所能实现的目标的应用] |
| 前置条件 | [用况执行前，系统/构件或者外部环境必须保证的条件] |
| 成功保证 | [用况成功执行后，系统/构件或者外部环境必须保证的条件] |
| 最小保证 | [在用况执行后，不论成功或者失败，系统/构件或者外部环境必须保证的条件] |
| 扩展点 | [该用况被其他用况扩展或包含其他用况的位置，即用况场景的步骤] |
| 触发器 | [触发用况的事件，如系统事件、时间事件或者外部事件] |
| 主要场景 | 步骤 动作 |
| 可选场景 | 步骤 动作 |
| 失败场景 | 步骤 动作 |
| 技术和数据变体 | [对执行用况场景中单独步骤的可选实现方案的描述] |
| 特殊需求 | [对用况场景中单独步骤或者整个用况的质量需求或者约束的描述] |
35.4.3 开发初始体系结构(SP₂)
目标是开发预期系统的一个初始体系结构。子过程探索并评估可能的体系结构方案(即系统概念)。
输入包括系统愿景、已知的需求(目标和场景)以及现有的/已知的系统概念。
输出是一个主要由粗粒度的、可能是部分的体系结构所组成的方案概念(见图35-17)。
系统级协同设计过程所创建的体系结构设计包含两个部分：
系统接口(即系统到它所处操作环境的嵌入情况)和一个初始的、粗粒度的系统功能体系结构。
功能体系结构应该反映出所选择的系统概念。
推荐使用一种系统描述语言(ADL)对体系结构进行文档化。
应该能支持对构件、接口和连接器的建模。
35.4.4 开发构件目标和场景(SP₃)
旨在获取功能体系结构中每一个功能构件的初始需求，以发现(系统)需求和功能体系结构之间的不匹配情况。
SP₃的输入是子过程SP₁和SP₂执行后的结果，即已定义的系统目标和系统场景，以及初始的功能体系结构。
主要包括3个迭代执行的活动：
❑责任分配：将系统目标和场景步骤的责任分配到体系结构元素上。
❑精化：活动基于较高抽象层中的目标和场景为单独的体系结构元素定义相应的目标与场景。
需求(即所定义的目标和场景)和体系结构之间的比较具有以下两个主要目标：
❑确认体系结构是否足够好地支持了系统目标和场景。
❑基于所提出的系统体系结构识别新的系统目标和系统场景的概念。
需求和体系结构之间的比较揭示了体系结构没有记录的目标和场景以及体系结构方案。
目标精化
旨在识别功能构件层的子目标，这些子目标能实现最终的系统目标并能分配给功能体系结构中的单独功能构件。
迭代地执行下面的步骤：
❑步骤1:识别实现相应目标所需要的功能构件。
❑步骤2:如果为了实现相应的目标，多个构件必须协作，那么将该目标分解为几个子目标，每个子目标可以被更少的功能构件实现。
❑步骤3:用一个分解关系将步骤2得到的子目标与超目标连接。对每一个子目标持续进行步骤2,直到每一个得到的子目标都可以单一地被分配到某一功能构件上。
如果两个或多个最终系统目标的子目标发生重叠，相应的子目标应该被调整。
构件的目标分配可以帮助揭示目标模型和体系结构模型中的潜在问题。如：
❑一个相关目标的精化结果不能被分配到任何一个构件上。这种情况说明缺少了一个构件，或者这个目标是多余的。
❑在所有系统目标被精化后，一些构件没有分配到目标。这种情况说明缺失了一个或多个目标，或者构件是多余的。
❑一个构件负责实现所有或者大部分子目标。说明这个构件是一个“热点”,可能会在实现和测试期间造成困难。应该考虑改变设计(如将该构件分解为几个构件)或者重新分配责任。
❑一个目标已经被分配到了一个构件上，这个构件不能完全实现这个目标。分析：为了实现该目标必需修改哪些体系结构和需求。
过程期间，应记录发现的问题、建议的扩展和改变，以及关于目标模型和体系结构模型的想法。
场景精化
可通过以下步骤实现：
❑步骤1:识别负责实现相应系统场景的功能构件。
❑步骤2:将系统场景定义的每一个场景步骤(即每一个系统-参与者-交互)分配到一个功能构件上。
❑步骤3:通过在功能构件之间添加要求的、系统内部的交互来完成精化。
责任分配是在步骤1和步骤2中执行的。
步骤1执行了一个粗粒度的分配，即全部场景被分配到了体系结构构件集合中。
步骤2以一个更合适的粒度进行责任分配，即单独场景步骤被分配到了单独构件上。
**注：场景精华的实际任务是将场景的每个步骤的实现部分，分配到每个功能构件上，这个动作是用以表达实际功能构建对应的场景中的步骤部分。进一步精化过程中，以添加功能构件之间的交互，来实现场景步骤之间的交互过程，实际上在功能构件的基础上，完成交互动作的开发。
系统场景的精化能帮助发现初始场景和初始体系结构中的不足。如：
❑体系结构中定义的一个构件与其他构件或者环境没有交互。这种情况表明该构件是多余的，或者相关的场景、某一场景中的交互或者构件接口没有被考虑到。
❑两个或多个构件根据体系结构模型相互连接，然而却没有场景定义了这些构件的交互。这种情况说明体系结构中存在多余的接口和连接，或者存在缺失的场景和交互。
❑一个构件根据体系结构模型要求与另一个模型交互，这两个构件却没有相互连接。这种情况说明在体系结构中存在缺失的接口和连接，或者存在多余的场景和交互。
过程期间，应该文档化识别的问题、建议以及关于场景和体系结构的想法。
35.4.5 整合需求和体系结构制品(SP₄)
目标是基于子过程SP₃比较的结果来协调需求和体系结构。
子过程的输出是一个经过调整的目标、场景以及体系结构制品的集合。
必需执行的活动：
❑已提出变更的调整和优先级排列。
❑目标、场景和体系结构的调整。
已提出变更的调整和优先级排列
先评估SP₃得到的问题、建议和想法。
建议将提出的变更分为两类，并按其类型进行处理：
❑必须与涉众进行协商的变更；
❑不用协商就可集成的变更。
对于重大的变更，应该执行一个成本-价值分析，每一个(主要的)变更根据其对整个系统愿景的贡献和它对(开发或者生产)花费的影响进行优先级排序。
目标、场景和体系结构的调整
每一个批准的改变被引入到目标、场景和体系结构中
应该注意变更应该一致地集成到所有被这一变更影响的制品中。
每一个对系统目标、系统场景或者系统接口(即系统层的制品)的变更必然导致功能分解层进一步的改变。反之亦然。最初发生在功能分解层制品上的变更如果影响到了系统层方面，也可能导致系统层的改变。
抽象层内和跨抽象层的不同制品之间关系必须被一致地调整。
在子过程SP₄每一个主要的需求和体系结构修正之后，应该以子过程SP₄的结果作为输入重新执行子过程SP₃,这有助于发现更多的或新引入的不一致以及新想法的产生。这两个子过程持续迭代，直到制品足够统一与稳定。
35.4.6 详述具体的系统需求(SP₅)
基于SP₁～SP₄开发和统一的系统目标、系统场景和功能分解，定义面向方案的系统需求。
输入包括通过子过程SP₃和SP₄的迭代得到的已经相当稳定的目标、场景和体系结构。
结果是通过文本的需求或模型的方式而被文档化的具体的(面向方案的)系统需求(即功能需求、质量需求和约束)。
这些具体的需求是进一步开发活动，如功能级协同设计过程的基础。
第36章 实施COSMOD-RE方法：一个实例
**注：使用系统级协调设计过程进行实例展示，主要涉及的层包括系统层和初步的功能层。
36.1 开发初始目标和场景（SP1）
在子过程SP₁中，开发系统的初始目标和场景。
系统目标
记录了定义在系统层的一组目标以及这些目标之间的关系。
模型中只显示了目标的名称。另外，每一个目标都具有一个描述，该描述用来具体解释该目标。
每一个目标都会用目标模板进行详细描述。
在定义了这组初始的目标集合，文档化每一个目标之后，系统场景被开发出来用以说明这些目标的实现。
另外，场景的开发可以导致额外目标的识别或者对已识别系统目标的精化。
系统场景
描绘基于初始系统目标中被抽取出的初始场景(用况)集合。
用况图展示了系统边界、外部参与者、初始的用况集合以及外部参与者和用况之间的联系。
通过分析初始的系统目标和系统环境，可识别出外部参与者。
系统定义的系统目标的实现是通过用况来描述的，用况定义了系统和它的外部参与者之间所需的交互。
可使用用况模板详细地定义每一个用况。
为了降低复杂性，一开始，只定义了用况的主要场景。
36.2 开发初始体系结构（SP2）
定义系统接口和系统初始的功能体系结构。
系统接口
定义的系统接口表示系统与外部环境交换信息、能力或材料的逻辑位置。
需要分析系统目标和系统场景(即系统用况)。
通常，每一个系统接口需要满足一个系统目标或者实现一个定义在场景中的交互。
另外，通过考虑系统的外部参与者能够识别系统接口。
功能体系结构
功能体系结构定义了系统必需的功能(逻辑)构件以及这些构件的逻辑接口和逻辑连接。
初步的构件连接可以基于构件之间的相互依赖来定义。
然而，这些连接需要在功能构件目标和场景的帮助下被检查和调整。
36.3 开发构件目标和场景（SP3）
基于系统目标、系统场景和初始功能体系结构定义了功能分解层的初始目标和场景。通过将功能构件目标和场景指派到功能体系结构中的元素涉众可以发现不一致的情况，并提出对目标、场景和体系结构的修改建议。
功能构件目标
精化系统初始目标，分解目标。
分配目标到初始构件上。
功能构件场景
建议将用况场景转变为顺序图或消息顺序图表。
36.4整合需求和体系结构制品（SP4）
涉众对子过程SP₃中所提出的变更进行评价、整合和优先级排序。被批准的变更被一致地集成到系统层和功能分解层的目标、场景和体系结构模型中。
目标和场景的调整
体系结构的调整
36.5 详述具体的系统需求（SP5）
系统目标、系统场景和功能体系结构被整合并由此达到足够的稳定性后，可定义系统的具体的面向方案的需求。
❑系统目标和系统场景已经与功能体系结构相统一。
❑在定义面向方案的行为需求时，功能体系结构能够简化对系统状态和事件的识别，这些状态和事件必须在行为模型中被详述。
36.6 总结
COSMOD-RE方法提出了一个具有四个基本抽象层的层次结构，用以构建系统和系统的需求。每一个抽象层应针对系统不同的关注点，并使用目标、场景和面向方案的需求制品来定义需求。另外，为了澄清每个抽象层中需求的范围，并且支持层次之间的过渡，该方法使用了结构化的体系结构模型。
表36-5 COSMOD-RE制品的简要说明
| 层次 | 目标 | 场景 | 面向方案的需求 | 结构化的体系结构 |
| 系统层(L₁) | 系统目标 | 系统和外部参与者之间的交互 | 系统所需的功能、数据、行为和质量 | 系统接口 |
| 功能分解层(L₂) | 每个单独功能构件的目标 | 系统功能构件与环境之间的交互 | 每一个功能构件所需的功能、数据、行为和质量 | 系统的功能分解，包括逻辑组件、接口和逻辑连接 |
| 硬件/软件分割层(L₃) | 每个单独软件构件的目标 | 软件和硬件构件与环境之间的交互(独立于部署) | 每一个软件构件所需的功能、数据、行为和质量 | 系统到硬件和软件构件的分解 |
| 部署层(L₄) | 部署目标 | 特定于平台的交互 | 每一个软件构件的特定于平台的功能、数据、行为和质量 | 硬件和软件构件到一个特定硬件/软件平台的映射 |