軟件需求管理控制程_第1頁
軟件需求管理控制程_第2頁
軟件需求管理控制程_第3頁
軟件需求管理控制程_第4頁
免費預覽已結束,剩余1頁可下載查看

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、目錄1. 目的22. 范圍23. 職責24. 工作程序 24.1 軟件需求收集、分析和文檔化過程24.1.2 下達軟件工程任務書 34.1.3 制定需求分析計劃 34.1.4 需求的分析過程34.1.5 編制軟件需求說明書 34.1.6 制定軟件驗收計劃 44.2 需求變更經管過程(包括增加、刪除和修改) 44.2.2 需求更改申請的提出44.2.3 影響分析階段44.2.4 申請評審、批準階段44 2 4 實施更改 45 2 5 評審、批準 44 3 需求追蹤 55 參考資料 51 .目的明確需求經管全過程的主要工作和內容,具體包括以下方面:保證客戶、客戶經理和軟件開發工程組之間對客戶需求具

2、有共同的理解,并且在工程的整個生命周期內都是有效的;通過系統工程組編寫特性需求說明書FRS ( Feature RequirementsSpecification ),將系統需求中的軟件、硬件和其它系統成分的工作分開,軟件需求以外的工作由軟件工程組之外的人員完成;軟件工程經理明確定義軟件需求說明書SRS ( Software Requirements Specification)中要求的內容并文檔化;軟件需求說明書必須完整、正確、及時地反映客戶的需求,要仔細進行分析、消化并詳細描述,盡量做到所有相關人員都能正確理解;軟件需求說明書經評審后存檔,即作為軟件開發計劃和活動進行經管和控制的基線;一旦

3、軟件需求說明書經過雙方簽字認可之后,每當用戶需求發生變更時,必須進行需求變更,受其影響的工程計劃、活動和工作產品必須進行相應的修正,并通告所有受影響的組織和個人;確保最終的軟件工作產品、活動和計劃與軟件需求說明書相一致,并能通過軟件 工程經理對軟件需求的可追蹤性進行經管。2 .范圍本過程適用于以下范圍:a)新的軟件開發工程;b)原有軟件系統的升級、維護;c)自用工具軟件的開發;d)軟件工程開發過程中的需求變更。3 .職責3.1 系統工程組(產品經理、研發經理、客戶經理)負責編制特性需求說明書。3.2 研發經理下達軟件工程任務書,指定軟件工程經理,協助軟件工程經理成立軟 件工程小組。3.3 軟件

4、工程經理負責組織進行軟件需求的收集、分析(必要時編制需求分析計劃);負責制定軟件需求說明書、軟件驗收計劃等,并對需求實現情況進行跟蹤、檢查。3.4 軟件工程經理負責組織相關人員進行評審工作。3.5 高級經管者負責批準對外承諾,并定期審查需求經管活動。4 .工作程序4.1 軟件需求收集、分析和文檔化過程4.1.1 需求收集和編制特性需求說明伸在的力tl制定FRS與客戶有了合作意向或合同簽定后及產品研發部確定開發產品時,系統工程 組收集工程的需求(過程可參見軟件需求收集指南),分析工程系統需求,并 將其分配為軟件、硬件和其它系統成分,決定每一個需求的特征和需要修改的缺 陷,形成特性需求說明書,以作

5、為軟件工程小組工作的先決條件,特性需求 說明書必須經過評審(評審的方式根據需要選擇適當的方式舉行,可參見評 審過程)以確保其內容準確、完整地反映了客戶的需求,同時它成為制定軟件需 求說明書的基礎;評審通過才能進入下一階段。說明:對于純軟件的工程,可以不制定特性需求說明書,進入下一階段。4.1.2 下達軟件工程任務書研發經理發出軟件工程任務書,初步指定工程開發人員和軟件工程經理, 明確提供工程開發的可用資源,并將軟件工程任務書提交到技術經管部組織評 審(評審的方式根據需要選擇適當的方式舉行,可參見評審過程),作為工程正式立項,以確認工程的正式啟動。4.1.3 制定需求分析計劃如果工程規模較大,需

6、求收集超過二個月的,軟件工程經理負責制定需求分 析計劃,否則,可以不進行需求分析計劃的制訂。4.1.4 需求的分析過程對于初次進行軟件需求收集、分析和經管的人員,軟件工程小組安排進行必要 的培訓,以便他們能按照公司的規范要求完成需求分析和經管活動。工程小組通過分析、收集、標識、細化和評審等方式鑒別出不完備的、遺漏的 或多余的用戶需求,以盡可能詳細的描述來表達客戶對軟件的功能要求,以及對軟件界面、系統運行環境、安全、穩定性、可擴展性等方面的要求。該要求需在軟 件需求說明書中描述并由客戶代表(客戶經理)簽字確認。對需求的描述詳盡程 度應滿足軟件設計和開發的基本要求。適當的變更和修改將使用需求變更經

