軟件項目需求工程主要內容軟件項目需求概述軟件需求開發和管理軟件需求規格的定義方法一、軟件項目需求概述1.什么是需求需求的基本概念寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。需求的重要性FrederickBrooks在他1987年經典文章“NoSilverBullet”中闡述了需求的重要性：開發軟件系統最困難的部分就是準確說明開發什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統的接口。此工作一旦做錯，將會給系統帶來極大的損害，并且以后對它修改也極為困難。需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。國內軟件業的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發。2.了解客戶、最終用戶、間接用戶基本概念“用戶”（user）是一種泛稱，它可細分為“客戶”（customer）、“最終用戶”（theenduser）和“間接用戶”（或稱為關系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶。客戶與最終用戶可能是同一個人也可能不是同一個人。3.需求工程基本概念什么是需求工程把所有與需求直接相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發，另一類屬于需求管理。3.需求工程基本概念需求開發過程域需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求。需求調查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產生《用戶需求說明書》。需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規格說明書》。系統設計人員將依據《產品需求規格說明書》開展系統設計工作。需求管理過程域需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。二、軟件需求開發和管理1.需求開發的主要困難與對策知識技能問題態度問題合作關系用戶說不清楚需求開發人員寫不好需求文檔用戶經常變更需求2.如何開展需求調查準備調查調研單準備預約執行調查調研會議閱讀文檔遠程調研（電話mail）需求分析2.、調研單調研內容需要文檔（是否復印）計劃時間計劃方式聯系人聯系方式3.如何進行需求分析基本概念需求分析是指在需求開發過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。“問答分析法”比較適合于用戶需求調查階段“建模分析法”比較適合于產品需求定義階段。問答分析方法問答分析最重要的問題是：“是什么”和“為什么”。其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現嗎？需求可驗證嗎？需求的優先級確定了嗎？

三、定義需求規格的方法需求規格原型方法結構化分析法面向對象的用例分析法關鍵功能列表法1.原型方法定義按照用戶的需要，快速形成一個操作流程界面可能只是一個框架，具體的功能沒有實現，只是結果靜態的操作流程，以便與用戶快速就需求達成一致主要考慮系統的功能需求，很少考慮非功能需求需求分析原型開發原型評價需求規格原型方法的類型進化型開發出來用于了解問題，并形成被交付軟件的部分或全部的基礎拋棄型開發出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實際部分2.結構化分析方法20世紀70年發展起來的面向數據流的方法是一種自頂向下逐步求精的分析方法根據軟件內部數據傳遞、變換的關系進行分析的技術數據流圖(DFD)數據字典(DD)系統流程圖數據流圖是一種描述軟件系統邏輯模型的圖形符號數據流圖的層次結構為了表達數據處理過程的數據加工情況，需要采用層次結構的數據流圖。按照系統的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖。數據字典描述系統中涉及的每個數據,是數據描述的集合,通常配合數據流圖使用,用來描述數據流圖中出現的各種數據和加工.組成數據項:數據元素數據流:由數據項組成的數據流數據文件:表示對數據文件的存儲數據流圖需求分析實例:建立學生管理系統學管科體檢科學籍科學生處學管科體檢科學籍科學生管理信息系統學生處領導學生基本信息學生健康信息學生成績學生健康情況表學生成績單查詢要求不及格人數人數統計表數據字典-數據流學生基本信息：學號十姓名學生健康信息：學號十健康情況學生成績：學號十{課程名+成績}查詢要求：[健康查詢單|平均成績查詢單l不及格人數查詢]學生健康情況表：優％十良％十一般％十差％學生成績單：學號十姓名十{課程名+成績}+總成績不及格人數統計表：學號十成績十不及格總人數數據字典-文件文件文件名：基本信息組成：｛學號十姓名十入學成績十生源｝組織：按學號遞增順序排列文件名：健康文件組成：{學號+姓名+健康情況}組織：按照健康情況為優、良、一般、差順序排列文件名：成績文件組成：{學號+姓名+平均成績}組織：按照評劇成績遞增順序排列加工說明加工編號2.1加工名稱：學生基本信息處理輸入流：合法的學生信息輸出流：錄入單，修改單，刪除單加工邏輯：根據輸入的要求，對學生基本信息進行錄入、修改或刪除3.用例需求（usecase）分析用例需求分析方法采用一種面向對象的情景分析方法用例是系統向用戶提供一個有價值的結果的某項功能所有的用例結合起來就構成了用例模型從用戶角度出發考慮的功能需求UML

UnifiedModelingLanguage統一建模語言，是一種通用的模擬語言。Booch,Rumbaugh

和Jocobson

基礎上發展起來的。1997年11月國際對象管理組織OMG批準將UML作為基于面向對象技術的標準建模語言。UML制定了一整套完整的面向對象的標記和處理方法。UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態圖（StateDiagram）活動圖（ActivityDiagram）用例視圖用例視圖主要是展示了外部行為者所觀察到的系統將提交的功能.即:各類外部行為者與系統所提供的用例的連接用例（Usecase）：系統所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統UML圖符

用例實例

用例實例

順序圖示順序圖展示了幾個對象之間的動態協作關系，主要用來顯示對象之間發送消息的順序，還顯示對象之間的交互，即系統執行某一特定時間點所發生的事。

活動視圖

活動圖用來描述執行工作流程中涉及的活動，展示了連續的活動流。

UseCase需求分析方法綜述識別出系統的Actor描述主要的Usecase實現用例視圖實現順序視圖、活動視圖、狀態視圖等4.關鍵功能列表KFL是對項目的功能需求進行詳細說明的一種方法。可以作為用例分析方法的附加說明，詳細說明某個用例的具體功能。4.什么是好的需求規格說明書正確清楚無二義性一致必要完備可實現可驗證確定優先級闡述“做什么”而不是“怎么做”5.如何定義產品需求第一步：細化并分析用戶需求第二步：撰寫產品需求規格說明書第三步：進行需求確認軟件需求說明書的參考模板6.需求管理：確認、跟蹤、變更控制需求確認（評審和承諾）需求評審面臨的困難需求承諾需求跟蹤需求變更控制需求追蹤的意義問題舉例：作用地位

忘記實現子需求變更時不清楚要變動的地方搞不清改動的影響面有多大取消需求，設計仍然在進行

追蹤信息是項目管理的重要依據追蹤信息是變更的重要參考是可靠過程的重要標志定義追蹤關系（Links）業務需求系統需求系統測試軟件需求硬件需求原理圖體系結構PCB圖單元設計單元測例集成測例直接追蹤間接追蹤后向追蹤前向追蹤實現舉例：追蹤表追蹤表（需求）描述編號FR1.1FR1.2應用圖形顯示網絡拓撲結構應能使用戶在圖形中選擇并編輯