補充規約在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:zhangkeqiang@gmail.com

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

總結

以上是生活随笔為你收集整理的需求用例分析之三：补充规约的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。