7、管過程 4.2。需要指出的是,在現實工作中,需求的定義應服務于公司的商務過程的要求 并以達成商務談判的目標為原則。說明:需求定義、工程策劃和設計可能會有所重疊。4.1.5 編制軟件需求說明書4.1.5.1 軟件工程經理組織編寫軟件需求說明書,編制完成后必須組織 軟件工程組、有影響的組或人員評審(評審的方式根據需要選擇適當的方式舉 行,可參見評審過程),評審出問題的需求必須做出更改,經過評審的軟件 需求經SCCB、高級經管者和客戶(客戶經理)批準后入基線庫進行經管并作 為制定開發計劃的基礎。4.1.5.2 軟件需求說明書批準后,由有關人員討論協商,確定由軟件需 求引起的相應職責和活動,這些人員可

8、能包括:客戶經理、計劃制定人員、軟 件設計人員、軟件開發人員、軟件系統測試人員、質量保證人員、配置經管人 員等。4.1.6 制定軟件驗收計劃軟件工程經理在軟件需求說明書編制過程中或編制完成后應組織制訂軟件驗收計劃,該驗收計劃需經過評審(評審的方式根據需要選擇適當的方式舉行,可 參見評審過程)、SCCB批準,并取得客戶的認可,以便在工程結束時按計劃驗 收,驗收結束后應填寫軟件驗收報告。4.2 需求變更經管過程(包括增加、刪除和修改)開始4.2.1 需求更改申請的提出1)客戶提出的修改請求,堀喋是1卵限的方式,軟件工程小組人員或客戶經理 應對顧客的請求進七記屋一»§力確認后,填

9、寫需求變更申請表 提交軟件工程經理。2)如果請求是由公司內那人耳給出的 提出者應填寫需求變更申請表 交軟件工程經理且4.2.2錄于軟件需求與軟件病0影響分析階段軟件工程經理報后應對需求的變更情況毋行登記(記 對于緊急的變更應及時進人影響分析階段;而其他的變更應進行匯總,統1時"用而進極響分析包括以下方麻總竄覆必要 性、可行性和合理性;影澗域(技采, 至度, 資源、成本、系統公構等)|評估;規模和工作量的估算;標忒 規劃取蚓恥。對于小的變更應予記錄并累計工作量,當累計的工作量將達到預計的工作加時,應及時通知客戶方,超出的部分有可能計算成本并收取相應的費用,但須客戶確認后家施。, ,、,

10、 、 評審4.2.3申請評審、批M階段甲如果 審核批準 審、批準 評審人員變更請求涉及緊急事項,則應由有關部門和個人立即組織評審并由SCCB,而后由責任人負責實施I.如果是非緊急事項,由軟件工程經理集中組織評(SCCB)(評審的也共、一審適當叫”行,應包括受影響的組和fefe ,sCCBS與曲H協冏1!改可參見評審過程),SCCB批準后實施更改。級經管者和客戶不作修改若此更動涉及組織外部,則啦有組織附高級經管者確認,并得到客戶的確認后實施更改;若此更動僅涉及組織內部,,4, 2, 4修個需求說明了修改需求說明書更改時,如果軟件H程經理安排工程組的其他人員實施更改,軟件工程經理應填寫任務通知單,

11、通知1改,并對更改情況進行監督。一評審、批準一4. 2. 5評審、批準更改結束后,軟件工仍經理應船織對更改后的軟件需求說明書進行評審, 并通過SCCB會議批準卜得魚麻棒管者心客戶的確認后,才可入基線庫進行經 管,配置經管員應及時填心變屯!知單而知受影響的組和個人。4. 3需求追蹤4.3.1 對于軟件需求說明書中所描述的所有需求(包括變更的需求),由軟件工程經理 根據軟件需求與軟件需求變更追蹤表跟蹤至完成狀態。4.3.2 高級經管者通過審查需求工程里程碑報告和質量保證評估報告,來了解和考察需求經管活動。4.3.3 軟件工程經理通過參加需求評審或對需求進行定期檢查和跟蹤來經管和控制需 求的活動,并對需求的變更狀態和數量進行測量。4.3.4 質量保證人員按照計劃使用軟件需求經管檢查表實現對需求的檢查并將質 量保證評估報告通知相關人員(包括工程經理、高級經管者、工程組成員等)。5.參考資料序號編力文檔名稱1:Q/RKS-SP-RM-02,軟件需求收集指南2Q/RKS-SP-RM-03特,住需求說明書3Q/RKS-SP-RM-04軟件工程任務書

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論