本文將與《UML系統分析與設計02－用例圖和活動圖（上）》、《UML系統分析與設計02－用例圖和活動圖（下）》共同組成簡單的基於UML技術的軟件需求分析說明並對其分析結果進行輸出，后續將繼續對基於UML技術的軟件設計進行總結，以拋磚引玉。
《軟件需求分析說明書》雖然不是UML體系的內容，但作為使用UML進行系統分析與設計的一項重要輸出，我想也很有必要進行簡單的說明。由於我所在的公司本文檔標記為“保密”，也就無法在此共享出來給大家做個參考。
但話又說回來，我所在的公司以前也是沒有這個文檔的，至少在我入職時是沒有的，后來應該是參考了別的人模板，結合自身的特點作了一定的更改，與網上公開的模板也是大同小異。有興趣的可以參考一下百度文庫中的“系統需求分析說明書實例模板”。（我並沒有認真分析其內容，只是簡易的看了下格式）
[注：如果下載不了的，可以通過工具“iDocDown”來下載百度文庫中的文檔。當然，對下載“系統需求分析說明書實例模板”文檔帶的任何責任，本人概不負責。]
本着學習與交流的目的我把我所了解的文檔目錄共享給大家，目錄大體分分三部分：
1）：前面部分
前部分的內容大多可以從產品的《可行性分析報告》和《產品需求規格說明書》中獲得，不做詳述。
2）：中間部分
中間部分是本說明書的重點，主要是對業務/需求進行分析后的文檔輸出，是本文的重點。
3）：后面部分
最后部分主要是從總體上的要求，比如：與外部系統的集成與合作，對產品的后繼開發升級、擴展等進行了一些規划。
4）：特別說明
在本文檔中，有很多類似“約束”、“限制”、“環境”等字眼，后繼一般會以“非功能性需求”來進行驗證，很多時候銷售為了簽單往往在前期什么都答應，不以為然。比如響應時間、並發數據、數據量等，但對開發來說卻不可大意，我曾經就在並發數上吃過虧。
[注意：可性行分析和產品規格說明書，都是基於產品的。而系統需求分析說明書是基於當前項目的，產品需求可能會分成若干個項目，分批次分階段來進行（我們有時會忽悠用戶說：在第二期為您提供。其實有錢才有第二期，沒錢就是遙遙無期）。嚴格來說兩個文檔的目標，用戶等可能不完全一致，可以簡單的認為項目的需求小於等於產品需求]
從目錄中我們會發現：其實前部分和后部分在以往的文檔中都基本上已經提及，所以直接拷貝過來整理一下即可，也不是重點。中間部分的“用例描述”就成了我們的本次說明的重點，主要用於對功能性需求進行描述。也就是我們前幾篇文章中所講的需求分析所生成結果的文檔輸出、即《軟件需求分析說明書》。
《軟件需求分析說明書》的格式，以Word格式為例常見的有兩種。經我在網上查找，基本上類似如下下：
1）： 表格方式
| 用例1 |
用例名稱 |
||
| 描述 |
該用例的詳細解釋 |
||
| 前提 |
要使該用例能夠工作，系統需要處於什么樣條件下，如商店要賣東西必須先開張 |
||
| 觸發條件 |
是什么導致這個用例開始工作？如顧客需要商品，並進入商店。 |
||
| 成功 |
用例完成后系統處於什么狀態？如顧客擁有了所需產品並感到愉快，貨幣保存在出納機中，等待下一位顧客。 |
||
| 中止 |
如果用例被放棄了，會發生哪些情況？如，如果顧客放下購物籃沒有買任何東西離開，需要有人看到這些並把貨物放回原處。 |
||
| 參與者 |
主要的 |
誰起主導作用？如顧客和收款員？ |
|
| 從屬的 |
誰起次要作用？如店員？ |
||
| 過程 |
步驟 |
活動名 |
描述 |
|
|
1 |
|
|
|
|
2 |
|
|
|
|
3 |
|
|
|
|
|
|
|
|
|
|
|
|
| 變更 |
步驟 |
活動名 |
描述 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 異常 |
步驟 |
活動名 |
描述 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2）： 編號方式
- 用例名
1.1 前置條件
1.2 后置條件
1.3 擴充點
1.4 事件流
1.4.1 基流
1.4.2 分支流
S-1:
S-2:
S-n:
1.4.3 替代流
E-1:
E-2:
E-n:
2．用例名2（略）
我比較喜歡第二種縮進方式，因為活動圖的步驟是不定的，我不喜歡總去添加和刪除網格，麻煩。當然網格看起來比較一目了然。廢話說了一堆，直接來個例子以作參考吧 (*^_^*)
－－－－－－－－－－－－－－－－－－－－－－－－－示例－－－－－－－－－－－－－－－－－－－－－－－－－
1. 唱片資料管理
1、 用例圖
2、 用例描述：
管理唱片資料用例，主要用於管理員對唱片資料信息進行“新增”、“修改”和“刪除”操作，方便管理員對唱片資料進行及時創建和更新。（此處可以更詳細一些）。
管理員在“基礎數據管理”的“唱片資料管理”模塊來實施本用例。主要用於維護唱片資料的基礎信息、庫存信息等。
該用例包括三個具體的用例：
創建唱片資料：管理員輸入唱片的基礎信息、庫存信息，並創建數據信息。
修改唱片資料：管理員修改唱片的基礎信息、庫存信息。隨后進行保存或取消恢復操作。
刪除唱片資料：管理員對所選的唱片資料信息進行刪除。
3、前置條件：
只有具有管理員身份的用戶才具有此功能的操作權限。
4、后置條件：
如用例成功，則用例對應的唱片信息及關聯信息將會被新增到系統中、或被修改更新、或被刪除；如不成功，則系統狀態不變化。
5、參與者：
管理員
6、基本事件流：
當管理員需要新增、修改、刪除唱片資料信息時，用例啟動。
系統呈現管理員可以執行的活動（新增唱片資料、修改唱片資料、刪除唱片資料）供選擇。
如果所選活動是“新增唱片資料”，則執行分支流S-1：新增唱片資料。
如果所選活動是“修改唱片資料”，則執行分支流S-2：修改唱片資料。
如果所選活動是“刪除唱片資料”，則執行分支流S-4：刪除唱片資料。
7、分支流：
S-1：新增唱片資料
(1) 用戶選擇新增操作
(2) 系統提供新增唱片資料的信息編輯界面，要求用戶指定唱片名稱、出版社、出版時間、現有庫存進行錄入。
[注：這些信息只為代表，並不一定適應現實]
(3) 用戶錄入完唱片資料信息后提交
(4) 系統校驗用戶提交的信息（E-1）
(5) 系統保存新唱片資料信息內容
S-2：修改唱片資料
(1) 用戶選擇修改操作
(2) 系統顯示唱片資料列表並要求用戶選擇要修改的唱片資料
(3) 用戶選擇一個要修改的唱片資料
(4) 系統提供選中唱片資料的信息編輯界面
(5) 用戶編輯唱片資料基本信息后提交
(6) 系統校驗用戶提交的信息（E-2）
(7) 系統保存修改后的唱片資料信息內容
S-3：刪除唱片資料
(1) 用戶選擇刪除操作
(2) 系統顯示晶片資料列表並要求用戶選擇將要被刪除的唱片資料項
(3) 用戶選擇唱片資料並確認刪除唱片資料
(4) 系統校驗用戶提交的信息（E-3）
(5) 系統刪除唱片資料的信息
8、替代流：
E-1:用戶提交的唱片資料信息與系統中的數據有沖突，系統顯示失敗的信息，用戶可以重新輸入或終止用例。
E-2:用戶提交編輯后的唱片資料信息與系統中的數據有沖突，系統顯示修改失敗的信息，用戶可以刷新唱片資料列表顯示重新開始修改或終止用例。
E-3:用戶選擇的刪除操作不可行，系統顯示失敗信息，返回並刷新唱片資料列表。或提示警告信息，用戶可以確認或取消。
9、擴充點
無；
[注：此處用於描述“extend”的用例說明]
10、活動圖：
[注意：好的用例分解，其優點不僅體現在技術方面，對項目管理也是很有幫助的。特別是在進行任務WBS分解及任務計划制定時，會表現的一目了然。]
－－－－－－－－－－－－－－－－－－－－－－－－－示例完－－－－－－－－－－－－－－－－－－－－－－－－－
到目前為此大部分基於UML的工作是對需求進行分析，從而進行一定的篩選和歸納，主要面對的對象是用戶、產品經理等。在整個過程中技術人員可能更多作用的是明確用例的可行性，並協助完成對產品需求到系統需求的轉換（比如“店長可以刪除唱片資料，而店員不可以”進行分析后轉化成“基於角色的權限管理”）從而形成這個《軟件需求分析說明書》。
《軟件需求分析說明書》的一個重要作用是把產品需求或用戶需求轉變成了系統需求，成為后繼項目開發的一個基線。按“項目管理”的說法是明確了本項目的“項目范圍”。
當然，在很多的項目中也會把“系統的典型UI風格”、“操作文檔”、甚至“簡單的Demo模型”等作為附件與本說明書一起提供，為相關的“評審”提供更直觀的表述，為后繼開發提供更准確的指導。
[補充：軟件需求分析說明書有時也稱作：系統需求分析說明書或系統軟件需求分析說明書]