《軟件需求管理》ppt課件-全文預(yù)覽
【正文】 the project Create a Requirement in the Explorer or in a View User Documentation Specifications Design Specifications UseCase Model Supplementary Specifications Features Software Requirements Needs Requirements and Associated Documents StakeholderRequests Vision Document Design, Test, Documentation Requirements Delete a Requirement in a Document 。 ?每一個已應(yīng)用的需求（是指已劃過基線）建議變更和實現(xiàn)變更的數(shù)量。 ?配置管理部門。 ?市場部或客戶代表。 簡單變更控制步驟模板 ① 目的 ② 范圍 ③ 定義 5. 任務(wù) ① 產(chǎn)生變更請求 ② 評估變更請求 ③ 作出決策 ④ 通知變更人員 6. 驗證 7. 結(jié)束條件 變更管理活動中可能的項目角色 角 色 描述及責(zé)任 變更控制委員會主席 變更控制委員會的主席 ， 在 C C B意見不一致情況下可以獨自做出決定 CCB 決定采納或拒絕針對某項目所建議的變更請求的團(tuán)體 評估者 應(yīng)項目管理者要求分析所建議的變更帶來影響的人員 修改者 負(fù)責(zé)實現(xiàn)已經(jīng)被認(rèn)可的請求變更，按時更新變更狀態(tài)的人員 建議者 提交新變更請求的人 項目管理者 負(fù)責(zé)指定評估者和修改者的人員 請求接受者 接受提交變更請求的人 驗證者 負(fù)責(zé)決定變更是否正確執(zhí)行的人 變更控制委員會的組成 ?產(chǎn)品或計劃管理部門。 ?簡單請求一個變更不能保證能實現(xiàn)變更，要由項目變更控制委員會（ C C B）決定實現(xiàn)哪些變更。 ?控制需求擴(kuò)展的另一個有效的技術(shù)是原型法，這個方法能夠給用戶提供預(yù)覽所有可能的實現(xiàn)，以幫助用戶與開發(fā)者溝通從而準(zhǔn)確把握用戶的真實需求。 ?若不控制范圍的擴(kuò)展將使我們持續(xù)不斷地采納新的功能，而且要不斷地調(diào)整資源、進(jìn)度、或質(zhì)量目標(biāo)，這樣做極其有害。 ?要是每個建議的需求都被采納，對于項目出資者（ sponsor）、參與者與客戶來說項目將永遠(yuǎn)也不會完成 — 事實上，這是不可能的。 ?變更應(yīng)及時通知所有涉及的人員。 需求的屬性 ? 創(chuàng)建需求的時間 ? 需求的版本號 ? 創(chuàng)建需求的作者 ? 負(fù)責(zé)認(rèn)可該需求的人員 ? 需求狀態(tài) ? 需求的原因或根據(jù)（或信息的出處） ? 需求涉及的子系統(tǒng)
公司管理相關(guān)推薦
鄂ICP備17016276號-1