1、系統工程之需求分析趙熙朝 編者按：現在人們越來越認識到軟件工程在軟件開發中的重要作用。目前國內軟件在開發中還沒有 對軟件開發的過程進行明確規定，文檔不完整，也不規范，軟件項目的成功往往歸功于軟件開發組 的一些杰出個人或小組的努力。這種依賴于個別人員上的成功并不能為全組織的軟件生產率和質量 的提高奠定有效的基礎，只有通過建立全過程的改善，采用嚴格的軟件工程方法和管理，并且堅持 不懈地付諸實踐，才能取得全組織的軟件過程能力的不斷提高，使軟件開發更規范合理。我們馬上就要進入WTO，因此軟件開發也要與國際接軌，只有這樣才能提高我們在項目管理水平，最終開發出高質量的軟件。綜述軟件工程中包含需求、設計、編

2、碼和測試四個階段,其中需求工程是軟件工程第一個也是很重要的一個階段，本文以醫院管理系統為例詳細介紹了需求工程的構成和進行方法。一、需求開發需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規大小和特點等實際情況我們應該自己確定合適的步驟的步驟，當然應按照項目的1 需求獲取確定需求開發過程確定如何組織需求的收集、分析、細化并核實的步驟，并將它編寫成文檔。2 需求分析繪制關聯圖、創建開發原型、分析可行性、確定需求優先級、為需求建立模型、編寫數據字典、應用質量功能調配。3 編寫規格說明書項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求4 需求驗證審查需求

3、文檔、依據需求編寫測試用例、編寫用戶手冊、確定合格的標準二、需求管理需求開發的結果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規格說明及相關分析文檔就定義了開發工作的需求基線。模型。經評審批準，這些、綜述軟件工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟件工程第一個也是很重要的一個階段，本文以醫院管理系統為例詳細介紹了需求工程的構成和進行方法。首先我們必須了解需求工程和其他項目過程的關系:項目跟蹤和控制過程軟件需求包括三個不同的層次-業務需求、用戶需求和功能需求-也包括非功能需求 ： 業務需說明了提供給客戶和產品開發商的新系統的最初利益標要求，它們在項目視圖與范圍文檔中予以說明

4、，反映了組織機構或客戶對系統、產品高層次的目；用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明；功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。需求工程分為了需求開發和需求管理兩個階段：下面就以這兩個階段說明：二， 需求開發需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。以下列岀和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己確定合適的步驟。1. 需求獲取：1 ）確定需求開發過程：確定需求開發過程確定如何組織需求的收集、分析、細化并核實的步驟，并將它編寫成文檔。對重要的步驟要給予一

5、定指導，這將有助于分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行。2 ）編寫項目視圖和范圍文檔：項目視圖和范圍文檔應該包括高層的產品業務目標，所有的使用實例和功能需求都必須遵從能達到的業務需求。項目視圖說明使所有項目參與者對項目的目標能達成共識。而范圍則是作為評估需求或潛在特性的參考。12345& |A 業務需求業務目標客尸或市場提供給客戶的衛首旦孫值呂頃目視圖的解決項目觀圖陳主要特性假設和依賴述環境C 砲圍和局限性苜次發行的隨后發行的局限性和專范圍疤圍用性|D 業務環境客戶概貌項目就先級E 產品成功的因素表 1 項目視圖和范圍文檔的模板a . 1背景在這一部分，總結新

6、產品的理論基礎，并提供關于產品開發的歷史背景或形勢的一般性描述。a. 2 業務機遇 描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市 場和信息系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案， 并指出所建議的產品為什么具有吸引力和它們所能帶來的競爭優勢。a. 3 業務目標用一個定量和可測量的合理方法總結產品所帶來的重要商業利潤把重點放在給業務的價值上。a. 4 客戶或市場需求 描述一些典型客戶的需求，包括不滿足現有市場上的產品 或信息系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出 現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能運行的軟、硬件平臺。

7、a.5提供給客戶的價值確定產品給客戶帶來的價值，并指明產品怎樣滿足客戶的需要。a.6 業務風險 總結開發（或不開發）該產品有關的主要業務風險，例如市場競 爭、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測 風險的嚴重性，指明你所能采取的減輕風險的措施。b. 1 項目視圖陳述編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場、企業框架、組織的戰略方向和資源局限性為基礎。b. 2 主要特性包括新產品將提供的主要特性和用戶性能的列表。強調的是區別于以往產品和競爭產品的特性。可

