軟件開發過程與質量保證需求工程軟件開發過程與質量保證需求工程軟件開發過程與質量保證需求工程情景互動需求評審會項目名稱：俄羅斯方塊報告人：項目小組代表評審組：客戶方代表、技術顧問、相關各項目小組全體成員2021年1月18日軟件開發過程與質量保證需求工程軟件開發過程與質量保證需求工程1情景互動需求評審會項目名稱：俄羅斯方塊報告人：項目小組代表評審組：客戶方代表、技術顧問、相關各項目小組全體成員2024年4月2日情景互動2一個優秀的需求文檔應具備的特征完整性、正確性不能遺漏用戶需求說明書中的必要需求。需求分析員必須在將需求進行細化時，不能丟失和改變信息，需求規格說明書必須經過用戶確認。具有準確性和一致性。它是連接計劃時期和開發時期的橋梁，也是軟件設計的依據。任何含混不清、前后矛盾或者一個微小的錯漏，都可能導致誤解或鑄成系統的大錯，在糾正時付出巨大的代價。可行性描述的功能必須從技術上是可以實現的，并且滿足時間、費用、質量等約束。必要性需求規格說明書中的內容對用戶來講都是必需的，不可或缺的。一個優秀的需求文檔應具備的特征3劃分優先級根據需求“輕重緩急”進行分級表述，可以在有限的資源（資金、人員、時間等）情況下進行取舍，降低在實現過程遇到風險。無二義性。因為它是溝通用戶和系統分析員思想的媒介，雙方要用它來表達對于需要計算機解決的問題的共同理解。如果在需求說明中使用了用戶不容易理解的專門術語，或用戶與分析員對要求的內容可以做出不同的解釋，便可能導致系統的失敗。可驗證性是軟件需求的基本屬性。需求必須是可驗證的，否則軟件評審和測試就沒有相應的依據。需求應盡量進行量化，使得其可以被驗證、測試。直觀、易讀和易于修改。應盡量采用標準的圖形、表格和簡單的符號來表示，使不熟悉計算機的用戶也能一目了然。劃分優先級4如何才能有效地描述需求？需求到底要達到一種什么樣的目標呢？如何才能有效地描述需求？5一、需求概述什么是需求？用戶解決問題或達到目標所需要的條件或權能；系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所要具有的條件或權能；反映上面兩條的文檔說明。需求工程指系統分析人員通過細致的調研分析，準確地理解用戶的需求，確定客戶“需要”什么樣的軟件。將不規范的需求陳述轉化為完整的需求定義，再將需求定義寫成需求規約的過程。需求工程包含需求開發和需求管理兩部分。一、需求概述什么是需求？6需求的演變過程—需求的“沙漏”1.需求的演變需求的演變過程—需求的“沙漏”1.需求的演變7需求獲取又被稱為需求捕獲或需求啟發發現客戶需求的過程需求分析一旦提出了最初的需求，推敲和擴充的過程構建正式的需求文檔需求獲取82.需求工程的主要活動和文檔需求開發活動需求獲取需求分析編寫需求規格說明書需求評審《用戶需求說明書》《產品(系統)需求規格說明書》《需求評審報告》2.需求工程的主要活動和文檔需求開發活動《用戶需求說明書》9需求開發文檔的區別內容用戶需求是用自然語言加圖表的形式給出的關于系統需要提供哪些服務，以及系統操作受到哪些約束的聲明。軟件需求規約(需求規格說明書)詳細地給出系統將要提供的服務以及系統所受到的約束。軟件需求規約文檔有時也稱為功能描述，應該非常精確，它可能成為系統買方和軟件開發者之間合同的主要內容需求開發文檔的區別10需求開發文檔的區別讀者對象客戶管理者最終用戶系統體系結構工程師承包商管理者客戶工程師《用戶需求說明書》需求開發文檔的區別客戶最終系統體系承包商客戶《用戶需求說明書11需求開發文檔的區別讀者對象軟件開發人員系統體系結構工程師《需求規格說明書》客戶工程師最終用戶需求開發文檔的區別軟件系統體系《需求規格說明書》客戶最終用戶12需求管理活動需求變更控制版本控制需求跟蹤需求狀態跟蹤《需求跟蹤報告》《需求變更控制報告》需求管理活動《需求跟蹤報告》《需求變更控制報告》133.需求的類型功能需求和非功能需求功能需求描述系統所應提供的功能和服務，包括系統應該提供的服務、對輸入如何響應及特定條件下系統行為的描述。非功能需求作為功能需求的補充，非功能需求是指那些不直接與系統的具體功能相關的一類需求，但它們與系統的總體特性相關，如可靠性、響應時間、存儲空間等。3.需求的類型功能需求和非功能需求14非功能性需求的類型非功能性需求的類型15人教版(新教材)初中地理《自然環境》ppt下載16針對不同需求來源的需求分類領域需求領域需求的來源不是系統的用戶，而是系統應用的領域，反映了該領域的特點。它們主要反映了應用領域的基本問題，如果這些需求得不到滿足，系統的正常運轉就不可能。領域需求可能是功能需求，也可能是非功能需求，其確定所需的領域知識。它經常采用一種應用領域中的專門語言來描述。業務需求反映組織機構或客戶對軟件高層次的目標要求，這項需求是用戶高層領導機構決定的，它確定了系統的目標規模和范圍。針對不同需求來源的需求分類17用戶需求用戶使用該軟件要完成的任務系統需求容易被忽視的要求通常是為了保證整個系統能夠正常運行的輔助功能,用戶一般不會意識到。用戶需求18軟件需求各組成部分之間的關系軟件需求各組成部分之間的關系19二、需求獲取需求獲取（requirementselicitation）也稱為需求收集（requirementscapture），它是與發現目標系統應該提供的需求相關的活動的統稱。二、需求獲取需求獲取（requiremen201.需求獲取的過程需求獲取的步驟1.需求獲取的過程需求獲取的步驟212.需求調查的主要內容環境調查包括與開發項目相關的企業的組織結構、規章制度、工藝流程、產品和服務等。新系統目標的調查將系統目標具體化，例如節約成本的手段，提高業務處理速度的方法等。管理功能和決策方式調查了解各級組織的職能和有關人員的工作內容，發現各種現存問題和薄弱環節，及對新系統的功能要求。2.需求調查的主要內容環境調查22業務流程詳細了解各職能部門人員的業務分工情況和各單位人員之間業務關系、作業順序和管理信息流動等。調查結果用業務流程圖表示。數據流程收集各業務及管理崗位使用的賬目、報表、單據、文件等數據，弄清這些數據的來龍去脈。業務流程23需求的其他來源編寫調研報告--《用戶需求說明書》需求的其他來源243.需求獲取的方法會談建立聯合分析小組由用戶、系統分析員和領域專家構成的需求收集方法座談會由開發組組織用戶和相關部門的經理、IT技術人員以及高層管理人員參加，目的是集中精力、縮短時間、提高搜集信息的效率和準確度；3.需求獲取的方法會談25搜集資料搜集現有文檔、報表等：這是最常用的方法，但必須依靠企業負責人和系統最終用戶的幫助，才能獲得所需文件；調查問卷：涉及調查表，對一些共性的問題進行較大范圍的調查，但效果不一定好；搜集資料26場景系統分析師為每個用戶設計一個場景，以提問的方式提取需求。學徒法實地觀察工作環境，參加業務實踐，對理解一些復雜細致的業務流程較為有效；原型法由于用戶對系統需求的含義不甚了解，因此由系統開發人員為用戶提供可以借鑒的模型系統，引導用戶提出更加合理的需求。場景274.分析人員與用戶的合作關系了解用戶客戶掏錢買軟件的用戶最終用戶最終操作軟件的用戶間接用戶既不掏錢買軟件，也不使用軟件，但它可能對軟件產品產生很大影響。

分清用戶的重要性4.分析人員與用戶的合作關系了解用戶285.權利和義務客戶合法要求（權利）要求分析人員使用符合客戶語言習慣的表達；要求分析人員了解客戶的業務及目標；要求分析人員編寫軟件需求規約；要求得到需求工作結果的解釋說明；要求開發人員尊重客戶的意見；要求開發人員對需求及產品實施提供建議，拿出主意；描述產品易使用的特性；調整需求，允許重用已有的軟件構件；獲得滿足客戶功能和質量要求的系統。5.權利和義務客戶合法要求（權利）29軟件需