1、需求分析方法一 需求分析概括需求分析應該先了解宏觀的問題，再了解細節的問題。一個應用軟件系統（記為 S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應于一個軟件子系統。S= D1, D2 , D,Dn問題域Di由若干問題（記為 P）組成，每個問題對應于子系統中的一個軟構件。Di = P1, P2, P3 ,Pn問題Pi有若干個行為（或功能，記為F）,每個行為對應于軟構件中的實現接口。Pj = F1, F2 , F3 ,Fk需求說明書應該對于那些只想了解宏觀需求的領導和需要了解細節的技術員都合適。在寫需求說明書時，應該注意兩個問題：1. 最好為每個需求注釋“為什么” ，這樣可

2、以讓程序員了解需求的本質， 以便選用最合適 的技術來實現此需求2. 需求說明不能有”二義性”，更不能前后矛盾。如果有二義性或前后矛盾，即要重新分 析此需求。需求分析方法論第一階段：“訪談式”第一階段是和具體用戶方的領導層、業務層人員的訪談溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢， 了解現有的組織架構、業務流程、硬件環境、軟件環境、現有 的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。實現手段：訪談、調查表格 輸出成果：調查報告、業務流程報告 第二階段：“誘導式”結合第一階段的基本信息， 做出簡單的用戶流程頁

3、面， 同時結合以往的項目經驗對用戶采用 誘導式，啟發式的調研方法和手段， 和用戶一起探討業務流程設計的合理性、準確性、 習慣 性。用戶可以操作簡單演示的DEMO感受整個業務流程的設計合理性、準確性等等問題，以及提出改進意見和方法。實現手段：誘導（拜訪） 、原型演示 輸出成果：調研分析報告、原型反饋報告、業務流程報告第三階段：“確認式”此階段在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段。這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，并能清晰地向用戶描述系統的業務流設計目標。通過審查，提出反饋意見，并對已經可接受的報告、文檔簽字確認。實現手段：拜訪（回顧、確認）

4、，提交業務流程報告、數據項表；原型演示系統輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（后三者可以統一歸 到需求分析報告中）后續的需求改進中，工作則基本集中在后兩個階段中。三需求工程需求過程諾求營理需求快態跟蹤需求幵發需求開發:1. 確定產品所期望的用戶分類。2. 獲取每類用戶的需求。3. 了解實際用戶任務和目標 以及這些任務所支持的業務需求。4. 分析源于用戶的信息以區別用戶 任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。5. 將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。6. 了解相關質量屬性的重要性。7. 商討實施優先級的劃分。8.

5、將所收集的用戶需求編寫成規格說明和模型。9. 評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前 將問題都弄清楚。需求分析需求分析是指通過對需求獲取中獲得的問題域的研究，獲得對該領域特性及存在其中的問題特性的透 徹理解并用文檔說明。? 不需要等到需求完全捕獲后開始，在“業務需求”充分理解下，并且收集了本質的“用戶需求”之后就可以開始進行需求分析? 交替進行，先把握“用戶需求”主要部分，然后在分析的基礎上引入系統級的需求（系統的涉 及與實現角度），并且分析模型，成為開發人員之間、開發人員與客戶之間達成共識的一個平 臺? 分析的基礎上，就會發現更多的不明確項，更多待

6、捕獲的信息，這時就可以生成第二次的需求 調研計劃、問題和素材編寫規約? 規格說明書是對需求分析結果的文檔化過程? 需求規約必須與實際開發緊密結合，否則很容易造成與開發脫離? 為需求規約定義統一的格式是一個很重要的工作? 規約內容必須嚴謹、正確、無歧義需求驗證? 不重視需求驗證工作會在系統交付時，客戶發現不是這樣的，導致不期望的需求變更? 提高需求質量的重要手段有：需求評審、需求確認和原型驗證需求方法之-原型開發需求分析層次需求層次內容業務需求反應組織機構或客戶對系統、產品高層次的目標要求。通常問題定義 就是業務需求用戶需求描述用戶使用產品必須要完成什么任務、怎樣完成，通過是在問題定 義的基礎上

