軟體工程之需求分析(一)

文章目錄

• 軟體工程之需求分析(一)

軟體工程之需求分析(一)

(來源：http://www.yesky.com)

［編者按：］現在人們越來越認識到軟體工程在軟體開發中的重要作用。目前國內軟體在開發中還沒有對軟體開發的過程進行明確規定，文檔不完整，也不規範，軟體項目的成功往往歸功於軟體開發組的一些傑出個人或小組的努力。這種依賴於個別人員上的成功並不能為全組織的軟體生產率和品質的提高奠定有效基礎，只有通過建立全過程的改善，採用嚴格的軟體工程方法和管理，並且堅持不懈地付諸實踐，才能取得全組織的軟體流程能力的不斷提高，使軟體開發更規範合理。
　　 我們馬上就要進入WTO，因此軟體開發也要與國際接軌，只有這樣才能提高我們在專案管理水平，最終開發出高品質的軟體。

　　綜述
　
　　　軟體工程中包含需求、設計、編碼和測試四個階段,其中需求工程是軟體工程第一個也是很重要的一個階段，本文以醫院管理系統為例詳細介紹了需求工程的構成和進行方法。

　　一、需求開發

　　需求開發又分為需求萃取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己確定合適的步驟

　　　1． 需求萃取

　　　確定需求開發過程確定如何組織需求的收集、分析、細化並核實的步驟，並將它編寫成文檔。

　　　2． 需求分析

　　　繪製關聯圖、建立開發原型、分析可行性、確定需求優先順序、為需求建立模型、編寫資料字典、應用品質功能調配。

　　　3． 編寫規格說明書

　　　項目視圖和範圍文檔包含了業務需求，而使用執行個體文檔則包含了使用者需求

　　　4． 需求驗證

　　　審查需求文檔、依據需求編寫測試案例、編寫使用者手冊、確定合格的標準

　　二、需求管理

　　　需求開發的結果應該有項目視圖和範圍文檔、使用執行個體文檔、軟體需求規格說明及相關分析模型。經評審批准，這些文檔就定義了開發工作的需求基準。

一、綜述

　　軟體工程中包含需求、設計、編碼和測試四個階段,其中需求工程是軟體工程第一個也是很重要的一個階段，本文以醫院管理系統為例詳細介紹了需求工程的構成和進行方法。

　　首先我們必須瞭解需求工程和其他項目過程的關係：

圖1 需求與其他項目過程的關係

　　軟體需求包括三個不同的層次-業務需求、使用者需求和功能需求-也包括非功能需求:業務需說明了提供給客戶和產品開發商的新系統的最初利益,反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明;使用者需求文檔描述了使用者使用產品必須要完成的任務，這在使用執行個體文檔或方案指令碼說明中予以說明;功能需求定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。

圖2 軟體需求各組成部分關係

　　需求工程分為了需求開發和需求管理兩個階段:下面就以這兩個階段說明:

一,需求開發

　　需求開發又分為需求萃取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己確定合適的步驟。

　　1． 需求萃取：

　　 1）確定需求開發過程：確定需求開發過程確定如何組織需求的收集、分析、細化並核實的步驟，並將它編寫成文檔。對重要的步驟要給予一定指導，這將有助於分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行。

　　 2）編寫項目視圖和範圍文檔：項目視圖和範圍文檔應該包括高層的產品營運目標，所有的使用執行個體和功能需求都必須遵從能達到的業務需求。項目視圖說明使所有項目參與者對項目的目標能達成共識。而範圍則是作為評估需求或潛在特性的參考。

	1	2	3	4	5	6
A 業務需求	背景	業務機遇	營運目標	客戶或市場需求	提供給客戶的價值	業務風險
B 項目視圖的解決方案	項目視圖陳述	主要特性	假設和依賴環境
C 範圍和局限性	首次發行的範圍	隨後發行的範圍	局限性和專用性
D 業務環境	客戶概貌	項目優先順序
E 產品成功的因素

　　　　　　　　　　　　　　表1 項目視圖和範圍文檔的模板

　　a . 1 背景 在這一部分，總結新產品的理論基礎，並提供關於產品開發的曆史背景或形勢的一般性描述。

　　a.2 業務機遇 描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市場和資訊系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案，並指出所建議的產品為什麼具有吸引力和它們所能帶來的競爭優勢。

　　a.3 營運目標 用一個定量和可測量的合理方法總結產品所帶來的重要商業利潤,把重點放在給業務的價值上。

　　a.4 客戶或市場需求 描述一些典型客戶的需求，包括不滿足現有市場上的產品或資訊系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能啟動並執行軟、硬體平台。

　　a.5 提供給客戶的價值 確定產品給客戶帶來的價值，並指明產品怎樣滿足客戶的需要。

　　a.6 業務風險 總結開發（或不開發）該產品有關的主要業務風險，例如市場競爭、時間問題、使用者的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能採取的減輕風險的措施。

　　b.1 項目視圖陳述 編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場、企業架構、組織的戰略方向和資源局限性為基礎。

　　b.2 主要特性 包括新產品將提供的主要特性和使用者效能的列表。強調的是區別於以往產品和競爭產品的特性。可以從使用者需求和功能需求中得到這些特性。

　　b.3 假設和依賴環境 在構思項目和編寫項目視圖和範圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。

　　c.1 首次發行的範圍 總結首次發行的產品所具有的效能。描述了產品的品質特性，這些特性使產品可以為不同的客戶群提供預期的成果。

　　c.2 隨後發行的範圍 如果你想象一個周期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，並期待隨後版本發行的日期。

　　c.3 局限性和專用性 明確定義包括和不包括的特性和功能的界線是處理範圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能。

　　d.1 客戶概貌 客戶概述明確了這一產品的不同類型客戶的一些本質的特點，以及目標市場部門和在這些部門中的不同客戶的特徵。

　　d.2 項目的優先順序 一旦明確建立項目的優先順序，風險承擔者和項目的參與者就能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟體項目的五個方面：效能、品質、計劃、成本和人員。

　　e. 產品成功的因素 明確產品的成功是如何定義和測量的，並指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的範圍內的事務，還要包括外部因素。如果可能，可建立測量的標準用於評價是否達到營運目標.

3）使用者群分類：產品的使用者在很多方面存在著差異，例如：使用者使用產品的頻度、他們的應用領域和電腦系統知識、他們所使用的產品特性、他們所進行的業務過程、他們在地理上的布局以及他們的訪問優先順序。根據這些差異，你可以把這些不同的使用者分成小組。使用者類不一定都指人，你可以把其它應用程式或系統介面所用的硬體組件也看成是附加使用者類的成員。以這種方式來看待應用程式介面，可以協助你確定產品中那些與外部應用程式或組件有關的需求。將使用者群分類並歸納各自特點為避免出現疏忽某一使用者群需求的情況，要將可能使都有所差異。詳細描述出它們的個性特點及任務狀況，將有助於產品設計。

　　4）選擇產品代表：擇每類使用者的產品代表為每類使用者至少選擇一位能真正代表他們需求的人作為那一類使用者的代表並能作出決策。這對於內部資訊系統的開發是最易實現的，因為此時，使用者就是身邊的職員。而對於商業開發，就得在主要的客戶或測試者中建立起良好的合作關係，並確定合適的產品代表。他們必須一直參與項目的開發而且有權作出決策。每一個產品代表者代表了一個特定的使用者類，並在那個使用者類和開發人員之間充當主要的介面。

　　5）建立核心隊伍：建立起典型使用者的核心隊伍把同類產品或你的產品的先前版本使用者代表召集起來，從他們那裡收集目前產品的功能需求和非功能需求。這樣的核心隊伍對於商業開發尤為有用，因為你擁有一個龐大且多樣的客戶基礎。與產品代表的區別在於，核心隊伍成員通常沒有決定權。

　　6）確定使用執行個體：讓使用者代表確定使用執行個體從使用者代表處收集他們使用軟體完成所需任務的描述-使用執行個體，討論使用者與系統間的互動方式和對話要求。在編寫使用執行個體的文檔時可採用標準模版，在使用執行個體基礎上可得到功能需求。

　　一個單一的使用執行個體可能包括完成某項任務的許多邏輯相關任務和互動順序。因此，一個使用執行個體是相關的用法說明的集合，並且一個說明是使用執行個體的例子。在描述時列出執行者和系統之間相互互動或對話的順序。當這種對話結束時，執行者也達到了預期的目的。

　　對於一些複雜的使用執行個體，畫出圖形分析模型是有益的，這些模型包括資料流程圖、實體關聯圖、狀態轉化圖、對象類和聯絡圖。

　　使用執行個體的描述並不向開發人員提供他們所要開發的功能的細節。為了減少這種不確定性，你需要把每一個使用執行個體敘述成詳細的功能需求。每一個使用執行個體可引伸出多個功能需求，這將使執行者可以執行相關的任務；並且多個使用執行個體可能需要相同的功能需求。使用執行個體方法給需求萃取帶來的好處來自於該方法是以任務為中心和以使用者為中心的觀點。比起使用以功能為中心的方法，使用執行個體方法可以使使用者更清楚地認識到新系統允許他們做什麼。

　　每一個使用執行個體都描述了一個方法，使用者可以利用這個方法與系統進行互動，從而達到特定的目標。使用執行個體可有效地捕捉大多數所期望的系統行為，但是你可能有一些需求，這些需求與使用者任務或其他執行者之間的互動沒有特定的關係。這時你就需要一個獨立的需求規格說明。

　　7）召開應用程式開發聯絡會議：召開應用程式開發聯絡會議應用程式開發聯絡會議是範圍廣的、簡便的專題討論會，也是分析人員與客戶代表之間一種很好的合作辦法，並能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發人員間的夥伴關係付諸於實踐。

　　8）分析使用者工作流程：分析使用者工作流程觀察使用者執行業務任務的過程。畫一張簡單的（最好用資料流圖）來描繪出使用者什麼時候獲得什麼資料，並怎樣使用這些資料。編製業務過程流程文檔將有助於明確產品的使用執行個體和功能需求。你甚至可能發現客戶並不真地需要一個全新的軟體系統就能達到他們的營運目標。

　　9）確定品質屬性：確定品質屬性和其它非功能需求在功能需求之外再考慮一下非功能的品質特點，這會使你的產品達到並超過客戶的期望。對系統如何能很好地執行某些行為或讓使用者採取某一措施的陳述就是品質屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、方便使用、健壯性、可靠性、安全性和高效性。你將要和使用者一起商討精確定義他們模糊的和主觀言辭的真正含義。

　　10）檢查問題報告：通過檢查當前系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新產品或新版本提供了大量豐富的改進及增加特性的想法，負責提供使用者支援及協助的人能為收集需求過程提供極有價值的資訊。

　　11）需求重用：跨項目重用需求如果客戶要求的功能與已有的產品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟體組件。