需求分析過程指南Version0.1修訂歷史日期版本描述作者2010-09-110.1需求分析過程指南初稿譚勇

目錄TOC\o"1-3"\h\z1 緒言和目標 31.1 目的 31.2 范圍 31.3 定義及縮寫 31.4 參考 32 角色和職責 33 進入標準 34 輸入 35 過程 45.1 需求研發 45.2 變更控制 46 輸出 47 退出標準 48 控制機制 49 度量 4

緒言和目標目的本文檔為軟件項目開發中需求分析工作提供了一個可遵循的規范標準，通過本規范的使用可以提高需求分析工作的質量、可管理性、可跟蹤性和可維護性，促進在業務部門、技術部門和開發商之間的對系統需求的充分的共同理解，提高項目的質量和用戶滿意度。范圍本文檔主要面向的讀者和使用人員是：管理應用開發的有關人員，開發商的設計開發人員。文檔概述本文檔描述了軟件項目開發中，需求分析工作應遵循的過程規范、基本原則和可選擇的需求分析方法。定義及縮寫縮寫定義需求系統必須滿足的條件和實現的功能需求管理對系統需求進行引入、組織和文檔化的一種系統化的方法與步驟，以及建立和維護開發人員與業務部門之間關于系統需求變更的確認的過程參考文檔名標題《軟件工程——實踐者的研究方法》需求分析過程標準需求管理流程分為四個階段：階段工作內容提交成果責任人確認人1業務需求調研《業務需求說明書》需求管理人員業務部門負責人2確定系統需求《系統需求說明書》需求管理人員、系統架構管理人員技術管理部門負責人3詳細需求調研和需求分析《系統需求規格說明書》需求管理人員、系統架構管理人員、系統開發商業務部門項目經理、技術管理部門項目經理4需求變更管理《系統變更單》需求管理人員、系統架構管理人員、系統開發商業務部門負責人、技術管理部門負責人第一階段主要對應于業務部門確定的業務需求。第二階段主要對應于技術管理部門確定的系統范圍和系統需求。前兩個階段對應于項目合同簽訂前的活動，需求管理人員必須完成制定系統的高層需求的工作。第三階段主要對應于系統開發商對業務需求和系統需求的細化和分析，是項目合同簽訂后的活動。第四階段主要對應于前三階段的提交成果產生基線版本后需要對需求內容進行修改時的活動，是貫穿于系統整個生命周期的活動。因為需求涉及從高到低的不同的概括層次，出于分工的需要，需求管理人員將持續維護的高層需求，并管理開發商維護系統的詳細需求。業務需求調研業務需求反映：業務部門對系統高層次的目標要求；用戶對系統使用和運行方式的重要規定；業務涉及的組織機構；主要的業務流程和參與角色；重要的影響到系統的外部約束和假設（如必須遵從的標準、規范，與其他部門的接口，其它關聯的系統，和業務有關的法律、法規等）。業務需求調研階段產生的提交成果為《業務需求說明書》。需求管理人員制訂需求調研計劃需求管理人員與業務部門有關人員會談，了解業務部門對系統高層次的目標要求，并共同確定：1）需求信息（包括組織機構信息、標準、規范、法律、法規、與其他部門和業務的接口、其它關聯的系統等）的獲得途徑和時間進度，這部分信息的獲取一般采用資料收集的手段；2）要進行調研的主要業務流程、指定的描述流程的業務人員和時間安排，提供這部分調研一般采用與有關業務人員面談的手段。3）需求調研計劃納入到《項目工作計劃》中。需求管理人員調研業務流程將要涉及到的業務流程明確下來之后，需求管理人員在業務部門的協調下，按計劃調研確定每一個業務流程中的參與人員角色、每個角色所執行的活動、在活動中所使用的業務實體、以及在活動中要遵循的一些業務規則。調研結果填寫在《需求調研表》中。需求管理人員撰寫《業務需求說明書》需求管理人員通過對前一階段業務需求調研結果的整理，形成《業務需求說明書》。業務部門負責人確認《業務需求說明書》業務部門負責人審閱（或安排相關業務人員審閱）并簽字確認《業務需求說明書》后，作為一個基線版本，將不允許直接改動，除非通過正規的變更流程。當有較大的變更時，應創建新的基線版本。確定系統需求需求管理人員、系統架構管理人員，根據用戶業務需求，結合相關技術約束條件，確定將來系統所要提供的高層的、概括的功能特性，將來系統所要具有的非功能特性，系統的用戶界面特性，系統的運行環境，系統設計需遵循的技術標準和原則，系統必須提供的接口等。通過《系統需求說明書》，參與各方都能理解將來系統的概況，并且一致同意將來系統就按照《系統需求說明書》的要求來開發。非功能特性可包括：性能指標；可靠性指標；可維護性；可用性；靈活性；可移植性；可重用性；可測試性；易用性。確定系統需求階段產生的提交成果為《系統需求說明書》。需求管理人員和系統架構管理人員根據業務需求，規劃新系統需求管理人員和系統架構管理人員根據《業務需求說明書》的內容，結合技術條件的約束和要求，分析需要并可能構建一個什么樣的系統來解決業務部門的問題和實現業務部門的目標，將系統的主要的功能特性、非功能性需求以及其它一些約束條件明確定義下來，作為對系統的完整定義。這一定義是高層的、概括的，偏重于整體架構和關鍵特性。需求管理人員和系統架構管理人員編寫《系統需求說明書》在《系統需求說明書》中，可包括問題說明、系統定位、系統功能特性、系統非功能性需求等。主要業務部門和技術管理部門確認《系統需求說明書》《系統需求說明書》的內容須經由其涉及到的主要業務部門和技術管理部門負責人的確認后，作為一個基線版本，將不允許直接改動，除非通過正規的變更流程。當有較大的變更時，應創建新的基線版本。《系統需求說明書》和《業務需求說明書》一起，定義了系統開發商必須滿足的要求。詳細需求調研和需求分析系統開發合同簽訂后，開發商在理解了《業務需求說明書》和《系統需求說明書》的內容以后，為了進行系統設計，一般還需要進行詳細的業務需求調研，并進行需求分析，撰寫《系統需求規格說明書》。這一階段的工作在需求管理人員的管理下進行。用戶項目經理和開發商項目經理討論《業務需求說明書》和《系統需求說明書》的內容用戶方（包括業務部門和技術部門）與開發方須對《業務需求說明書》和《系統需求說明書》達成一致的理解，盡早發現問題并經過探討后可進行必要的變更。由此雙方形成對要開發的系統的進一步的共識。用戶項目經理和開發商項目經理制訂詳細需求調研計劃需求管理人員、開發商項目經理共同確定：詳細需求信息（包括組織機構信息、標準、規范、法律、法規、與其他部門和業務的接口、其它關聯的系統等）的獲得途徑和時間進度，這部分信息的獲取一般采用資料收集的手段；要進行調研的主要業務流程、指定的描述流程的業務人員和時間安排，提供這部分調研一般采用與有關業務人員面談的手段。詳細需求調研計劃納入到《項目工作計劃》中。開發商詳細需求定義人員調研業務流程將要涉及到的業務流程明確下來之后，開發商詳細需求定義人員在業務部門的協調下，按計劃調研確定每一個業務流程中的參與人員角色、每個角色所執行的活動、在活動中所使用的業務實體、以及在活動中要遵循的一些業務規則。調研結果填寫在《需求調研表》中。開發商整理詳細需求調研結果，初步確定《系統需求規格說明書》的框架內容根據對《業務需求說明書》和《系統需求說明書》的共同理解，并整理詳細需求調研的結果，開發商可由此提出發現的問題，并提出變更《系統需求說明書》的有關內容。開發商并初步確定《系統需求規格說明書》的框架內容，包括建立用例模型。開發商開發界面原型開發商根據當前對業務需求和系統需求的理解，開發完成初步的界面原型，以反映出要開發的系統的概念框架和使用模式。開發商詳細需求定義人員用例模型和界面原型為基礎與業務部門用戶溝通開發商詳細需求定義人員用例模型和界面原型為基礎與業務部門用戶溝通，進一步了解業務部門的要求和期望。開發商詳細需求定義人員細化《系統需求規格說明書》的內容詳細需求定義人員根據對業務部門的調研結果，對軟件需求和界面原型進行完善，最終明確定義以用例表達的功能性需求和非功能性需求，細化《系統需求規格說明書》的內容。業務部門、技術管理部門評審《系統需求規格說明書》召開評審會議，《系統需求規格說明書》的內容須經由其涉及到的業務部門以及技術管理部門的一致確認后，作為一個基線版本將不允許直接改動，除非通過正規的變更流程。當有較大的變更時，應創建新的基線版本?！断到y需求規格說明書》的內容完整地定義了軟件開發商必須滿足的要求。需求變更管理需求變更的目的是保證對需求提出的變更申請以一種可控的、受管理的方式納入到軟件開發活動中。需求變更通過《系統變更單》來管理。需求變更申請人提出變更申請需求變更申請人可以是業務部門用戶、系統維護人員、設計人員、開發人員或測試人員等任何發現系統的問題或改進的機會的人，通過填寫《系統變更單》，來提交變更申請給需求管理人員。需求管理人員和系統架構管理人員分析需求變更的影響和可行性需求管理人員和系統架構管理人員評估變更對系統性能、成本、進度和風險的影響，判斷變更的合理性、可行性，并核定工作量影響。將有關信息填寫到《系統變更單》。業務部門負責人、技術管理部門負責人審核變更申請業務部門負責人、技術管理部門負責人根據需求變更申請人、需求管理人員和系統架構管理人員在《系統變更單》中提供的信息，審核變更的必要性、合理性和可行性，決定是否執行變更，并填寫審核意見到《系統變更單》。執行變更變更通過審核后，需求管理人員根據跟蹤關系，組織開發商執行對《系統需求規格說明書》以及設計文檔、測試文檔和用戶手冊等受影響的內容的修改，并提交新版本給文檔管理人員。開發商并執行對軟件代碼或系統配置的修改，在測試管理人員的組織下對新系統進行測試，并部署到生產環境中。需求分析原則必須表示和理解問題的信息域在開始建立分析模型前先理解問題。人們通?？偞嬖诩庇谇蟪傻膬A向，甚至在問題被很好地理解前，這經常會導致產生一個解決錯誤問題的優美軟件的誕生。必須定義軟件將完成的功能必須表示軟件的行為(作為外部事件的結果必須劃分描述信息、功能和行為的模型，從而使得可以以層次的方式揭示細節分析過程應該從要素信息移向細節實現開發原型使得用戶能夠了解將如何發生人機交互。因為人們一般對軟件質量的感覺經?；趯缑妗坝押眯浴钡母杏X，因此，強力推薦使用原型方法(以及相應產生的迭代)記錄每個需求的起源及原因這是建立回溯到客戶的可追蹤性的第一步。使用多個需求視圖建立數據、功能和行為模型，為軟件工程師提供三種不同的視圖，這將減少忽視某些東西的可能性，并增加識別不一致性的可能性。給需求賦予優先級過短的時限可能使每個軟件需求得于實現的可能性減小，如果采用增量過程模型(第2章)，必須標識那些將在第一個增量中要交付的需求。努力刪除含糊性因為大多數需求以自然語言描述，存在含糊性的可能，正式的技術復審是發現并刪除含糊性的一種方法。需求分析方法結構化分析創建實體—關系圖實體—關系圖使得軟件工程師可以完整地刻劃系統輸入和輸出的數據對象、定義這些對象的性質的屬性、以及對象間的關系。與分析模型中的其他元素一樣，ERD是以迭代的方式構造的。可以采用以下的方法：在需求搜集的過程中，要求客戶列出應用軟件或業務過程涉及到的“事物”。這些“事物”演化為一組輸入和輸出的數據對象，以及生產和消費信息的外部實體。一次考慮一個對象，分析員和客戶定義這個對象和其他對象間是否存在連接(在這個階段沒有命名)。當連接存在時，分析員和客戶應創建一個或多個對象—關系對。對每個對象—關系對，考察其基數和形態。迭代地進行步驟2到步驟4，直至定義了所有的對象—關系對。在這個過程進展中發現遺漏是很正常的。當進行若干次迭代時，將總是不斷地增加新的對象和關系。定義每個實體的屬性。形式化并復審實體—關系圖。重復步驟1到步驟7，直到數據建模完成。創建數據流圖(DFD)數據流圖(DFD)使得軟件工程師可以同時開發信息域和功能域的模型。當DFD被精化到較細的級別時，分析員對系統進行了隱式的功能分解，這樣完成了第四條操作性分析原則。同時，當數據流過體現應用的加工時，DFD的精化導致了數據的相應精化。第0層的數據流圖應將軟件/系統描述為一個泡泡；應仔細地標記主要的輸入和輸出；通過隔離要表示在下一層中的候選加工、數據對象和存儲而開始精化過程；所有的箭頭和泡泡應使用有意義的名稱標記；當從一個級別到另一個級別時要維護“信息流連續性”；一次精化一個泡泡。經常存在一種使數據流圖過分復雜的自然趨勢，當分析員試圖過早地顯示過多的細節或在信息流中表示軟件的過程時，會發生這種情況。DFD的精化可以連續進行，直至每個泡泡只執行一個簡單的操作，即直至每個泡泡所代表的加工執行一個可以很容易地實現為程序組成部分的功能。創建控制流模型對于事件驅動的應用軟件，產生控制信息，而不是報告或顯示值；處理信息時非常關注時間和性能。這些應用軟件在數據流建模以外還需要使用控制流建模。創建CFD的方法，從數據流模型中“剝去”所有的數據流箭頭，然后向圖中加入事件和控制項(虛線箭頭)，并顯示一個到控制規約的“窗口”(豎短線)。以以下方法選擇潛在的候選事件：·列出所有被軟件“讀取”的傳感器。·列出所有的中斷條件?！ち谐鏊斜徊僮髡唛_動的“開關”。·列出所有的數據條件?！せ貞泴庸⑹鲞M行的名詞—動詞掃描，回顧所有作為可能的CSPEC的輸入/輸出的“控制項”?！ねㄟ^標識其狀態描述系統的行為；標識這些狀態是如何達到的，并定義狀態間的變遷?！りP注可能的省略——這是在刻劃控制時非常普遍的錯誤(例如，問“有什么其他的途徑可以達到這個狀態或從它離開嗎？”)?？刂埔幖s(CSPEC)控制規約(CSPEC)在兩個不同的方面表示系統的行為(在它被引用的層次上)，CSPEC包括一個狀態變遷圖(STD)，它是行為的“順序規約”；CSPEC還包括加工激活表(PAT)——行為的“組合規約。通過研究STD，軟件工程師可以確定系統的行為，更重要的是，可以確定被描述的行為中是否存在“空洞(ho1e)”。一種不同的表示行為的模式是“加工激活表”(PAT)，PAT在加工的語境中，而不是在狀態的語境中，表示STD中包含的信息，即這張表指明當事件發生時，流模型中的哪些加工(泡泡)被激活。PAT可以作為那些必須確立執行者來控制在該層次上表示的加工的設計者的指南。加工規約(PSPEC)加工規約(PSPEC)用來描述出現在求精過程的最終層次的所有流模型加工。加工規約的內容可以包括敘述性正文、加工算法的“程序設計語言”(PDL)描述①、數學方程、表、圖或圖表。為流模型中的每個泡泡提供了PSPEC，軟件工程師就創建了一個“小規約”，它可以作為創建軟件需求規約的第一步，并作為對實現加工的程序成分進行設計的指南。數據字典分析模型中包含對