本文將與《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模型”等作為附件與本說明書一起提供,為相關的“評審”提供更直觀的表述,為後繼開發提供更準確的指導。
[補充:軟體需求分析說明書有時也稱作:系統需求分析說明書或系統軟體需求分析說明書]