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