8、以從用戶需求和功能需求中得到這些特性。b. 3 假設和依賴環境在構思項目和編寫項目視圖和范圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。c. 1 首次發行的范圍總結首次發行的產品所具有的性能。描述了產品的質量特性，這些特性使產品可以為不同的客戶群提供預期的成果。c. 2 隨后發行的范圍如果你想象一個周期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，并期待隨后版本發行的日期。c. 3 局限性和專用性明確定義包括和不包括的特性和功能的界線是處理范圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能d. 1 客戶概貌客戶概述明確了

9、這一產品的不同類型客戶的一些本質的特點，以及目標市場部門和在這些部門中的不同客戶的特征。d. 2 項目的優先級 一旦明確建立項目的優先級，風險承擔者和項目的參與者就 能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟件項目的 五個方面：性能、質量、計劃、成本和人員。e. 產品成功的因素明確產品的成功是如何定義和測量的，并指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的范圍內的事務，還要包括外部因素。如果可能，可建立測量的標準用于評價是否達到業務目標.3）用戶群分類：產品的用戶在很多方面存在著差異，例如：用戶使用產品的頻度、他們的應用領域和計算機系統知識、他們所使用的

10、產品特性、他們所進行的業務過程、他們在地理上的布局以及他們的訪問優先級。根據這些差異，你可以把這些不同的用戶分成小組。用戶類不一定都指人，你可以把其它應用程序或系統接口所用的硬件組件也看成是附加用戶類的成員。以這種方式來看待應用程序接口，可以幫助你確定產品中那些與外部應用程序或組件有關的需求。將用戶群分類并歸納 各自特點為避免出現疏忽某一用戶群需求的情況，要將可能使都有所差異。詳細描述出它們的個性特點及任務狀況，將有助于產品設計。4）選擇產品代表：擇每類用戶的產品代表為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表并能作出決策。這對于內部信息系統的開發是最易實現的，因為此時，用

11、戶就是身邊的職員。而對于商業開發，就得在主要的客戶或測試者中建立起良好的合作關系，并確定合適的產品代表。他們必須一直參與項目的開發而且有權作出決策。每一個產品代表者代表了一個特定的用戶類，并在那個用戶類和開發者之間充當主要的接口。5）建立核心隊伍：建立起典型用戶的核心隊伍把同類產品或你的產品的先前 版本用戶代表召集起來，從他們那里收集目前產品的功能需求和非功能需求。這樣 的核心隊伍對于商業開發尤為有用，因為你擁有一個龐大且多樣的客戶基礎。與產 品代表的區別在于，核心隊伍成員通常沒有決定權。6）確定使用實例：讓用戶代表確定使用實例從用戶代表處收集他們使用軟件 完成所需任務的描述 - 使用實例，討

12、論用戶與系統間的交互方式和對話要求。在編 寫使用實例的文檔時可采用標準模版，在使用實例基礎上可得到功能需求。一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。 因此，一個使用實例是相關的用法說明的集合，并且一個說明是使用實例的例子。 在描述時列出執行者和系統之間相互交互或對話的順序。當這種對話結束時，執行 者也達到了預期的目的。對于一些復雜的使用實例，畫出圖形分析模型是有益的，這些模型包括數據流系圖、狀態轉化圖、對象類和聯系圖。程圖、實體關使用實例的描述并不向開發者提供他們所要開發的功能的細節。為了減少這種 不確定性，你需要把每一個使用實例敘述成詳細的功能需求。每一個使用實例

13、可引 伸出多個功能需求，這將使執行者可以執行相關的任務；并且多個使用實例可能需 要相同的功能需求。使用實例方法給需求獲取帶來的好處來自于該方法是以任務為 中心和以用戶為中心的觀點。比起使用以功能為中心的方法，使用實例方法可以使用戶更清楚地認識到新系統允許他們做什么。每一個使用實例都描述了一個方法，用戶可以利用這個方法與系統進行交互， 從而達到特定的目標。使用實例可有效地捕捉大多數所期望的系統行為，但是你可 能有一些需求，這些需求與用戶任務或其他執行者之間的交互沒有特定的關系。這 時你就需要一個獨立的需求規格說明。7）召開應用程序開發聯系會議：召開應用程序開發聯系會議應用程序開發聯 系會議是范圍

