簡介 除用例之外，還有其他一些重要的UP需求制品，本章將介紹這些制品，這些內容與案例研究關系密切，并且提供了更為完整的需求示例。
其他需求制品 用例不是要求的全部。
》補充性規格說明 捕獲并確定了其他類型的需求，例如報表、文檔、包裝、可支持性說明、許可授權等
》詞匯表 捕獲術語和定義，它也可起到數據字典的作用
》設想 概括了對項目的“設想”，即執行摘要。該制品為 項目主要思想提供簡潔描述
》業務規則（或領域規則）捕獲了凌駕于特定應用之上的長期規則或政策，例如稅法
這些示例的詳盡程度 本書首要目標是介紹OOA/D基礎知識，而不是本章所論述的次要POS需求細節。因此本章只展示部分示例，并不展示完整詳盡的需求示例。
某些小節將作為承上啟下的過渡小節，突出重點問題，提供對內容的感性認識，然后就會快速進入下面的內容。
準則：初始階段是否應該對此徹底地進行分析 非也。UP是一種迭代和進化式方法，這意味著應該早在完整地分析和記錄大多數需求之前，盡早進行具有產品品質的編程和測試。來自早期編程和測試的反饋使需求進化。
研究表明，在開始階段，高階粗粒度需求的“前十”列表是有幫助的。同樣，在早期花費一定時間去理解非功能性需求（例如性能或可靠性）也是有幫助的，因為這對架構選擇具有重要影響。
可靠性規格說明：是否矛盾？ 接下來所編寫的需求示例可能會造成以下錯覺：既然理解并良好定義了真實的需求，那么也可以用它來對項目進行可靠的預算和計劃。這種錯覺對非軟件開發者來說尤其強烈，程序員會從其慘痛教訓中認識到這種計劃和預算是多么不可靠。
真正重要的是快速構建可以通過用戶驗收測試的軟件，而且能夠滿足用戶真實的目標，但在用戶對軟件進行評估或使用之前，無法確定這些目標。
編寫設想和補充性規格說明是值得重視的，但是這些制品（或者任何需求）也并不是完全可靠的規格說明。只有編寫代碼、測試、獲取反饋、進一步完成與用戶和客戶的協作并且對軟件進行改寫，才會真正達到目標。
這并不是要號召無序分析和思考就匆忙地去編碼，而是建議輕度地處理需求，盡快開始編程，并且不斷引入用戶和測試以得到反饋。
準則：這些制品是否應該放在項目Web站點上 與普通的靜態文檔 不同，這些制品應該是超鏈接的，或者使用不用于字處理器或電子表格的其他工具進行記錄。例如，其中大多數可以記錄在WiKi Web上。
NextGen示例：（部分）補充性規格說明 P78
注解：補充性規格說明 補充性規格說明（supplementary specification）捕獲了用例和詞匯表難以描述的其他需求、信息和約束，其中包括系統范圍的"URPS+"（可用性、可靠性、性能、可支持性和其他）等質量屬性或需求。 在思考用例的時候，某用例專有的非功能性需求可以首先簡要地寫入用例，即用例的“特殊需求”小節。但是，在這種非正式描述后，應該將其歸入補充性規格說明，以便所有非功能性需求集中在一處，避免重復。
補充性規格說明中的元素包括：
》“FURPS+”需求--功能性、可用性、可靠性、性能和可支持性
》報表
》硬件和軟件約束（操作系統和網絡系統等）
》開發約束（例如，過程或開發工具）
》其他設計和實現約束
》國際化問題（貨幣單位、語言）
》文檔化（用戶、安裝和管理手冊）和幫助
》許可和其他法律問題
》包裝
》標準（技術、安全和質量）
》物理環境問題（例如，熱度或振動）
》操作問題（例如，如何處理錯誤，或者每隔多久進行備份）
》特定應用領域規則
》所關注領域的信息（例如，信用卡支付處理的整個過程）
質量屬性 有些需求可以稱為系統的質量屬性（quality attribute，或qualities attribute），包括可用性、可靠性等等。需要注意的是，這些指的是系統的質量，而非屬性本身的質量，屬性本身并沒有高質量之說。
當我們帶上“架構師的帽子”時，系統范圍的質量屬性（記錄于補充性規則說明中）將特別重要，因為架構分析和設計極為關心在功能性需求語境下質量屬性的確定和選擇，第33章將對此進行介紹。
補充性規格說明中有功能性嗎？難道不應該在用例中嗎？ 某些功能或特性并不適合采用用例的形式描述，可以采用特性的方式來描述功能性。
UP當然也允許使用這種面向特性的方法來描述需求，在這種情形下，應在補充性規格說明中描述特性列表。
UP提倡但不是強求對功能性使用用例。用例是一種優秀的方法，可以通過產品使用的典型場景把一組相關特性集中起來思考。但是用例并不是永遠適用。
應用專用的領域（業務）規則 一般來說，諸如稅法等廣泛應用的領域規則屬于UP業務規則制品，UP將其作為核心的共享知識庫。但是，對于更為局限的特定于應用的規則，例如如何計算某項商品折扣，可以記錄在補充性規格說明中。
所關注領域的信息 這對于主題問題專家是具有價值的，他們可以編寫（或提供URI）一些與新軟件系統有關的領域解釋（銷售和賬務，地下油/水/氣流量的地球物理學知識），以便為開發小組提供背景信息和更為深入的理解力
NextGen示例：（部分）設想 P82
注解：設想 編寫執行摘要對項目運行進行簡要的描述，使主要成員建立起對項目的共同設想，也是同樣有幫助的。 設想不應該占據很長的篇幅，也不應該試圖詳細描述公司的需求。設想應該概括用例模型和補充性規格說明中的一些信息。
涉眾的關鍵高階目標及問題 該小節總結高階（通常高于特定用例）目標和問題，并且揭示了重要的非功能和質量目標，這些目標可能屬于某個用例或跨越多個用例。
準則：有哪些簡化的方法？ 特別是在輸入定義高階問題和確定目標的活動過程中，會發生創造性、研究性的小組工作。對于發現根源問題及目標、啟發思路和定義優先級，存在一些有助于小組工作的技術：
》思維導圖（mind mapping）
》產品設想包裝制作（product vision box creation）
》魚骨圖（fishbone diagram）
》排列圖(pareto diagram)
》集體討論（brainstorming）
》多次投票表決（multi-voting）
》記點投票表決（dot voting）
》提名小組過程（nominal group process）
》集體編寫（brainwritting）
》相關性分組（affinity grouping）
可以在Web上找到這些方法的具體介紹。推薦在同一討論會上采用其中幾種方法，以便從不同角度發現共同的問題和需求。
系統特性概要 為掌握主要特性而在設想文檔中只列出用例名稱是不夠的，原因如下：
1、太詳細或層次太低。人們想要的是主要思想的概要
2、用例名稱可能掩蓋了涉眾真正關心的主要特性
3、有些值得注意的特性跨越了多個用例或者與用例無關
因此，使用特性作為替代的、補充性的方式來表示系統的功能，在這種語境下，更準確地說法是系統特性，即以高階、簡潔的語句對系統功能加以概括。更為正式地，在UP中，系統特性是“由系統提供的外部可觀察到的服務，可以直接實現涉眾的需求”
定義：特性是系統能夠實行的行為上的功能。特性應該通過如下語言上的測試：系統實行<特性X>
將功能上的系統特性與各種非功能性需求和約束進行對比，例如“系統必須運行于Linux”，顯然不能通過上述語言上的測試。例如，系統實現Linux。
準則：如何編寫功能列表 通常可以使用兩級層次結構來組織系統特性。但是，如果設想文檔的層次多于兩級，則顯得過于詳細。設想文檔的系統特性應該對功能性進行概括，非不應分解為細粒度元素的冗長列表。
準則：在設想文檔中包含的特性最好少于10個，因為更多的特性不能夠被快速掌握。如果存在更多的特性，則需考慮對這些特性進行分組和概括。
準則：我們是否應該在設想文檔中重復其他需求？ 準則：對于其他需求，要避免在設想和補充性規格說明（SS）中重復或近于重復。最好只在SS中記錄這些需求。在設想文檔中，可以指引讀者到SS中閱讀這些需求
準則：你應該先編寫設想還是用例？ 不需要嚴格定義這種先后順序。在開發者合作創建不同需求制品時，對一個制品的創建工作會影響并有利于澄清另一個制品。盡管如此，還是建議采用如下的順序：
1、首先編寫簡要的設想草案
2、確定用戶目標和對應的用例名稱
3、詳細編寫一些用例，并且開始編寫補充性規格說明
4、精化設想，對以上制品中的信息進行概括。
NextGen示例:（部分）詞匯表 P87
注解：詞匯表（數據字典） 詞匯表（glossary）的最簡形式是重要術語及其定義的列表。令人驚訝的一種常見情況是，不同涉眾可以用略有不同的方式使用同一（通常是技術的或特定于領域的）術語。這一問題必須解決，以減少溝通上的問題和需求的二義性。 準則：及早開始編寫詞匯表。詞匯表將很快成為關于細粒度元素細節信息的有效知識庫。
詞匯表作為數據字典 在UP中，詞匯表也充當數據字典（data dictionary）的角色，即記錄關于數據之數據，也就是元數據（metadata）的文檔。在初始階段，詞匯表應該是術語及其描述的簡單文檔。在細化階段，詞匯表可以擴展為數據字典。
術語的屬性包括：
》別名
》描述
》格式（類型、長度、單位）
》與其他元素的關系
》值域
》驗證規則
注意，詞匯表中的值域和驗證規則是反映系統行為的需求的組成部分。
準則：我們是否可以在詞匯表中記錄組合術語 詞匯表不僅用于記錄原子術語，例如“產品價格”，它也能夠并且也應該包括諸如“銷售”（其中包含其他元素，例如日期和地點）的組合元素和用來描述用例參與者之間所傳遞的一組數據的簡化名稱。例如，在處理銷售用例中，考慮如下陳述： 系統向外部支付授權服務發送支付授權請求，并請求批準支付。 “支付授權請求”是一組數據的別名，也需要在詞匯表中加以解釋。
NextGen示例：業務規則（領域規則） P88
注解：領域規則 領域規則指出領域或業務是如何運作的。盡管應用需求通常都會受到領域規則的影響，但是這些規則不是任何一個應用的需求。公司政策、物理法則（例如油在地上如何流動）和政府法律都是常見的領域規則。
領域規則通常稱為業務規則（business rule），這也是其最常見的類型，但是這一術語并不是恰當的，因為大量軟件應用不是面向業務問題的。
最好在單獨的與應用無關的制品中確定和記錄領域規則，這在UP中稱為業務規則制品，這樣便能夠使分析在組織和項目范圍內進行共享和重用，而不是只限定于特定項目的文檔里。
規則強調了情節的連續性而不是細節，有助于澄清用例中的歧義。例如，在NextGen POS中，如果有人問事否應該在處理銷售用例中加入另一路徑，即不允許不記錄簽名的信用卡支付，業務規則給出了答案，其表明任何信用卡授權公司都不允許這種情況。
過程：迭代方法中的進化式需求 PPT6概括了制品示例及其在UP中的時限。通常，大多數需求制品始于初始階段，并且主要在細化階段開發。
初始階段 涉眾要決定項目是否值得深入調查。實質的調查活動在細化階段發生，而不是初始階段發生。在初始階段，設想以某種形式概括了項目思想，以幫助決策者決定是否值得繼續，并且從哪里著手。
因為大多數需求分析發生在細化階段，所以在初始階段應該只對補充性規格說明稍作開發，只需要突出重要的質量屬性用以揭示主要風險和挑戰。這些制品的輸入可以在初始階段的需求討論會上產生。
細化階段 通過細化階段，基于對部分系統增量構建的反饋、調整以及在若干開發迭代中舉行的多個需求討論會，對“遠景”和設想文檔加以精化。通過進一步的需求調查和迭代開發，其他需求將更為清晰并且可以記錄在補充性規格說明中。
在細化階段結束時，完成并提交用例、補充性規格說明和設想是切實可行的，因為在此時，這些文檔能夠合理地反映穩定的主要特性和其他需求。盡管如此，補充性規格說明和設想不等同于凍結并“簽署”了的規格說明；改寫--并非僵化--是迭代開發和UP的核心價值。
所謂的“凍結簽署”是在細化階段結束時，就項目剩余時間里所要完成的事項與涉眾達成一致意見，并且就需求和進度給予承諾（可能是以合同形式），這是完全切合實際的。在某一時刻（在UP中是細化階段的結束時刻），我們需要對“什么、多少、何時”有可靠的認識。從這種意義上說，簽署關于需求的合約時正常的，也是有必要的。同時還需要具備變更控制過程（UP中明確的最佳實踐之一），以便正式地考慮和批準需求變更，避免混亂和不受控的變更。
“凍結簽署”的事實還意味著如下幾點：
》 在迭代開發和UP中，無論在需求規格說明上付出多少努力，還是不可避免地會存在一些變更，這應該可以被接受。這些變更可能是能夠為所有者帶來競爭優勢的、新近發生的對系統投機性的改進，或者是由于加深了認識而引起的改進。
》 使涉眾來進行評估、提供反饋以及掌握項目的方向以滿足其真實意圖，這是迭代開發的核心價值。“洗手不干”，不關注于參與項目，而是在一組凍結的需求上簽字認可后就等待著項目結束，這樣對涉眾來說并沒有好處，因為他們幾乎不會得到真正滿足其需要的結果。
構造階段 通過構造階段，主要需求（包括功能性需求和其他需求）應該已經穩定下來，雖然還不是終結，但是已經可以專注于次要的微擾事物了。因此，在此階段，補充性規格說明和設想都不必進行大量改動。