【文章內(nèi)容簡介】 對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等?？刹捎玫男枨蠓治龇椒ㄓ小皢柎鸱治龇ā薄ⅰ敖Y構化分析法”和“面向對象分析法”。 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結果，進一步定義準確無誤 的產(chǎn)品需求，產(chǎn)生《需求規(guī)格說明書》。系統(tǒng)設計人員將依據(jù)《需求規(guī)格說明書》開展系統(tǒng)設計工作。 需求開發(fā)產(chǎn)生的文檔有： 《業(yè)務需求說明書》，見模版 3（定制項目可使用與客戶簽訂的合同技術文件作為用戶需求說明書）。 《需求規(guī)格說明書》，見模版 4 用戶需求調(diào)查 目的 獲取用戶的需求信息，經(jīng)過分析后產(chǎn)生《業(yè)務需求說明書》。 角色與職責 需求分析員調(diào)查、分析用戶的需求； 客戶與最終用戶提供必要的需求信息。 主要步驟 準備 ①需求分析員確定需求調(diào)查的方式，例如 與用戶交談，向用戶提問題 參觀用戶的工作流程，觀察用戶的操 作。 向用戶群體發(fā)調(diào)查問卷。 與同行、專家交談，聽取他們的意見。 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。 從行業(yè)標準、規(guī)則中提取需求。 從 Inter 上搜查相關資料。 ②需求分析員準備調(diào)查問卷 需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等。 調(diào)查與記錄 需求分析員調(diào)查用戶需求，隨時記錄調(diào)查過程中所獲取的需求信息。 分析需求信息 需求分析員分析已經(jīng)獲取的需求信息，消除錯誤，歸納與總結共性的用戶需求。 撰寫用戶需求說明書 需求分析員按照指定的文檔模板撰寫《業(yè)務需求說明書》，主要內(nèi)容包括 ：產(chǎn)品介紹、描述用戶群體的特征、產(chǎn)品應當遵循的標準或規(guī)范、描述產(chǎn)品的功能性需求、描述產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質量等需求 需求確認 項目經(jīng)理邀請同行專家和用戶一起評審《業(yè)務需求說明書》，盡最大努力使《業(yè)務需求說明書》能夠正確無誤地反映用戶的真實意愿。 產(chǎn)品需求定義 目的 定義準確無誤的產(chǎn)品需求，產(chǎn)生《需求規(guī)格說明書》； 角色與職責 需求分析員定義產(chǎn)品需求。 客戶與最終用戶提供必要的需求信息，并確認產(chǎn)品需求。 主要步驟 細化并分析用戶需求 需求分析員對《業(yè)務需求說明書》進行細化，以便產(chǎn) 生詳細的產(chǎn)品需求。 需求分析員對比較復雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。 撰寫產(chǎn)品需求規(guī)格說明書 ① 需求分析員按照指定的文檔模板撰寫《需求規(guī)格說明書》。 ②《需求規(guī)格說明書》的主要內(nèi)容包括產(chǎn)品介紹、描述用戶群體的特征、定義產(chǎn)品的范圍、闡述產(chǎn)品應當遵循的標準或規(guī)范、定義產(chǎn)品中的角色、定義產(chǎn)品的功能性需求、定義產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質量等需求。 需求確認 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《需求規(guī)格說明書》，盡最大努力使《需求規(guī)格說明書》 能夠正確無誤地反映用戶的真實意愿。 需求管理 需求管理的目的在客戶與項目組之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更。需求管理過程的三個主要規(guī)程為：需求確認、需求跟蹤、需求變更控制。 所有與需求相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發(fā)，另一類屬于需求管理。圖 為需求工程的結構圖。 圖 需求工程結構圖 需求管理過程主要有 3 個規(guī)程：需求確認、需求跟蹤與需求變更控制。 需求確認： 需求確認是指項目 組和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 需求跟蹤： 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 需求變更控制： 需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認”的流程處理需求的變更，確保需求的變更不會失去控制而導致項目發(fā)生混亂。 需求管理過程產(chǎn)生的主要文檔有： 《業(yè)務需求評審報告》，見模版 14 《需求規(guī)格評審報告》，見模版 15 需求確認 目的 項目組和客戶對需求文檔 《需求規(guī)格說明書》進行評審確認。 角色與職責 （ 1）項目組和客戶共同組織人員對需求文檔如《需求規(guī)格說明書》進行評審。 （ 2）項目組負責人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 主要步驟 非正式需求評審 項目經(jīng)理先在項目內(nèi)部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。 正式需求評審 項目經(jīng)理邀請同行專家和用戶一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。 需求跟蹤 目的 將系統(tǒng)設計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維 護“需求文檔－設計文檔－代碼－測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 角色與職責 項目經(jīng)理跟蹤需求。 主要步驟 建立與維護需求跟蹤矩陣 ① 正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應點。 ② 逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。 ③ 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應關系。矩陣單元之間的可能存在“一對一”、“一對多”或“ 多對多”的關系。由于對應關系比較復雜，最好在表格中加必要的文字解釋。表 為簡單的需求跟蹤矩陣格式。 序號 需求文檔 （版本，日期） 設計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1 標題或標識符，說明 標題或標識符，說明 代碼名稱，說明 測試用例名稱，說明 2 ? ? ? ? 表 需求跟蹤矩陣 查找不一致 ① 使用需求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處。 ② 項目經(jīng)理將發(fā)現(xiàn)的“不一致性”記錄在《需求跟蹤報告》之中，并通報給 相關責任人。 消除不一致 ① 相關責任人給出消除“不一致”的措施和計劃，項目經(jīng)理將該措施和計劃記錄到《需求跟蹤報告》之中。 ②相關責任人消除“不一致性”之后，項目經(jīng)理更新“需求跟蹤矩陣”。 需求變更控制 目的 （ 1）修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔。 （ 2）控制需求文檔的變更，防止發(fā)生混亂。 角色與職責 項目組負責人（項目經(jīng)理）和客戶共同控制需求變更。 主要步驟 需求變更申請 ①需求變更申請人撰寫“需求變更申請書”，遞交給項目經(jīng)理或客戶方負責人。 ②“需求變更申請書”必須闡述：變更 原因、變更的內(nèi)容、此變更對項目造成的影響。 審批需求變更申請 項目組負責人（項目經(jīng)理）和客戶共同審批“需求變更申請書”： 如果任何一方不同意變更，則退回變更請求，項目按照“原需求文檔”執(zhí)行。如果雙方都同意變更則進入下一流程。 更改需求文檔 需求分析員根據(jù)需求變更申請更改“原需求文檔”，產(chǎn)生新的需求文檔。 重新進行需求確認 重新進行需求評審確認。 概要設計 概要設計也成為高層設計階段，重點是進行軟件系統(tǒng)的體系結構設計。概要設計與需求開發(fā)、詳細設計及編碼實現(xiàn)的關系如圖 所示。 圖 開發(fā)過程各階段 的關系圖 概要設計階段產(chǎn)生的主要文檔有： 《概要設計說明書》，見模版 5 《概要設計評審報告》，見模版 16 目的 分析與設計軟件的體系結構