14、廣的、簡便的專題討論會，也是分析人員與客戶代表之間一種很好的 合作辦法，并能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客 戶與開發人員間的合作伙伴關系付諸于實踐。8）分析用戶工作流程：分析用戶工作流程觀察用戶執行業務任務的過程。畫一張簡單的示意圖（最好用數據流圖）來描繪出用戶什么時候獲得什么數據，并怎樣使用這些數據。編制業務過程流程文檔將有助于明確產品的使用實例和功能需求。你甚至可能發現客戶并不真地需要一個全新的軟件系統就能達到他們的業務目標。9）確定質量屬性：確定質量屬性和其它非功能需求在功能需求之外再考慮一下非功能的質量特點，這會使你的產品達到并超過客戶的期望。對系統如何能很

15、好地執行某些行為或讓用戶采取某一措施的陳述就是質量屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。你將要和用戶一起商討精確定義他們模糊的和主觀言辭的真正含義。10）檢查問題報告：通過檢查當前系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新產品或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。11）需求重用：跨項目重用需求如果客戶要求的功能與已有的產品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。2 需求分析1）繪制關聯圖：繪制系統關聯圖是

16、用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。2）創建開發原型：創建用戶接口原型當開發人員或用戶不能確定需求時，開發一個用戶接口原型，這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。3）分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項需求 實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外 界因素的依賴和技術障礙。4）確定需求優先級：確定需求的優先級別應用分析方法來確定使用實例、產 品特性或單項需求實現的優先級別。

17、以優先級為基礎確定產品版本將包括哪些特性 或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本 計劃中作出需要的變更。5）為需求建立模型：為需求建立模型需求的圖形分析模型是軟件需求規格說 明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致 的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、 對話框圖、對象類及交互作用圖。6）編寫數據字典：創建數據字典數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包

18、括數據字典組件。7）應用質量功能調配：使用質量功能調配質量功能調配是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。它將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備。3 編寫規格說明書項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。軟件需求規格說明闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件,

19、它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細節。1）采用軟件需求規格說明模版：采用需求規格說明書模板在你的組織中要為編寫軟件需求文檔定義一種標準模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統一的結構。注意，其目的并非是創建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。許多組織一開始都采用 IEEE 標準 830-1998 （ IEEE 1998 ）描述的需求規格說明書模板。要相信模板

20、是很有用 的，但有時要根據項目特點進行適當的改動。123456闌 Is目的文檔約定預期的讀著和閱產品的范參莆文獻圍El 綜合描述產品的前產品的功用戶類和特征運行環境設計和實現上假設和依賴景能的限制附錄U 外部接口需求用戶界面硬件接口軟件接口通信接口附錄附錄D 系統特性說明和優獄勵加向應功能需求先級序列E 其它菲功能性能需求安全設施安全性需求軟件質量業務規則用戶文檔需求需求屬性F 其它需求G 附件詞匯表分析模型待確定間題的列表4. 需求驗證1）審查需求文檔：對需求文檔進行正式審查是保證軟件質量的很有效的方 法。組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小 組，對需求規格說明

21、書及相關模型進行仔細的檢查。另外在需求開發期間所做的非 正式評審也是有所裨益的。2）依據需求編寫測試用例：根據用戶需求所要求的產品特性寫出黑盒功能測 試用例。客戶通過使用測試用例以確認是否達到了期望的要求。還要從測試用例追 溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結果與測試用例相一致。 同時，要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。3）編寫用戶手冊：在需求開發早期即可起草一份用戶手冊，用它作為需求規格說明的參考并輔助需求分析。優秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而輔助需求如質量屬性、性能需求及對用戶不可見的功能則在需求規格說明書中予以說明。4

22、）確定合格的標準：確定合格的標準讓用戶描述什么樣的產品才算滿足他們他們使用的。將合格的測試建立在使用情景描述或使用實例的基礎之上。的要求和適合二、需求管理需求開發的結果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規格說 明及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線。這個基 線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定。需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。1 確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業化的問題跟蹤工具都能支持變

23、更控制過程。2?建立變更控制委員會，組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設置實現的優先順序，制定目標版本。3 ?進行需求變更影響分析，應評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。明確與變更相關的任務并評估完成這些任務需要的工作量。通過這些分析將有助于變更控制委員會作出更好的決策。影響分析可以提供對建議的變更的準確理解，幫助做出信息量充分的變更批準決策。通過對變更內容的檢驗，確定對現有的系統做出是修改或拋棄的決定，或者創建新系統以及評估每個任務的工作量。進行影響