7、進行訪談、調查、對用戶使用的場景進行整理，從而建立 從用戶角度的需求系統需求從系統的角度來說明軟件的需求，它就包括了用特性說明的功能需求，質量屬性以及其他非功能需求，還有設計約束1. 功能需求：系統必須完成的任務，以及怎樣完成這些任務。即為了向用戶提供有用的功能，必須完成的動作。2. 非功能需求：指產品必須具備的屬性或品質，如可靠性、性能、響 應時間、容錯性和擴展性。3. 設計約束：即限制條件或補充規約，通常是對解決方案的一些約束說明。例如必須運行在 unix操作系統之下（硬、軟件的約束）。，還應該得到市場客戶管理將項目大的目標整理提煉，戈U分為項目子目標，將其作為“項目的行動綱領” “項目發

8、起人”的認可，并且在此基礎上編寫“項目的目標和范圍文檔”需求分析迭代過程需求分析更正幷 A減少課差僞寫機約童罵需求捕獲需求捕獲明確業務需求：業務需求是整個系統最為宏觀層面的東 西”也就是項目的目標“；通常來說，業務需求是構 建在“項目發起人”的腦子里的；“業務需求歸可以分 為*產品丿項目目標和和“子目標描述兩個方面的內 容 理解業務流程t若項目較大或者業務較陌生：應進行業務建模;“如果業務較陌生：聘請領域專家*領域培訓; -如杲術語較多，易于混淆：業務術語表 無論如何，都應該建立跨部門職能流程圖用例模型用例模型一組織需求用例特性“用例描繪的場景（或事件流）展示了參與者如何使用 系統3這都應基于

9、系統要完成的任務及其重要性來決定 如何確定主要場景次要場景，以及需要多少場景I -用例的粒度問題很關鍵，既不能太丸也不能夠太小測試頊說胡WWhat to do用例星苦描述了愷用做什么曲罪如何做？AAtlors puinl of * kW用例的攤述琵否怵現了穆歸的視角丫VVilue for ctie atior?EEnli代 scrollLitio出例插述時間流鼻咅為-個完蹩的場景？建立用例模型一合并特性獲得用例特性書倒幵發人員fmks刑廉人易接到任務時.如過刺協鑑HI時袖（ 計超開始ti聞和計制結応時幣n項冃粉墀確認后.更釘 H和址排嚨ucuiAte務計它FKATOCi Jt人抽町氏直酣阪工件

10、任務的加處顧揺tfiSff 船悄1茨附戡UC01査詢他蟲枉務FE/CTg丹發人員可區柚據仟：務綸號*關變界 起止時間謖 鞋分類組令齊詢與魁計FEATWJ1K人員琳戰豪時記錄口己的H闔、慢慎-JTteit IV、 “耕停ii時、11停止計WT .右涉止時.嘎入任 夯騙號 吊務則樂揮八 工佯關艇牛C以型號分爲的多車 ）p自動生成開始時何、暫停時間.停止時間、總時從丫 甫效時風t總肘民-中斷時栓rmitfii訶彌t序食H動違掠翩喩極甘閭曲志t 停麗丁件*術施逼攤肌務僭刪。木飆暫存耐何nUC03.遠威詩間日比建立用例模型一繪制用例圖建立用例模型一簡要描述用例用例編號UCOI用例名稱填寫任務計劃用例彈述

11、齊發人員對項目經理安扌非給自己的工佟任務進行計劃.填八計 劃開姑吋問和計劃完成時間.主參與者開發人屍補充說明在境入計劃幵始吋間和計劃完成吋間吋，開發人員可以查詢與 該任務的關如字和關妁歷史任務的數培。建立用例模型一劃分用例優先級優先級用例1UCM 登錄系純系統便用的M他.并斗可feHJJft価源UC3管理啪皿息UC04設世工作包UB5分配J件任務UC01 壩寫任務計劃仔務伶理的完無流創是記錄中亦日志的 基礎UC03id親時間H 土系統檢心功陡2【JC07關閉作任務只兒肘杠傷信息進口更祈.而酸忤次ZUCW6.SrHftk UC5A.査耘，按對I IX安井進L優化.便任餌女？ 1臺攔化3UB2 査

12、詢歷史仃分致掛UB8統i卩貝目產能UC10毀汁團隊產詭対系扯氾釆的時何記禾迥行片效的利用， 必須而的M4能筋開反UCI2 管好用戶詢期nJ以迫過直接徨戳據障中寫值的方式 進行使用.卓后握01畀面操件即可理立用例複型一評地誦還ffl例ffim號uco用例第體記錄破間H土用似|戲述開変人員彳以必時*乙點自己的廿間U 丹耐訃r普停計時、.侔止金対、沁丸 止時-仗人蘭命編當q A縱M&M)工什芟優字1以H號分代的$個)U 詢2此井竹叭罰 福耳廳間停止M同.殆時米老貳時Me恵時晁沖嘶時兵卜二與善護岌人員條件用戶itA “褐廉算間H老”程片Eltfrfr轄次片何。芯海入贛福M垃S!1常妮盅孑訐0 訕屮和“

