CMMI-ReqM -...

CMMICMMI--ReqMReqM

B9315013 B9315013 徐明儀徐明儀

B9315034 B9315034 鄧偉捷鄧偉捷

B9315047 B9315047 陳俊郎陳俊郎

B9315052 B9315052 呂偉民呂偉民

B9315054 B9315054 陳映臻陳映臻

8484

報告內容大綱報告內容大綱

�� ReqMReqM在在CMMICMMI裡的定位裡的定位

�� ReqMReqM的執行方法的執行方法

�� 什麼是需求？什麼是需求？

�� 為何需求要定義？為何需求要定義？

�� 需求定義要定義什麼？需求定義要定義什麼？

�� 需求如何管理需求如何管理

ReqMReqM之定位之定位

ReqMReqM的特定執行方法的特定執行方法

瞭解需求瞭解需求

�� 目的：目的：

需求提供者與接受者間需求提供者與接受者間

對需求內容有共同的認知對需求內容有共同的認知

瞭解需求瞭解需求

�� 活動：活動：

1.1.需求必須來自正確適當的對象需求必須來自正確適當的對象

2.2.需求品質必須合乎要求需求品質必須合乎要求

�� 建立客觀的需求接受條件建立客觀的需求接受條件

�� 檢驗分析需求以確保符合接受條件檢驗分析需求以確保符合接受條件

3.3.與需求提供者共同完成充份清楚的需求，足使專案與需求提供者共同完成充份清楚的需求，足使專案成員可以承諾需求。成員可以承諾需求。

取得需求承諾取得需求承諾

�� 目的：目的：

獲得專案成員對達成需求之承諾

取得需求承諾取得需求承諾取得需求承諾取得需求承諾取得需求承諾取得需求承諾取得需求承諾取得需求承諾

�� 活動：活動：

1.1.評估需求對既有承諾之影響評估需求對既有承諾之影響�� 自設計、介面、時程、資源、風險等各角度評估自設計、介面、時程、資源、風險等各角度評估

�� 新需求產生時，專案成員新需求產生時，專案成員((工程人員工程人員))必須參與評估必須參與評估

�� 評估時應考慮需求間之資源競爭評估時應考慮需求間之資源競爭-->>需求排程需求排程

2.2.記錄對需求之承諾及評估結果記錄對需求之承諾及評估結果

管理需求變更管理需求變更

�� 目的：目的：

在專案進行過程中管理對需求的變更在專案進行過程中管理對需求的變更

管理需求變更管理需求變更

�� 行動行動

1.1.記錄專案過程中所有需求及需求變更記錄專案過程中所有需求及需求變更

2.2.記錄需求資訊、需求原因、需求提出人記錄需求資訊、需求原因、需求提出人

接受考量等相關資訊，作為需求追蹤與衝突解決時之參考接受考量等相關資訊，作為需求追蹤與衝突解決時之參考

依據。依據。

3.3.維持需求變更之歷史記錄及變更原因。維持需求變更之歷史記錄及變更原因。

4.4.由相關人員依其角度評估需求變更之影響由相關人員依其角度評估需求變更之影響

5.5.將需求及變更資料公告給全專案。將需求及變更資料公告給全專案。

維護需求的雙向追溯性維護需求的雙向追溯性

�� 目的：目的：

在需求、產品及專案計畫間在需求、產品及專案計畫間

建立與維持雙向之追溯表。建立與維持雙向之追溯表。

維護需求的雙向追溯性維護需求的雙向追溯性

�� 行動：行動：

1.1.維持向上之需求追溯性，確保對組件產品之需求來源均維持向上之需求追溯性，確保對組件產品之需求來源均

能被有效定義。能被有效定義。

2.2.維持向下之需求追溯性，確保每一需求均被展開與配置維持向下之需求追溯性，確保每一需求均被展開與配置

到相關之功能、物件、人員及流程。到相關之功能、物件、人員及流程。

3.3.維持功能與功能及介面間之水平追溯性維持功能與功能及介面間之水平追溯性

4.4.產生需求追溯表產生需求追溯表

界定專案工作與需求間的差異界定專案工作與需求間的差異

�� 目的：目的：

鑑定需求與專案計畫鑑定需求與專案計畫

及既有產品間之不一致性及既有產品間之不一致性

