我们可以在所有涉众出席的一个（或多个）会议上填写职责矩阵。这使其成为每个人都同意的联合工作。
    我们不需要对业务有很多的了解来支持职责矩阵的创建。
    职责矩阵可以被用来作为开发案例的一部分，以非常简洁且易读的方式提供对所剪裁的 RUP 的主要构建模块的概述。

    填写职责矩阵

    职责矩阵可以通过不同的方法填写。我们将看一看其中的三种。

    策略 1：从 100% RUP 开始

    通常的起始点是一组标准的 RUP 工件和角色。RUP 顾问对组织中需要什么 RUP 工件和角色进行有根据的推测，并填写职责矩阵中的所有职责。该职责矩阵随后用作与涉众进行讨论的基础。

    然而，该方法有两个不利方面：

    与公司经验不相关。职责矩阵没有使用涉众熟悉的角色和工件。
    从涉众的观点出发，RUP 引入了所有的新词汇。因此职责矩阵很难让人理解。这各问题可以通过给人们具体的 RUP 培训，按照开发案例来剪裁来解决。

    策略 2：从中间开始

    在此策略中，RUP 顾问提供一个合理的工件及角色集合，如果需要的话，包括一些具体公司的工件和角色，并将这些填写在职责矩阵中。但不填写交叉部分。RUP 顾问应该设法使所有公司特有的工件和角色不覆盖已经在 RUP 中确定的内容。在对工件和角色进行解释之后，可以将它们移动、重命名或替换，并且通过完成职责矩阵将职责进行划分。

    公司特有的工件和角色的使用，以及涉众选择其职责的事实，使从其中识别新的开发案例更加容易。然而，该方法也有一个不利方面：

    提供工件和角色的合理集合需要业务知识。这意味着 RUP 顾问不得不花时间学习业务知识。

    策略 3：从零开始

    我们喜欢“从零开始”的策略。RUP 顾问从调查会议开始，在这个过程中，公司中所有的涉众都会出席。在该会议中，将讨论公司中存在的工件和角色，并放入到职责矩阵中。还应该讨论为什么使用某个工件或角色的理由。通常，当参与者说明现有的工件和角色的意图时，在被识别出的角色和工件中的差别、重叠和不一致的地方将会出现活跃的讨论。在此情境下，RUP 顾问扮演者中介的角色，接受涉众提出的角色和工件，并试图找出相应的 RUP 角色和工件。涉众最终同意每个角色和工件是至关重要的。

    此方法的优点是涉众（RUP 的外行）可以从熟悉的工件和角色开始，并且可以互相并对 RUP 顾问清楚地说明他们的意图。RUP 顾问（业务的外行）而后可以使用他或她的 RUP 知识，在可能的地方转化涉众对 RUP 的输入，并且识别出应该被保留的公司特有的角色和工件。

    RUP 拥有许多详细的角色和工件。扩展或减少 RUP 工件的内容来满足公司的需要可能是有用的。将若干角色的职责联合为一个角色，或将许多现有的角色中的一个 RUP 角色的职责分开也是可能的。例如，RUP 有一个管理员角色，系统管理员。在许多公司中，该角色分为两个：一个负责硬件和操作系统，而另一个负责管理应用程序。

    在创建职责矩阵的过程中，将新的职责矩阵中的工件和角色映射到公司的原始职责设置是有用的。这将帮助人们将在新的 RUP 方法中期望他们做什么，与他们当前的工作联系起来。

    该方法的结果是尽可能多地确定了 RUP 角色和工件的职责矩阵。这意味着每个团队成员都可以利用大量的 RUP 文档来获得对新方法的更好了解。同时，有一些 RUP 知识的新的团队成员可以快速地找到他们在项目中的路标。然而，与此同时，职责矩阵根深蒂固的来源于公司的现有非常好的实践。

    一旦对要使用哪些角色和工件，以及如何称呼它们达成了一致，RUP 顾问就可以继续在职责矩阵中分配职责了。通常，我们在一个单独的会议中做这件事。每个工件应该至少有一个给予了“写”职责（W）的角色（实际的作者），而大多数工件同时要收到贡献/审阅的职责（C）。此外，一些工件必须正式地被接受（A）。参见图 1 的实例。