13、號卍悴仏性僅-S-fe*耳用氣HrAJt 卅*T斤城記*片姑M同*4彳*兀可同 -ft 材0 優見，ft 紓AT挨佃不年忙3al命冏戶血文條X” i*Q.用命常時問丸矢術待芥怖芮月樣劉駅歐稻年町同.井裏如 H “響甘眄河為網*具柴機&垛耘旻比兵住娛礦射規則弓約味葉.通忸沖會0初逵J*氏務喬，無貝葉冋H七丄的亠作，七乂札3 UR% pjrt*札材存時河目怎用戶界面設計|圉r ,-啊、彷r快竝JMH呻亠勢城亠7, r.f.航帝酊*.廣杠襯F.* kiijNiY-總擊叫覺圧-打曲屮于甘m u叭 fiJ-.H 時 a- CA 曲j3.5利用跟蹤關系業務需求T用戶需求T系統需求如果業務需求和用戶需求沒有

14、得到片項需求（用戶 需求和系統需求）的充分支持，那么軟件儒求規格 說明文檔就衣在不完備的缺陷=系統需求T用戶需求T業務需求如果不能依據跟蹤關系找到一條系統蠱求的前頂川 戶需求和前項業務需求,那么該需求就屬于非必要 的需求驗證需求分析將需求分析的結果還原為用戶場景，然后向用戶描述該場景的目的、任務、實現的方法，以此驗證是否正確。推薦的需求文檔格式1）業務名稱解釋2）需求背景及目標介紹3）用戶操作場景說明4）功能總覽：用列表的方式，逐項敘述對系統所提出的功能要求，說明輸入什么量、 經怎么樣的處理、得到什么輸出5）系統交互圖6）界面原型（對該系統的輸入、輸出數據類型、格式、數值范圍、精度的描述）7）

15、業務規則說明8）業務正常流流程：功能模塊，主要操作9）業務異常流處理：異常場景，錯誤提示；異常流轉軟件需求說明書1引言1. 1編寫目的說明編寫這份軟件需求說明書的目的，指出預期的讀者。1 . 2背景說明：a .待開發的軟件系統的名稱；b 本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡;C.該軟件系統同其他系統或其他機構的基本的相互來往關系。1 . 3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1 . 4參考資料列出用得著的參考資料，如：a 本項目的經核準的計劃任務書或合同、上級機關的批文；b .屬于本項目的其他已發表的文件；列出這些c.本文件中各處引用的文

16、件、資料、包括所要用到的軟件開發標準。文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來 源。2 任務概述2. 1目標敘述該項軟件開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發的背景材料。解釋被開發軟件與其他有關軟件之間的關系。如果本軟件產品 是一項獨立的軟件，而且全部內容自含，則說明這一點。如果所定義的產品是一個更 大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系， 為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和接口。I2. 2用戶的特點列出本軟件的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技

17、術專長，以及本軟件的預期使甩頻度。這些是軟件設計工作的重要約束2. 3假定和約束列出進行本軟件開發工作的假定和約束，例如經費限制、開發期限等。3 需求規定3. 1對功能的規定用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經怎樣的處理、得到什么輸出，說 明軟件應支持的終端數和應支持的并行操作的用戶數。3. 2對性能的規定3. 2. 1精度說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3. 2 . 2時間特性要求說明對于該軟件的時間特性要求，如對：a .響應時間；b.更新處理時間；c .數據的轉換和傳送時間；

18、d 解題時間；等的要求。3. 2 . 3靈活性說明對該軟件的靈活性的要求，即當需求發生某些變化時，該軟件對這些變化的適應能力，如：a. 操作方式上的變化；b. 運行環境的變化；c .同其他軟件的接口的變化；d.精度和有效時限的變化；e .計劃的變化或改進。對于為了提供這些靈活性而進行的專門設計的部分應該加以標明。3 . 3輸人輸出要求解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟 件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結 果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。3 . 4數據管理能力要求說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對 數據及其分量的存儲要求作出估算。3. 5故障處理要求列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。3. 6其他專門要求如用戶單位對安全保密的要求，對使用方便的要求，