系统考虑

    系统工程师完成功能分析、功能分解和功能分配工作(当综合一项设计时)，但是功能并不是系统构架的唯一驱动因素，一个专门的工程师团队就能够在评估不同的设计方面做出贡献。IEEE Std 1220，系统工程过程的应用和管理标准(Standard for Application and Management of the Systems Engineering Process)在 6.3 节中描述了功能分解的使用，功能分析(Functional Analysis)在 6.3.1 节，功能分解(Functional Decomposition)，和系统产品解决方案等综合在 6.5 节中。6.5.1 节包含了一些特别有趣的内容，分组(Group)功能和分配(Allocate)功能，6.5.2 节是物理解决方案的选择(Physical Solution Alternatives)。在 6.3.1 节中指出，分解是用来清晰地理解系统必须完成哪些功能，并且一般情况下一层分解就足够了。

    注意，功能分解的目的并不是为系统定型(由综合工作来来完成定型)，而是理解和沟通系统必须完成什么――功能模型是能够完成这些的好的方式。在综合中，子功能首先被分配给解决方案的结构，然后评估这个解决方案――必须考虑所有的需求。这种方法和多层功能分解之间的不同之处在于：在每一层都试图描绘所要求的行为，并且在决定是否该行为在下一层需要被精化，以及分配到更低层的组件中之前，找到一种解决方案来实现它 。

    从中可以得出一个结论就是，在任何层次上使用数百个用例来描述行为是没有必要的。可能很少量的外部用例(和相关场景)就能够恰当地覆盖所要描述的对象(系统、子系统、类)的行为。我应该讲一下我所说的外部用例是指什么。举一个由子系统组成的系统例子，这些子系统又由类组成。描述系统及其参与者的用例，我称之为外部用例。子系统或许有它们自己的用例――它们对于系统来说是内部用例，但是对于子系统来说是外部用例。最终用来构建一个庞大系统(大于 100 万行代码)的外部用例和内部用例的总数，可能数以百计，因为这样规模的系统将包含其它系统，或者至少包含子系统。

    对结构和规模的假定

    用例的数量

    在 IBM Rational 中，我们认为用例的数量应该很小(10-50 个)，并且认识到大量(超过100 个)的用例表明可能需要进行功能分解，在功能分解中用例对于参与者毫无价值。然而，在实际项目中我们仍然能够发现大量的用例，并不总是"糟糕的"，至少在层次上是全面的。例如，在 Rational 内部的电子邮件中，作者引用了一个 Ericsson 例子：

    Ericsson，对大部分的新一代电话交换机的建模，估计要多于 600 个人年(最多，3 到400 个开发人员)，200 个用例(使用不止一层用例，请参考"互连系统构成的系统")对于一个超过 600 人年(这有多大呢?150万行 C++ 代码吗?)的系统，恐怕用例分析会限于子系统上面的某一层上(也就是说，如果一个人定义了一个 7000 到 10000 行代码的子系统)，否则用例的数量还会增加。

    因此，我仍然强调这种观点即少量的外部用例是适合的。为了匹配我曾经建议的结构和规格，我断言 10 个外部用例，每个用例带有 30 个相关场景 ，这对于描述行为是合适的 。如果实际中用例的数量超过了 10 个，并且确实是外部用例，那么它们所描述的系统要比相应的规范系统具有更大规模。在下文中我将提供一些支持理由来说明这些数字是合理的。

    结构分层

    建议的结构分层如下：

    4 - 多个系统组成的系统

    3 - 系统

    2 - 子系统组

    1 - 子系统

    0 - 类

    类和子系统在 UML 中定义为;在 UML 中更大的聚合是子系统(包含子系统)，为了更简单的进行描述，我进行了不同的命名。对于那些知道 2167 和 498 军方标准(称子系统为 CSC，称类为 CSU)中的术语的人来说，子系统组(subsystemGroup)的规模用 CSCI -来表示。我记得，经过 2167 天的关于 Ada 的结构应该映射到哪一层次的争论后，尘埃落定，Ada 包通常映射为 CSU。我并不建议系统必须严格的遵循这种层次结构，还将存在层次之间的混合，这种层次结构使我能够更好地了解规模对于每个用例工作量的影响。

    在每一层上都会有用例(尽管对于单个的类可能不是这样)，但并不是单纯的大量细节堆砌 ，而是用例针对那个层上的每个组件(例如子系统、子系统组，等等)。在上文中我曾断言对于每一层的每一个组件都有 10 个用例――如果用例的描述平均是 10 页，那么将会给出一个潜在的、大约 100 页长度的说明文档(还要加上类似的或者少一些的关于非系统性需求的相应说明)，这是 Stevens 98 提倡的数字，并且和Royce98推荐的数字很接近。但是为什么是 10 个用例呢?为了得出这个数字，基于对每一个子系统的类的数量、类的规模、操作规模等等我认为的合理的规模，我进行了自下向上的推理。这些和其他假设共同搜集在下表中供大家引用。

  

    我没有大量的经验数据-贯穿文中的是琐碎的、分散的数据，Lorentz 94 和 Henderson-Sellers 96 有一些数据，我也有一些在澳大利亚的项目中得出的数据，主要是在军用航空航空领域。任何情况下，在这个阶段，将框架或多或少的定位到合适的位置是非常重要的。