需求用例分析之三：補充規約

補充規約在RUP中是記錄那些在用例模型的用例中不容易展現出來的系統需求。這些需求包括： 

• § 法律法規方面的需求和應用标準。
• § 要建立的系統品質屬性，包括可用性需求、可靠性需求、性能需求和可支援性需求。
• § 其他需求，諸如作業系統和操作環境、相容性需求以及設計限制。

補充規約是對用例模型的重要補充。補充規約和用例模型應該一起擷取對系統的一整套需求。

通過以上文字可以知道，補充規約是全局性的要求，與上述c文中的“全局規則”極為接近。而中文中“補充規約”的說法讓不少人以為這是不重要的，是可以不寫的。

    事實上這是需求全局總綱性的說明，不寫補充規約相當于沒有展現全貌。是以有些組織将此文檔名稱改為“需求全局說明書”或者“需求總綱說明”，在需求全局說明書中說明需求概貌和原補充規約需要的内容，下面是一個需求全局說明的章節例子：

1 項目或産品概況     1.1  産品或系統名稱     1.2  産品或系統使用者     1.3  運作平台     1.4  詞彙表     1.5  資料字典   2      性能名額和驗收标準   3      功能需求概況     3.1  總體概述     3.2  功能子產品劃分     3.3  功能塊編碼  4      資訊安全方面需求     4.1  許可證方面需求     4.2  身份認證和授權方面需求     4.3  可恢複性方面需求   5      法律法規标準方面要求  6      非功能性需求        可用性需求、可靠性需求、性能需求和可支援性需求  7      其它要求               諸如作業系統和操作環境、相容性需求以及設計限制

另外一個對于補充規約的誤解是将補充規約設為用例規約的一部分，成為用例的一個屬性字段，甚至于将大量業務邏輯寫在用例的補充規約中，

由于在一個字段中書寫，所用寫法隻能是傳統SRS的寫法，這樣書寫後，用例的事件流變成簡單的引用補充規約，顯得無足輕重。

這樣其實喪失了用例分析的優勢，反而是回到了傳統SRS的路上。

是以無論從那個角度來講，在用例裡面是不需要補充規約這個屬性字段。

--------------------------------

作者：張克強

微網誌：張克強-靈活307 

email:[email protected]

本網站的所有文字允許在知識共享 署名-相同方式共享 3.0協定和GNU自由文檔許可證下修改和再使用。