類和子系統在 UML 中定義為；在 UML 中更大的聚合是子系統（包含子系統），為了更簡單的進行描述，我進行了不同的命名。對于那些知道 2167 和 498 軍方標準（稱子系統為 CSC，稱類為 CSU）中的術語的人來說，子系統組（subsystemGroup）的規模用 CSCI -來表示。我記得，經過 2167 天的關于 Ada 的結構應該映射到哪一層次的爭論后，塵埃落定，Ada 包通常映射為 CSU。我并不建議系統必須嚴格的遵循這種層次結構，還將存在層次之間的混合，這種層次結構使我能夠更好地了解規模對于每個用例工作量的影響。
在每一層上都會有用例（盡管對于單個的類可能不是這樣），但并不是單純的大量細節堆砌 ，而是用例針對那個層上的每個組件（例如子系統、子系統組，等等）。在上文中我曾斷言對于每一層的每一個組件都有 10 個用例――如果用例的描述平均是 10 頁，那么將會給出一個潛在的、大約 100 頁長度的說明文檔（還要加上類似的或者少一些的關于非系統性需求的相應說明），這是 Stevens 98 提倡的數字，并且和Royce98推薦的數字很接近。但是為什么是 10 個用例呢？為了得出這個數字，基于對每一個子系統的類的數量、類的規模、操作規模等等我認為的合理的規模，我進行了自下向上的推理。這些和其他假設共同搜集在下表中供大家引用。
我沒有大量的經驗數據－貫穿文中的是瑣碎的、分散的數據，Lorentz 94 和 Henderson-Sellers 96 有一些數據，我也有一些在澳大利亞的項目中得出的數據，主要是在軍用航空航空領域。任何情況下，在這個階段，將框架或多或少的定位到合適的位置是非常重要的。
分層結構中組件的大小
這里我應該指出的是，我曾經使用代碼行來度量組件的大小，但許多人不喜歡這種度量。這些是 C++（或者相同層次的語言）代碼行，所以，要回到功能點非常容易。
在容器中的類的數目和能表達的行為的豐富性之間肯定有許多關系。我選擇了 8 個類/子系統 ，8 個子系統/子系統組，8 個子系統組/子系統，等等。那么為什么是 8 個呢？
1. 它在 7 或－2 之間；
2. 由于每個類有 850 slocs（每 70 slocs 有 12 個操作）的 C++代碼，它得出了一個子系統的規模是 7000 slocs－一個可以由小的團隊（3－7人）在 4－9 個月能夠交付的功能/代碼的程序塊，其中系統的迭代長度該調整到 30 萬－100 萬slocs (RUP 99) 的范圍內 。
那么，多少用例能夠表達八個類的行為（外部的）？，哪些是屬于子系統的并且已經被定位在子系統中了？決定豐富性的原因不僅僅是用例的數量，還有每個用例的場景數量。現在，并沒有多少方法來指導場景/用例擴展――在Booch 98中，Grady Booch 指出"存在一個從用例到場景的"膨脹系統"，一個復雜度適當的系統中可能有幾十個用于捕獲系統行為的用例，每個用例可能具有幾十個場景…."，Bruce Powel Douglass 在 Douglass 99 中指出，"….為了詳細描述用例需要很多場景，通常需要1打到幾打"。我選擇了 30 個場景/用例――這處于"幾打"的較低的一邊，但是 Rechtin（在 Rechtin 91中）指出，工程師能夠處理 5 到 10 個互相作用的變量（對于這個變量，我解釋為互相協作的 5 到 10 個類）并且 10 到 50 種交互（我解釋為場景）。以這種方式解釋，多個用例即為該變量空間的多個實例。
因此，10 個用例，每個用例 30 個場景，也是說一共 300 個場景（后面將導致大約 300 個測試用例）對于覆蓋 8 個類的有意義的行為來說已經足夠了。是否有其他的跡象表明這是個合理的數字呢？如果應用 Pareto 的 80-20 規則，那么20%的類將表達80%的功能，同樣，80% 的功能將被每個類中20%的操作來表達。讓我們保守的說，我們需要20%的類（等）來達到75%的功能并且通過這點來構建一個 Pareto 分布圖。（圖 1）
圖 1: 一個 Pareto 式樣的分布圖
如果我們想要描述 80% 的系統行為，并且將 Pareto 規則應用到類、操作和場景數量方面，那么對于每一者都需要描述其行為的 93%(0.933＝ 0.8)－－也是對于每一個都需要 50%，例如，4 個類和 5 個操作(= (12 － 2 構建器/析構器)/2)。節點樹的不同分叉的數量可能達到數千個（其中節點樹用來代表4個類及每個類5個操作的執行模式）。我為每個節點創建了 1 到 3 個鏈接，假設在頂層有 10 個操作（接口操作）的層次結構，并且形成了一個三層的樹。這將會有 1000 條路徑或者場景。所以，500 個場景將會得到 93% 的覆蓋。使用 300 個場景（用相同的假定）我們可以得到 73% 的覆蓋。根據一個選定的算法，可以對這個樹進行修剪，從而刪除冗余的行為說明，甚至更少的數量完全可以符合要求。
達到該目的的另一個方法是研究一下對于 7000 slocs 的 C++代碼需要多少測試用例（從場景派生而來）。這些測試用例不受單元測試層次的制約，并且在 Jones 91 和 Boeing 777 項目中有許多證據表明這個數字是安全的，至少它符合實踐。這些來源表明在 250 到 280 之間是合適的。在一個完全不同的層次上，加拿大自動空中交通系統（Canadian Automated Air Traffic System ，CAATS)項目使用了 200 項系統測試（我私下里獲悉的）。
用例的規模
用例應該具有多大規模呢？是否應該足夠大以及表達足夠的細節才能表達所需要的行為－－這取決于與系統有關的用例復雜性、內部用例和外部用例。－－這里我們應該描述多少系統的內部動作來深入探討一下這個問題。很明顯，從外部行為描述來構建系統，要求將輸出與輸入關聯起來。例如，如果行為對歷史記錄敏感并且很復雜，那么在沒有系統內部的一些概念模型及行為的動作時，很難描述它。注意，沒有必要描述一個系統是如何從內部構建的－－任何滿足非功能性需求和匹配模型行為的設計能夠滿足要求。
UML 1.3 中提供的定義是："用例【類】：一個系統可以執行的動作（包括變體）序列的說明，其中這些動作與系統參與者進行交互"。對復雜的行為的內部動作，可能合理的采用這個定義也可以在實現階段再進行定義――這對于終用戶來說是個更遠的步驟。業務規則也應該納入到用例中以便約束參與者的行為（例如，在一個ATM系統中，銀行需要有一條規則：在一次交易中，提取的金額不能超過 500 美元，無論賬號中的余額為多少）。
根據這種解釋，事件的用例流描述的頁數可以為 2－20 。從計算的角度上看，具有簡單行為的系統顯然不需要冗長的描述。或許我們可以認為簡單的商務系統通常用 2 到 10 頁來描述，平均為 5 頁。對于更復雜的系統來說，業務系統和科學系統在 6 到 15 頁之間，平均為 9 頁。復雜的命令和控制系統在 8 到 20 頁之間，平均為 12 頁（這些比率反映了相同規模系統的工作量與類型之間的非線性關系），盡管我沒有數據來支持這種觀點。更富有表達力和描述性的形式（例如狀態機或者活動圖）可能需要更少的篇幅－－我們仍舊傾向于加強文本，所以此處不討論其他形式，畢竟相關資料很少或者根本沒有。
與上述規模有系統差異的開發應該運用乘法規則來計算在這些假設基礎上得出的每個用例的小時數（我建議增加一個 COCOMO -樣式的成本驅動，該驅動是系統類型的（簡單的業務類型、更復雜的類型、命令及控制類型等等）的觀察到的平均規模或建議的平均規模。
用例規模的另一個方面是場景的數量。例如，一個 5 頁長的用例可能是一個具有很多路徑的復雜結構。再一次重申，需要將場景的數量以及這個比例估計為 30（這是我對于每個用例的場景數的初步估計），將其作為成本的驅動因素。
得到的結果是，我們假設基于大約長度為 100 頁說明的用例，對于任何給定層次的外部說明及補充說明來說，都是足夠的。范圍是 20 到 200 頁之間（這些界限是模糊的）。注意，一個系統（子系統組）在低的層次上的總數是 3－15 頁/ ksloc（簡單的業務系統）到 12－30 頁/ ksloc（復雜的命令和控制系統）。這或許能夠解釋 Royce 98 表中的 14－9 和實際項目之間明顯的矛盾之處，前者的工件所占用的篇幅非常少，而實際項目卻占用了大量的頁。本文的觀點認為規格說明的層次不應受頁數的限制。－－Royce 是正確的，對于大型的、復雜的系統而言，重要內容的說明（如版本聲明）可以達到范圍的上限――200 頁
