UML系統分析與設計03-軟體需求分析說明書

來源:互聯網
上載者:User

本文將與《UML系統分析與設計02-使用案例圖和活動圖表(上)》、《UML系統分析與設計02-使用案例圖和活動圖表(下)》共同組成簡單的基於UML技術的軟體需求分析說明並對其分析結果進行輸出,後續將繼續對基於UML技術的軟體設計進行總結,以拋磚引玉。

 

     《軟體需求分析說明書》雖然不是UML體系的內容,但作為使用UML進行系統分析與設計的一項重要輸出,我想也很有必要進行簡單的說明。由於我所在的公司本文檔標記為“保密”,也就無法在此共用出來給大家做個參考。

     但話又說回來,我所在的公司以前也是沒有這個文檔的,至少在我入職時是沒有的,後來應該是參考了別的人模板,結合自身的特點作了一定的更改,與網上公開的模板也是大同小異。有興趣的可以參考一下百度文庫中的“系統需求分析說明書執行個體模板”。(我並沒有認真分析其內容,只是簡易的看了下格式)

[註:如果下載不了的,可以通過工具“iDocDown”來下載百度文庫中的文檔。當然,對下載“系統需求分析說明書執行個體模板”文檔帶的任何責任,本人概不負責。]

    本著學習與交流的目的我把我所瞭解的文檔目錄共用給大家,目錄大體分分三部分:

    1):前面部分

    前部分的內容大多可以從產品的《可行性分析報告》和《產品需求規格說明書》中獲得,不做詳述。

 

     2):中間部分

    中間部分是本說明書的重點,主要是對業務/需求進行分析後的文檔輸出,是本文的重點。

 

    3):後面部分

    最後部分主要是從總體上的要求,比如:與外部系統的整合與合作,對產品的後繼開發升級、擴充等進行了一些規劃。

 

    4):特別說明

    在本文檔中,有很多類似“約束”、“限制”、“環境”等字眼,後繼一般會以“非功能性需求”來進行驗證,很多時候銷售為了簽單往往在前期什麼都答應,不以為然。比如回應時間、並發資料、資料量等,但對開發來說卻不可大意,我曾經就在並發數上吃過虧。

[注意:可性行分析和產品規格說明書,都是基於產品的。而系統需求分析說明書是基於當前項目的,產品需求可能會分成若干個項目,分批次分階段來進行(我們有時會忽悠使用者說:在第二期為您提供。其實有錢才有第二期,沒錢就是遙遙無期)。嚴格來說兩個文檔的目標,使用者等可能不完全一致,可以簡單的認為項目的需求小於等於產品需求]

    從目錄中我們會發現:其實前部分和後部分在以往的文檔中都基本上已經提及,所以直接拷貝過來整理一下即可,也不是重點。中間部分的“用例描述”就成了我們的本次說明的重點,主要用於對功能性需求進行描述。也就是我們前幾篇文章中所講的需求分析所產生結果的文檔輸出、即《軟體需求分析說明書》。

    《軟體需求分析說明書》的格式,以Word格式為例常見的有兩種。經我在網上尋找,基本上類似如下下:

    1):  表格方式

用例1

用例名稱

描述

該用例的詳細解釋

前提

要使該用例能夠工作,系統需要處於什麼樣條件下,如商店要賣東西必須先開張

觸發條件

是什麼導致這個用例開始工作?如顧客需要商品,並進入商店。

成功

用例完成後系統處於什麼狀態?如顧客擁有了所需產品並感到愉快,貨幣儲存在出納機中,等待下一位顧客。

中止

如果用例被放棄了,會發生哪些情況?如,如果顧客放下購物籃沒有買任何東西離開,需要有人看到這些並把貨物放回原處。

參與者

主要的

誰起主導作用?如顧客和收款員?

從屬的

誰起次要作用?如店員?

過程

步驟

活動名

描述

 

1

 

 

 

2

 

 

 

3

 

 

 

 

 

 

 

 

 

 

變更

步驟

活動名

描述

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

異常

步驟

活動名

描述

 

 

 

 

 

 

 

 

 

 

 

 

 

    2):  編號方式

  1. 用例名

     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模型”等作為附件與本說明書一起提供,為相關的“評審”提供更直觀的表述,為後繼開發提供更準確的指導。

 

[補充:軟體需求分析說明書有時也稱作:系統需求分析說明書或系統軟體需求分析說明書]

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.