終於到了快結束的時候了，這將是用例分析系列的最後一篇，結果是得到需求規格說明書，以結束需求分析的過程。經過前面七篇的工作，我們從最初的業務用例獲取入手，獲得了業務用例模型，這是我們的業務範圍；經過分析得到了業務場景，這是我們的業務藍圖；經過規劃，得出用例實現視圖，這是我們的系統範圍；經過再次分析，得到了用例實現以及領域模型，包括用例規約，業務規則和業務數據，這是我們的概念模型。僅從需求所需的必要元素來說，我們基本上已經完成了需求分析的工作。誠如上一篇結尾所說，爲了讓我們的需求更完美，這一篇所要做的工作也是必不可少的。這一篇將要討論到的內容包括：用例補充規約，系統原型，以及需求規格說明書
先說說用例補充規約。
之前我們得到的用例規約是功能性的，它們是針對Actor完成目標業務所需的功能性Feature的描述。然而我們所面對的系統除了功能性的Feature之外，總有一些是與業務功能無關的，這部分需求就是補充規約要涉及的內容。
什麼樣的需求與業務功能無關呢？一般來說，就是系統需求，例如可靠性，可用性，擴展性，易用性等等。用戶提出，系統必須提供7*24小時的服務，它應該有一定隨業務變化而適應的能力，系統的界面應當簡單易學，具備基礎計算機知識的人可以不經過培訓就能使用它等等。這些需求與具體業務要求無關，哪怕一個不實現，系統也能Run起來。但是這些需求又是如此重要，它們是系統達到用戶期望必不可少的。甚至在用戶看來，某些補充規約要求比業務要求還重要，某個業務要求沒做好，用戶或許能寬容，如果你說系統不能提供7*24小時的服務，用戶肯定是不能接受的。這些需求，就是要在補充用例規約裏面說明的內容。
筆者自己有個習慣，在上一篇也有所提及，就是習慣於把全局規則也寫到補充用例規約裏面。比如，用戶提出，所有系統使用者在系統中的任何操作，都要能夠記錄下來；如果數據被更改，不論是Modify,Add還是Delete，數據都要做一個備份；響應時間可能超過1分鐘的功能，都要提供進度條等等...這些全局規則在實際情況中，一般都是由系統框架，或某個中間件來完成的，它們是系統架構的一部分。因此這些需求雖然也是功能性的，但筆者認爲將它們作爲補充需求，與可靠性之類的系統需求一起，由較高層次的設計師或者是架構師來處理它們更合適。
那麼補充用例規約到底是一個用例寫一份還是全部集中在到一起呢？RUP提供的模板是一個用例寫一份，只要它們與該用例相關。筆者在實際工作中覺得集中在一份文檔中似乎更合理。一是減輕很多的重複工作量，二是集中在一起更便於管理和驗證。
至於補充規約的格式就沒那麼重要了，只要將用戶提出的，或者用戶未提出，但作爲系統建設者知道系統要很好運行就必須去加入的那些特性，都一一寫明白了，就OK了。當然，有時某個補充要求的確只與一個特定的用例有關，例如交納借閱費，有一個可能的補充要求是保障安全性，包括數據安全，傳輸安全。其它用例則沒有必要進入安全通道。這時，專門爲交納借閱費用例寫一個補充規約也是合理並且推薦的方式。
再來說說系統原型。所謂系統原型根據目的不同，也分爲好多種，本文無意深入探討，大致說說，並只描述與需求過程相關的原型。例如，我們可能要使用一個全新的技術，爲了驗證其技術可行性，可能會開發一個小的原型，以掌握或證明我們能夠使用這種技術，也證明這項技術能夠支持後續的開發，這是一種驗證性原型；我們有一個初步的想法，但不知往下能走多遠，這個想法是否可行，也可以開發一個原型，這是一種探索型原型；我們要向別人說明某個產品，爲了形象化，也可以開發一個原型，以顯式的向別人展示以加深理解，這是一種輔助原型...目的不同，原型也有多種。另一種分類方法是將原型分爲拋棄型的和漸進型的，所謂拋棄，就是用完了就扔了，漸進型的，則是將來會在它基礎上逐步完善，乃至形成最終系統。
我們在做需求時所需的原型主要是輔助性的，將用例場景轉化成可操作的原型，如果是做Web系統，則基本上就是靜態html。第一，它能幫助系統分析員更好的與用戶交流，同時讓腦子湖塗的用戶明白，哦，原來就是這樣的啊......第二，這個原型能幫助用戶深化需求，憑空想象用戶很難提出具體而清晰的需求，當面對一個可以操作的界面時，往往文思泉涌。第三，這個原型能幫助系統分析員驗證需求分析的結果，如果將用例場景的文字描述轉化成界面以後難以操作，那就得回頭修改用例場景了。
那麼需求的系統原型是拋棄型的還是漸進型的呢？不一定。有的組織有快速頁面生成工具，能很快的將需求轉化成界面，這些界面簡單，不能滿足開發要求，需求結束後往往被拋棄；有的組織爲了在需求過程中將用戶Look and Feel的需求也一併收集，會精心開發界面原型，這些界面就成爲將來的開發基礎。的確大部分組織是將html開發完成後，由程序員填入動態代碼而形成ASP,JSP等動態網頁的。
系統原型什麼時候需要呢？雖然本系列文章到最後纔來討論它，但筆者的建議是從一開始就要開始原型的製作。很多人抱怨需求難做，用戶講不清又說不明，今天說的跟明天不一樣，抱怨用戶根本不懂計算機。有此抱怨是正常的，需求從來就不是容易的，但如果以這爲藉口而做不出好的需求，那就只能說明你不 是一個合格的系統分析員了。用戶如果都懂計算機，還要你做什麼？還好意思拿着"高薪"，號稱"高新技術人才"麼？把用戶想說又說不出來，或者根本不想說的東西套出來，這就是系統分析員的職責。原型在這裏將起到巨大的幫助作用，一個圖形化的展示勝過千言萬語，UML的誕生也是這個原因。在需求的初始階段，界面原型或許還開發不出來，但是，用Word,Visio,Powpoint畫幾個簡單的圖示不困難吧？甚至在草稿紙上手工畫畫界面原型，也會對你跟用戶的交流起到巨大的作用。
我們的所有準備工作都完成了，即將交出工作成果--需求規格說明書。有的讀者會奇怪，之前我們做的工作不都是需求說明嗎？怎麼又來一個需求規格說明書？原因是這樣，我們之前的工作的確都是需求說明，但是，這些需求說明是零散的，組織不好的。就拿筆者給大家提供的實例來說，讀者在看的時候感覺如何？沒有章節，沒有提綱，也看不出作者的組織思路，要看明白一個需求，要點好幾個圖，展開好幾層。對系統分析員來說不是什麼問題，但對用戶而言呢？你能指望他們滿意這樣的文檔而讓你驗收通過嗎？另一個原因是，現在系統建設一般都會按照國標來要求文檔提供，例如GB9385-88，尤其請了監理的用戶更是如此。因此，寫一份符合國標格式要求的需求文檔是非常有必要的。
不必擔心需求規格說明書會給你帶來多大的工作量，其實所有的元素已經具備，需要做的工作不過是將這些元素組織到一起而已。筆者提供一個簡單的例子以說明如何將他們組織起來。但這個例子並不是說明這是一個標準格式，你應當根據組織規範，用戶要求來組織這些元素。筆者想說明的只是一個組織文檔的思路和哪些元素是必須的以供參考。點這裏下載
最後需要說明的一點是，在這個例子裏，分了用戶需求和系統需求兩個部分，這對應着業務用例和用例實現。用戶需求不一定是系統需求，某些用戶需求是不必實現到系統中的，例如本系列文章示例中的圖遞送過程，缺了它用戶需求就不完整，但實際上這是一個人工過程，不需計算機的參與；同時用戶需求也未必全部包含系統需求，例如用戶需求中未提及事務處理，操作記錄，但作爲一個健壯的系統，這些需求又是必不可少的。
後記...
前後經過大半年，關於系統分析員用例分析的文章到這裏就結束了。期間承蒙網友們的支持與鼓勵，才走到今天。系統分析和UML是一個龐大的話題，短短的八篇文章僅能夠揭起冰山一角。實踐比理論學習能更快的成長。就筆者自己而言，若要論及理論知識，未必及得上科班出身的系統分析員們。只是實踐多了，就有些經驗積累下來，以至能與諸位分享。筆者相信，理論--實踐--理論，永遠是一條不二的成長途徑。只要本系列文章對大家還有些幫助，就不枉這半年多的筆耕了。
筆者不寄望於能在這短短八篇文章裏將所有知識和經驗都講到，也不保證有需要的讀者一定能在這裏找到答案。但筆者的Blog還在，也還沒有從此收山的打算，只是這一系列文章到了該結束的時候了。若讀者有疑問，有指教，都可以在我的BLog裏留言，以武會友就是專門爲大家準備的。筆者保證每條留言都會回覆的。謝謝大家。
小小預告一下，用例分析系列結束了，接下來筆者將開始系統分析和設計的系列文章，就是通常所說的OOD過程，這是將需求轉化爲代碼的中間重要階段，所面對的讀者是OO系統設計師。希望繼續得到大家的支持與鼓勵。敬請期待。