[工學(xué)]軟件項目計劃-在線瀏覽
2025-03-10 13:06本頁面
【正文】 nications for system integration 9 Insufficient experience as team 10 Shortage of application domain experts Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: CarnegieMellon University, Software Engineering Institute 2022/2/16 12 什么是軟件需求 ? 需求是指用戶對軟件的 功能 和 性能 的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。 —— Rational ? 用戶解決某一問題或達(dá)到某一目標(biāo)所需的軟件功能。 ——Merlin Dorfman 、 Richard H. Thayer 2022/2/16 13 軟件需求的層次 業(yè)務(wù)需求 表示組織或客戶高層次的目標(biāo) 。業(yè)務(wù)需求描述了組織 為什么要開發(fā)一個系統(tǒng) ，即組織希望達(dá)到的目標(biāo)。 2022/2/16 14 軟件需求的層次 業(yè)務(wù)需求 用戶需求 描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù) 。也就是說用戶需求描述了 用戶能使用系統(tǒng)來做些什么 。功能需求有時也被稱作行為需求，因為習(xí)慣上總是用 “ 應(yīng)該 ” 對其進行描述： “ 系統(tǒng)應(yīng)該發(fā)送電子郵件來通知用戶已接受其預(yù)定 ” 。 三個層次 2022/2/16 16 軟件需求的層次 業(yè)務(wù)需求 用戶需求 功能需求 系統(tǒng)需求 用于描述包含多個子系統(tǒng)的產(chǎn)品（即系統(tǒng)）的 頂級需求 。人也可以是系統(tǒng)的一部分，因此某些系統(tǒng)功能可能要由人來承擔(dān)。這些特性包括 可用性、可移植性、完整性、效率和健壯性 ，它們對用戶或開發(fā)人員都很重要。 2022/2/16 18 軟件需求的層次 業(yè)務(wù)需求 用戶需求 功能需求 非功能性需求 約束和假設(shè) 系統(tǒng)需求 限制了開發(fā)人員設(shè)計和構(gòu)建系統(tǒng)時的選擇范圍 。 需求工程 需求管理 需求開發(fā) 需求獲取 需求分析 需求規(guī)格編寫 需求驗證 變更管理 2022/2/16 23 需求獲取是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生 《 用戶需求說明書 》 。 2022/2/16 25 需求獲取方法 開始前：做好準(zhǔn)備，寫出訪談提綱 進行中：要注意聆聽和引導(dǎo) 結(jié)束后：要寫感謝信 旁敲側(cè)擊的方式 復(fù)述，復(fù)述，復(fù)述 聆聽不要指導(dǎo) 兩個人去訪談 讓被訪者上司安排 不要問太多 2022/2/16 26 需求獲取方法 頭腦風(fēng)暴法（集思廣益會） 德爾菲技術(shù) （ 1）根據(jù)問題的特點，選擇和邀請相關(guān)專家。 （ 3）管理者收集并綜合專家們的意見后，將綜合意見反饋給各位專家，請他們再次發(fā)表意見。 （ 4）如此反復(fù)多次，最后形成代表專家組意見的方案。A郵件提問 ? 電視電話會議訪談 2022/2/16 28 需求的分析、整理和確認(rèn) 目標(biāo)：要知道每個需求的 “ 為什么 ” ；從 “ 如何實現(xiàn) ” ?“ 實現(xiàn)什么 ” ； 分析隱含需求。 向用戶提供可視化的界面，用戶可以對需求做出自己的評價。 2022/2/16 33 處理需求不明確問題的方法 讓用戶參與開發(fā)。 需求討論會議。 2022/2/16 34 需求規(guī)格 ?需求分析工作完成的一個基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書。 2022/2/16 35 軟件需求規(guī)格說明的原則 ? 從現(xiàn)實中分離功能，即描述要 “ 做什么 ” 而不是“ 怎樣實現(xiàn) ” 。 ? 如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。 ? 規(guī)格說明應(yīng)該是一個認(rèn)識模型。 SRS實例 2022/2/16 36 需求驗證內(nèi)容 需求的正確性 需求的一致性 需求的完整性 需求的可行性 需求的必要性 需求的可檢驗性 需求的可跟蹤性 最后簽字 與其他軟件需求或高層需求不相矛盾 驗證是否所有可能的狀態(tài)、狀態(tài)變化、轉(zhuǎn)入、產(chǎn)品和約束都在需求中描述 驗證每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施。避免大段大段的敘述 2022/2/16 37 需求變更管理 確定變更控制過程 建立軟件變更委員會 進行變更影響分析 跟蹤變更影響的產(chǎn)品 建立基準(zhǔn)和控制版本 維護變更的歷史記錄 跟蹤每項需求的狀態(tài) 衡量需求穩(wěn)定性 選擇、分析、決策 項目進度、資源、工作量、項目范圍、對其他需求的影響 確定、已實現(xiàn)、暫緩、新增、變更 記錄需求基線的數(shù)量和每周或每月的變更 2022/2/16 38 變更申請 需求方 開發(fā)方 忽略 選擇變更方式 SCCB評估 項目經(jīng)理自行決定 根據(jù)評估結(jié)果 拒絕 接受本次修改 下個版本再修改 修改合同相關(guān)信息 修改相關(guān)需求 修改相應(yīng)的項目計劃 需求變更管理過程 2022/2/16 39 本章要點
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1