關于怎么寫需求分析報告,怎么寫需求分析這個問題很多朋友還不知道,今天小六來為大家解答以上的問題,現(xiàn)在讓我們一起來看看吧!
1、需求分析格式1 引言1.1 編寫目的【說明】目標:對用戶的需求進行收集、整理與分析,弄清楚系統(tǒng)究竟要 “干什么”及“由誰干”,并用合乎規(guī)范的文字及圖表予以描述。
2、不需要說明“怎么干”,因為那是設計階段的事情。
3、有關文字與圖表應盡量讓用戶便于理解。
4、??? 預期讀者:用戶方的相關業(yè)務人員、雙方的開發(fā)人員和系統(tǒng)維護人員。
5、??? 作用:實現(xiàn)開發(fā)方與用戶方的雙向溝通,是把業(yè)務需求計算機化的關鍵步驟。
6、??? 為下一階段的概要設計工作提供依據(jù)。
7、當用戶的需求發(fā)生變更時,應添寫補充說??????? 明;如變動過大可形成新版本。
8、軟件需求說明(Software Requirements Specification)的主要作用為:? 為用戶方與開發(fā)方建立共同協(xié)議奠定基礎。
9、? 提高開發(fā)效率、強化進度控制。
10、? 為項目的的評測與驗收提供依據(jù)。
11、? 便于移植。
12、? 作為系統(tǒng)不斷提高的基礎。
13、1.2 編寫背景1.2.1 系統(tǒng)名稱及版本號【說明】形如“網銀三期***系統(tǒng)V3.0.0”。
14、其中,版本號的格式為“XX.XX.XX”,X為阿拉伯數(shù)字,左“0”可省略。
15、1.2.2 使用者【說明】適應對象和范圍。
16、主要指預期讀者,也供有關領導審閱。
17、1.2.3 與其它系統(tǒng)的關系【說明】在用戶現(xiàn)有的及預期的整個應用系統(tǒng)中,給本系統(tǒng)準確定位。
18、用示意圖及相應的文字予以說明。
19、2 用戶的基本情況2.1 系統(tǒng)建設背景【說明】項目背景與依據(jù)、現(xiàn)有基礎、項目規(guī)模、預期目標等。
20、可繁可簡,格式自定。
21、2.2 組織機構與職能【說明】用層次示意圖及相應文字表示(如果需要開發(fā)的系統(tǒng)與部門沒有直接依賴關系此節(jié)可省略,本章隨后的小節(jié)數(shù)將順次減1),加注:組織機構的層次數(shù)、數(shù)目、各個機構的職能簡述。
22、2.3 用戶特點【說明】所在行業(yè)特征、操作人員與系統(tǒng)維護人員的數(shù)量、學歷與水平、數(shù)據(jù)量大小、使用頻度等。
23、2.4 用戶業(yè)務分析【說明】在本部分,希望系統(tǒng)分析人員能夠對用戶業(yè)務現(xiàn)狀進行分析、對用戶對本系統(tǒng)的未來發(fā)展方向作出一定的預測等。
24、以便設計人員對業(yè)務及其發(fā)展有所了解,增強系統(tǒng)設計的前瞻性。
25、2.5 計算機應用現(xiàn)狀【說明】可繁可簡,格式自定。
26、3 業(yè)務需求3.1 項目概述【說明】第一、 指明項目的開發(fā)意圖、應用目標(總目標、分期目標)、作用范圍、預期效益等。
27、第二、 指明在輸入信息轉變?yōu)檩敵鲂畔⒌倪^程中,為了滿足用戶的業(yè)務需求,應用軟件必須完成的基本功能(采用自然語言敘述)。
28、但此時不要求對基本功能進行分解。
29、第三、 如果本系統(tǒng)與其他系統(tǒng)相關聯(lián),則應確定本系統(tǒng)的基本功能邊界(可采用圖示+文字說明的形式,用藍色標示出本系統(tǒng)的功能,用綠色標示出相關系統(tǒng)的功能)。
30、3.2 約束條件3.2.1 費用約束【說明】 預計投資金額概算、其中軟硬件費用的比例、資金分期到位計劃。
31、3.2.2 進度約束【說明】預計完成日期、分步實施期限。
32、3.2.3 其它約束【說明】場地面積限制、通信設施基礎、其它干擾因素。
33、??? 注意:任何計算機系統(tǒng)都不是包羅萬象的;用戶自身的能力也是有限的。
34、輕諾必寡信。
35、故應特別指出:由于哪些條件的約束,本系統(tǒng)不能滿足哪些業(yè)務需求與系統(tǒng)需求。
36、本章主要介紹項目的總體業(yè)務功能,要求站在客戶的角度把握系統(tǒng)需求.3.3 性能需求【說明】依據(jù)ISO9000標準及我們的理解,下面列出了軟件的6組性能,共涵蓋21個子特性。
37、這些性能/子特性的相對重要性并不是等同的。
38、編寫時,可以基于具體項目的實際需求,對下述標題或內容進行取舍/側重。
39、事實上不可能做到面面俱到,往往要作出某些折中。
40、本節(jié)說明系統(tǒng)在性能方面的預期目標,不要求提供實現(xiàn)上述目標的具體實施方案。
41、3.3.1 功能性【說明】指與軟件實現(xiàn)的各項功能及其指定性質有關的一組屬性。
42、這些功能都是滿足規(guī)定需求和潛在需求所必需的。
43、它包括5個子特性:適用性:與指定業(yè)務所需各項功能的實現(xiàn)及其適合程度有關的一些軟件屬性。
44、準確性:與保證正確(或符合要求的)結果(或效果)有關的一些軟件屬性。
45、互操作性:與軟件同一些指定系統(tǒng)交互作用能力有關的一些軟件屬性。
46、復合性:使軟件遵守相關的標準、約定/法律或類似規(guī)定有關的一些軟件屬性。
47、保密安全性:與針對蓄意(或無意)而非法存取程序和數(shù)據(jù)的預防能力有關的一些軟件屬性。
48、這里主要指的是保護軟件的要素,旨在防止各種非法訪問、修改、破壞、泄密及感染計算機病毒等。
49、3.3.2 可靠性【說明】指在規(guī)定的條件和期限內,與軟件保持其性能水平有關的一組軟件屬性。
50、成熟性:與軟件故障引起的失誤頻率有關的一些軟件屬性。
51、容錯性:在軟件故障發(fā)生或其規(guī)定界面被破壞的情況下,與軟件仍能保持規(guī)定性??????????????? 能水平的能力有關的一些軟件屬性。
52、可恢復性:在失效的情況下、在限定的期限和強度范圍內,與軟件重建性能水平??????????????? 并恢復直接受影響的數(shù)據(jù)的能力有關的一些軟件屬性。
53、3.3.3 易使用性【說明】指與規(guī)定用戶(或潛在用戶)使用軟件所需的努力程度、對這種使用所做的評估有關的一組軟件屬性。
54、它包括3個子特性:易理解性:與用戶為理解其邏輯概念及適用范圍需做的努力有關的一些軟件屬性。
55、易學習性:與用戶學習其應用(例如操作控制、輸入、輸出)需做的努力有關的一些軟件屬性。
56、易操作性:與用戶操作及運行控制需做的努力有關的一些軟件屬性。
57、3.3.4 高效性【說明】指在特定的運行環(huán)境中,描寫軟件性能水平與所用的資源量之間關系的一組軟件屬性。
58、它包括兩個子特性:時間特性:在完成軟件功能時,與響應時間、處理時間、吞吐率有關的一些軟件屬性。
59、資源特性:在完成軟件功能時,與所用資源量及占用時間有關的一些軟件屬性。
60、3.3.5 可維護性【說明】與對軟件進行指定的修改所需的工作量有關的一組軟件屬性。
61、它包括4個子特性:易分析性:與診斷故障、確定失敗原因、在需要修改的部位進行標識等所做努力有關的一些軟件屬性。
62、易修改性:與實施修改、排除故障、環(huán)境改變所做努力有關的一些軟件屬性。
63、穩(wěn)定性:與修改的意外影響帶來的風險有關的一些軟件屬性。
64、易測試性:與對經過修改的軟件進行檢驗/確認做努力有關的一些軟件屬性。
65、3.3.6 可移植性【說明】指軟件從一個環(huán)境轉移的另一個環(huán)境時,與其適應能力有關的一組軟件屬性。
66、它包括4個子特性:適應性:除已有手段外,無須采用其它措施或手段,軟件便應能適應指定的環(huán)境。
67、與這種能力有關的一些軟件屬性稱為適應性。
68、易安裝性:在指定環(huán)境內,與安裝軟件所需努力有關的一些軟件屬性。
69、一致性:軟件從一個環(huán)境轉移的另一個環(huán)境時,應符合一定的標準和約定。
70、與這種符合程度有關的一些軟件屬性,稱為一致性。
71、易替換性:有時會出現(xiàn)這種需求:在某個其它軟件的運行環(huán)境下,要用本軟件來置換那個軟件。
72、與這種可能性及所需努力有關的一些軟件屬性。
73、4 用戶需求【說明】本章下面介紹的是一般規(guī)模軟件系統(tǒng)的書寫格式。
74、在書寫過程中可能要以業(yè)務名稱劃分小節(jié)(例如:5.1 代收電話費)。
75、每個業(yè)務小節(jié)包含兩個部分:第一部分是對此業(yè)務中角色和功能的定義;第二部分是此業(yè)務的圖形分析方法。
76、 在本章開始未分節(jié)的部分,應當繪制一個總體結構圖,依據(jù)這個總體結構圖進行一個總體描述,使得閱讀者對下面分節(jié)描述的各個功能形成一個整體印象。
77、這個總體結構圖不一定是指在ROSE工具中繪制的用例總圖, 而是根據(jù)需要可以選擇包括“用例總圖”、“適當級別的數(shù)據(jù)流圖”、“IDFF圖”、“數(shù)據(jù)流程圖”或其他專業(yè)圖形分析圖示等。
78、 每個小節(jié)中的第二部分采用rational公司的rose2000作為工具繪制用例(use case)圖和順序(sequence)圖。
79、在這里采用rose工具是作為繪圖分析工具使用,對需求的描述和分析并不代表我們的設計采用UML標準和面向對象的設計,具體分析人員應當根據(jù)實際的用戶需求描述繪制順序圖,而并不著重考慮對象的分析限制。
80、需求變更的處理原則:獲得批準的需求變更,需要在《需求分析》中有所體現(xiàn)。
81、增加的需求,需直接從本章尾部順序添加,相應的小節(jié)編號也需要依次增加。
82、例如:本章小節(jié)為5.1—5.5,增加的需求小節(jié)編號則為5.6。
83、刪除的需求,不需要將相應需求直接從《需求分析》中刪除,而只需在相應需求小節(jié)上注明刪除,并標出《需求變更單》編號。
84、修改的需求,可在相應的需求小節(jié)直接修改。
85、所有對《需求分析》內容的修改必須在修改歷史中留有記錄。
86、4.1 業(yè)務名稱14.1.1 角色/功能定義【說明】根據(jù)會議紀要、小組討論,確定系統(tǒng)中的角色(角色可以為外部系統(tǒng)或系統(tǒng)用戶),和功能,并給出相應的定義或解釋。
87、4.1.2 圖形分析【說明】本節(jié)主要描述相應業(yè)務的用例圖和順序圖的內容??? 統(tǒng)一建模語言(UML)是一個通用的可視化建模語言,用于對軟件進行描述、可視化處理、構造和建立軟件系統(tǒng)制品的文檔。
88、它記錄了對必須構造的系統(tǒng)的決定和理解,可用于對系統(tǒng)的理解、設計、瀏覽、配置、維護和信息控制。
89、UML適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應用領域以及各種開發(fā)工具,是一種總結了以往建模技術的經驗并吸收當今優(yōu)秀成果的標準建模方法。
90、在本需求模板中我們選取的是UML視圖來輔助進行圖形需求分析,選用Rational公司的ROSE工具完成。
91、在需求分析過程需要完成結構分類中的用例分析,繪制用例圖;對用例的動態(tài)行為進行交互分析,描述執(zhí)行系統(tǒng)功能的各個角色之間相互傳遞消息的順序關系,繪制順序圖。
92、在這里請作者將制作的用例圖和順序圖拷貝到本文檔中。
93、基本成分:用例(use case)、用例視圖(use case view)、角色(role、actor)、順序圖(sequence diagram)、協(xié)作圖(collaboration diagram)。
94、模板和命名:為更好地使用ROSE圖形分析工具,我們設定一個基本的分析模板,文件名為lansoftmdl.mdl。
95、該文檔涉及項目開發(fā)的需求、概設和詳設3個階段,在需求階段主要完成模板中用例視圖(use case view)規(guī)定完成的部分。
96、在項目中使用該模板后生成的mdl文件納入文檔的配置管理,具體命名參照SEMP體系的命名規(guī)定。
97、修改歷史記入文檔開始部分的“mdl文檔修改歷史表”中。
98、【ROSE使用要求】 要求使用ROSE工具時必須完成模板和使用要求中規(guī)定完成的內容,在完成基本內容的基礎上,可以根據(jù)需要增加部分內容。
99、2、 在公司沒有購買確定版本的ROSE以前,使用的ROSE版本應在項目開始前在項目組規(guī)定好,并由配置管理員負責配置。
100、3、 在用例視圖(use case view)中建立一個名稱為main的主用例圖(use case diagram),具體內容應當包括所有用例圖的全部內容,具體應用時還可以根據(jù)情況建立多個用例圖(use case diagram)。
101、4、 在用例視圖中請采用中文對所有的角色(actorole)進行命名。
102、其中角色必須在雙擊該對象圖后,詳細填寫該角色的描述(documentation)和該角色代表的角色數(shù)量(detail-multiplic)。
103、5、 在用例視圖中請采用中文對所有的用例(use case)進行命名。
104、命名中在一般的中文概括前應增加代表本節(jié)編號的部分,如“1.用戶認證”,順序編號。
105、其中用例必須在雙擊該對象圖后,詳細填寫該用例的描述(documentation)。
106、6、 在每個用例下必須組織建立相應的順序圖(sequence diagram),對于一個用例可以包含多個順序圖(sequence diagram),各個順序圖(sequence diagram)的命名需在一般的中文概括前增加代表本節(jié)編號的部分,如“1.1用戶認證”,順序編號,其中第一個1代表所屬的用例,第二個1代表順序圖(sequence diagram)的編號。
107、產生順序圖的數(shù)量根據(jù)說明需求的具體要求設定。
108、其中順序圖中的各個對象消息(object message)必須在雙擊該對象圖后,詳細填寫該對象消息(object message)的描述(documentation)。
109、4.1.3 數(shù)據(jù)存儲需求【說明】根據(jù)會議紀要、小組討論,對于在需求調研中有關的數(shù)據(jù)實體對象或數(shù)據(jù)實體信息,應當根據(jù)需要提出可能數(shù)據(jù)類型和數(shù)據(jù)長度以及單位量綱的記錄或建議。
110、5 運行環(huán)境【說明】本章只提出運行環(huán)境的邏輯結構,物理結構將在《概要設計說明書》中給出。
111、??????? 容許提出幾種可選方案。
112、5.1 硬件平臺【說明】指出本應用軟件適用的主機/服務器與終端/工作站的技術指標、基本配置、接口特點、特殊約定等。
113、應盡可能地說明上述設備在各級用戶機構預計的分布狀態(tài)。
114、5.2 網絡平臺【說明】選型標準、網絡類型、基本部件、接口情況、對綜合布線的要求、限制條件等。
115、應畫出網絡(廣域網、局域網)的拓撲結構圖,說明后者對前者的接入方式。
116、5.3 軟件平臺【說明】操作系統(tǒng)的名稱、生產廠家、版本號等。
117、??????? 數(shù)據(jù)庫的名稱、生產廠家、版本號等。
118、??????? 數(shù)據(jù)庫設計工具的名稱、生產廠家、版本號等。
119、??????? 網絡通信協(xié)議的名稱、生產廠家、版本號等。
120、??????? 前端開發(fā)工具的名稱、生產廠家、版本號等。
121、??????? 測試開發(fā)工具的名稱、生產廠家、版本號等。
122、??????? 現(xiàn)場運行時需要的工具軟件的名稱、生產廠家、版本號等。
123、??????? 配置管理工具軟件的名稱、生產廠家、版本號等。
124、6 附錄【說明】列出基礎素材中的文件、報表、單據(jù)等的樣張,再附上必要的注釋。
125、如果條件成熟,可以把數(shù)據(jù)字典(data dictionary)作為附件列于后。
126、6.1 電子文檔編寫方式與使用工具【說明】編寫要求、工具名、版本號、操作系統(tǒng)平臺。
127、使用多種工具時,應分別說明。
128、形如:??????? Microsoft Word 97 for Windows 95/98??????? Power Designer 6.0 for Windows 95/98??????? Rational Rose 98 for Wintel??????? Visio或Power Point 97 for Windows 95/986.2 定義說明與符號【說明】包括對專用術語及縮略語的解釋、所用到的圖(如use case、sequence圖)之圖符的表示與解釋等。
129、6.3 參考資料【說明】格式:作者,[版本號,]資料來源,日期 [,起止頁號] 。
130、其中,《質量保證計劃》是必選的參考資料。
131、6.4 有關表格清單【說明】列出用戶提供的素材,加上我們積累的有關文件,作為系統(tǒng)分析的基礎。
132、在這里除系統(tǒng)內部沒有用戶參與的需求分析工作外,必須包括一個以上的用戶訪談紀要、用戶確認簽名文件以及用戶訪談計劃等文件的列表。
133、在列表中的文件應當作為附件與需求文檔共同納入配置管理。
本文分享完畢,希望對大家有所幫助。
標簽:
免責聲明:本文由用戶上傳,如有侵權請聯(lián)系刪除!