界定專案工作與需求間的差異界定專案工作與需求間的差異

�� 行動：行動：

1.1.審查專案計畫、活動、與產品，評估與需求及需求變更審查專案計畫、活動、與產品，評估與需求及需求變更

項目間之一致性。項目間之一致性。

2.2.找出不一致處及其原因找出不一致處及其原因

3.3.鑑定由於需求基準點變更所造成之專案計畫、活動、與鑑定由於需求基準點變更所造成之專案計畫、活動、與

產品的變更需求產品的變更需求

4.4.採取矯正改善行動，以因應變更採取矯正改善行動，以因應變更

5.5.變更結果應通告專案相關人員變更結果應通告專案相關人員

什麼是需求？什麼是需求？

�� 什麼是需求？一般有三種說法：什麼是需求？一般有三種說法：

�� 所謂需求可以是當客戶要求我們建立一個系統時，客所謂需求可以是當客戶要求我們建立一個系統時，客戶對該系統應該或可能要完成哪些事情已經有一些想戶對該系統應該或可能要完成哪些事情已經有一些想法！法！((這就是需求這就是需求))。。

�� 凡是系統均應有一個目的！凡是系統均應有一個目的！((這就是需求這就是需求))。。

�� 所謂需求所謂需求(Requirement)(Requirement)就是對目標系統之容貌的一種描就是對目標系統之容貌的一種描

述或是為了達成系統目的而應具備之功能的敘述。述或是為了達成系統目的而應具備之功能的敘述。

為何需求要定義？為何需求要定義？

�� 多年來軟體工程中需求均是以自然語言來表達，但是以自多年來軟體工程中需求均是以自然語言來表達，但是以自然語言來表達需求在不同當事人解讀時會產生不同之感受然語言來表達需求在不同當事人解讀時會產生不同之感受或定義，如「可用性」之定義就有許多不同之見解。或定義，如「可用性」之定義就有許多不同之見解。

�� 需求不見得能夠根據它所涉及之系統元素來抽離與描述，需求不見得能夠根據它所涉及之系統元素來抽離與描述，所以軟體工程中就研究並提供一些方法來協助我們將需求所以軟體工程中就研究並提供一些方法來協助我們將需求用較嚴謹與易掌握之形式來定義需求。用較嚴謹與易掌握之形式來定義需求。

需求定義要定義什麼？需求定義要定義什麼？

�� 若一個系統應該能由一組完整的需求定義所組成，故需求若一個系統應該能由一組完整的需求定義所組成，故需求應該要描述到系統的所有部份包括實體、長相、關聯與進應該要描述到系統的所有部份包括實體、長相、關聯與進入、經過、離開系統會發生什麼事入、經過、離開系統會發生什麼事

�� 需求定義是用來指出系統之目的，而不必考慮到如何來製需求定義是用來指出系統之目的，而不必考慮到如何來製

作系統，也就是說不應該有：用哪種語言來開發、要多少作系統，也就是說不應該有：用哪種語言來開發、要多少錢、用哪種錢、用哪種DBMSDBMS等字眼出現於需求定義等字眼出現於需求定義((除非客戶指除非客戶指

定定))。。

需求如何管理？需求如何管理？

編號編號編號編號編號編號編號編號 步驟步驟步驟步驟步驟步驟步驟步驟

11 接受需求接受需求

22 登錄需求登錄需求

33 瞭解需求瞭解需求

44 審查與承諾審查與承諾

55 確認需求確認需求

66 管制需求變更管制需求變更

77 登錄及追蹤需求登錄及追蹤需求

88 建立追溯性建立追溯性

99 變更計畫變更計畫

1010 開發或修改軟體開發或修改軟體

找出客戶需求找出客戶需求

需求接受條件需求接受條件

11 清晰而適當地表達清晰而適當地表達清晰而適當地表達清晰而適當地表達清晰而適當地表達清晰而適當地表達清晰而適當地表達清晰而適當地表達

22 完整完整

33 相互一致相互一致

44 能被個別界定能被個別界定

55 能被適當地實行能被適當地實行

66 能被驗證能被驗證((例如能被測試例如能被測試))

77 具備追溯性具備追溯性

根據IEEE Std 830 SRS國際標準之一個好的需求應有下列條件