继续梳理这段时间看到的最乏味的文档，《AUTOSAR_TR_Methodology》。
活动的定义
在 SPEM 元模型中，活动是定义流程的主要构建块。 活动通常是定义的任务或要完成的工作，通常按一个顺序执行。
活动构成
活动可以包括其他活动，因此经常分解工作流并显示哪个活动先于其他活动。 在最低级别，活动是工作分解元素的集合，在 AUTOSAR 方法中是任务、角色和工作产物。
流程的定义
流程是 SPEM 元模型中的一项特殊活动，它描述了开发项目或其部分的典型结构。 流程侧重于分解结构中的生命周期和工作顺序。 流程包含任务和活动的序列，从而表达正在开发的产品的生命周期。 流程还通过定义工作、操作或事件的顺序来定义如何从一个里程碑到达下一个里程碑。
对于 AUTOSAR 方法，主要用例用 3 种类型的图表进行描述。
整体用例描述
在第一个图中，能力模式、活动和可交付成果用于描述整体用例、活动序列及其主要输出（可交付成果）。 在这些图中，可以跳过前趋关系，并且可以通过其他可交付成果扩展可交付成果（见图 1.8）。
该图后面是其相应的表格，详述如上面截图。
用例的精确描述
第二种类型的图是活动和任务定义图，它精确地描述了用于用例的主要任务和工作产品，但不像方法库中那样详细（见图 1.9）。 这些图中的任务使用将由角色和聚合处的注释来表示。 此信息也将在生成的表中可见。 用例中消耗或产生的工作产品不会集成到表格中以提高可读性。
该图后面是其相应的表格，详述如下：
工作流程的详细描述
第三种类型的图表包含活动使用的任务和工作产品，以显示详细的工作流程，而不是活动的结构，如第 1.5.1.1 节所示。 以图 2.9 为例。 没有为这种类型的图表完成表格生成。
这个活动的表达还是蛮复杂的。
继续往下是需求跟踪矩阵。
这个直白的翻译不是需求跟踪矩阵，但是正好跟我接触的CMMI中的需求跟踪矩阵应该是同一个事情。而接下来是一长串的跟踪表，我这边放一个例子，直接翻过了。
一些输入需求不能（或不完全）追溯到本文档中的单个规范项目。 他们由 AUTOSAR 方法论以及以下列出的其他文件满足：
一致性需求的定义
AUTOSAR 方法支持隐式通信行为描述的交换。 第 3.4.1.14 和 3.4.2.15 章描述了允许定义相应一致性需求的任务和工件。
建立AUTOSAR方法论的文档
所有与 AUTOSAR 方法相关的模型元素（参见 1.5）都由内部 AUTOSAR 工具使用，该工具自动生成相应的文本、表格和图表。 这些工件包含在一个文档中，该文档会自动转换为最终的 PDF 文件。
难道我现在看到的文档就是通过这种方式来生成的？？
AUTOSAR工作产物之间的关系
工作产品（交付物和工件）的设计方式使得不存在与其他工作产品的循环引用。
这个其实是前面看到过的一个原则。
外部工件（或者产物）的可追溯性
Methodology 模型中考虑的工件包括外部工件，如 c 代码、库、文档和生成的工件（参见例如 3.5.2.22、3.4.2.4）。 通用非 Autosar 工件是非 AUTOSAR 工件的通用表示。 它由 General Deliverable 聚合，并允许在 AUTOSAR 上下文中链接和跟踪非 AUTOSAR 工件。 此外，一些特定的工件代表非 AUTOSAR 元素或允许引用它们。 A2L 文件工件是由 ASAM 定义的测量和校准格式的表示，因此超出了 AUTOSAR 的范围。 原子软件组件实现工件的描述解释了如何从此 ARXML 工件引用外部工件。
虽然，这个软件架构用到了XCP，但是并没有对A2L有所要求。
工作产物的文档
为了在开发过程中记录设计决策或限制，每个工作产品可以聚合由通用文档工件表示的相应文档。 通过处理添加通用文档任务，通用文档工件被添加到工作产品中。
这个难啃的文档，终于草草过完了第一个章节。跨越的页数还不到总页数的十分之一。我在看的过程中一直在考虑页数，又一直从脑子里冒出来一个声音叫停。脑子里冒出来的是：子曰：“吾尝终日不食，终夜不寝，以思。无益，不如学也。”其实，考虑太多空洞的东西终究还是无用的，不如学一点有用的信息。还是一点点，脚踏实地看下去吧！
