假設更大的聚合也是可能的，但是我實在不想再考慮了！
每個用例的工作量
通過對每一層的額定的規模的工作量估計，我們可以對每個用例的工作量有一些深入了解。使用 Estimate Professional? 工具 （基于 COCOMO 2 和 Putnam's SLIM 模型），將語言設置為 C++（其他成本驅動因素設置為額定值），然后計算每一個示例系統類型在每個額定規模點的工作量（假設 10 個外部用例），得到表 1。表中描述的 L1 和 L2 范圍考慮到了單個用例的復雜度――使用 COCOMO 的代碼復雜性矩陣通過類比進行估計。在 L2 層，我相信復雜性在被納入系統類型的特征時復雜程度發生變化，因此一個更高層次的復雜命令和控制系統用例，將包含在一個較低的層次上復雜性的混合。在一個按照 log-log 比例的圖上繪制這些數據，得到圖 2。
圖 2: 用例工作量規模圖
從中我們可以看到，150-350 小時/用例（10 2.17-10 2.54）這個原來的 Objectory 數字在 L1 層上很適合，例如，這些用例可以通過類的協作來實現――因此存在一些理由來支持這個數字。然而，它不足以在分析中用來描述所有項目－－我的一位同事曾在電子郵件與我交流時說：它太"片面" 了。
工作量估計
當前的實際系統不能與這些槽（slot）一一匹配。所以，為了幫助了解應該如何描述一個系統，我們將使用從該方法種得出的模糊的界限并將它們繪制出來：
圖 3: 每個層次的規模范圍
從圖 3 中，我們可以看到一個超過 2.2 萬 slocs 的系統可能是在第一層描述，用例的數量在 2 到 30 之間。在這個規模上，更高的用例數量表明用例的粒度太細了。
規模在 2.2 萬 和 5.4 萬 slocs 之間的系統，應該使用一層用例和兩層用例的混合，用例的數量在 4（都在第二層）和 76 都在第一層）之間，正如上圖所表明的那樣，一般不會出現極限值。
規模在 5.4 萬和 11 萬 slocs 之間的系統，一個結構好的系統完全在第二層進行描述是可能的，用例的數量在 10 到 20 之間；混合起來可能是 L1/L2/L3（1 到 160 個用例，一般不會出現極限值）。
規模在 11 萬 和 37 萬 slocs 之間的系統，可能在第二層和第三層之間，用例的數量在 3（全部在第三層）到 66（全在部第二層）之間。
規模在 37 萬 和 54 萬 slocs之間的系統，如果完全在第三層進行描述，那么用例的數量在 9 到 12之間；混合情況可能是 L2/L3/L4（1 到 100 個用例，一般不會出現極限值）。
規模在 54 萬 和 260 萬 slocs 之間的系統，可能在第三層和第四層之間，用例的數量在 2（全部在第四層）到 60（全部在第三層）之間。
規模超過 260 萬 slocs 的系統，在第四層的用例數量應該在 8 左右。
多少用例才是足夠的?
從一些經驗法則中可以得到一些有趣的觀察結果。有一個問題經常被問及－－多少用例是過量的呢？這個問題實際上意味著在捕獲需求的過程中多少是過量。答案似乎是多于 70 個，甚至對于大的系統來說，70 這個數字也表明對于設計來說粒度太細了。在 5 到 40 之間是非常合適的，但是這只是數量，而并沒有考慮到層次，不能用來估計規模和工作量。這是初始的數量，對于特殊的層次是合適的。如果一個大型超級系統被分解為系統，系統又被分解為子系統，以此類推，那么需要數以百計的用例。如果直到類的層次達到后才開發用例，那么終的數量可能是上百個甚至是上千個（對于一個 140 人－年的項目，或者對于每個用例有15個功能點這樣的項目來說是 600 個用例）。然而，作為一個純粹的獨立于設計的用例分解來說，這并不會發生。這些用例起源于 Jacobson 97 中描述的過程，Jacobson 97 中系統層次上的用例被劃分為分配給子系統的行為，其中可以為子系統編寫更低層次的用例（將其他子系統作為參與者）。
工作量估計的過程
如何進行估計呢？這里有許多先決條件：如果不能理解問題的領域、不了解系統的規模和系統構架，以及在哪一階段進行估計，那么不能夠進行基于用例的估計。
第一次粗略的估計可以根據專家的觀點或者更正式的采用 Wideband Delphi 技術（該技術是Rand 組織在 1948 年發明的，請參考Boehm 81 的描述）。這將使得評估者可以將系統在圖 3 所示的規模范圍中對號入卒。這種部署將提供用例數量的范圍，并且表明表達式的層次（L1， L1/L2 等等）。然后評估者必須基于對現有構架知識和領域中的理解來決定這些用例是否適合某一層（是否毫不相關），或者是不同層次的混合（以事件流的方式來表達）。
