需求管理過程域的要點

實踐

理解與實施要點

sp1.1

理解需求：與需求提供者一起理解需求的含義。

（1）先判斷需求提供者是否合適，，即哪些人是合法的需求提供者，建立確認合適的需求提供者的準則,

（2）再判斷提出的需求是否可接受，建立需求可接受的準則

（3）最後和需求提供者對需求達成一致的理解

（4）上述的準則可以定義在需求開發計畫書中，也可以體現為單獨的檢查單。

（5）該過程域的sp1.1 sp1.2 sp1.4 在過程定義時可以放在需求開發過程中，sp1.3可以單獨寫乙個過程，或者和配置管理的變更流程合併，sp1.5可以定在評審的過程中或問題處理的過程中

sp1.2

取得對需求的承諾：取得專案成員對需求的承諾。

（1）此處的需求承諾是需求實現者對需求可實現的承諾不是客戶對需求不變的承諾。

（2）需求的承諾有2類時間點：一是需求剛建立時，二是需求變更時。

（3）在需求承諾前，需要開發人員理解需求，一般sp1.1是本實踐的基礎。

（4）承諾可以是書面的簽字，也可以是電子的。

（5）並非每個人都要對需求做出承諾，可以是專案組的核心成員作為代表。

（6）開發組需要對客戶有正式的承諾，該承諾一般體現在合同或專案任務書中。

（7）開發人員的承諾可以是和對計畫的承諾合在一起，也可以單獨承諾，承諾的時機可能不同。

sp1.3

管理需求變更

（ 1

）需求的變化是永恆的

（ 2

）需求是漸變的，是積少成多的

（ 3

）需求的小的變化也要管理

（ 4

）不同規模的需求變更，控制的嚴格程度不同

（ 5

）在組織內應該區分不同規模的需求變更，並定義不同的流程

（ 6

）需求變更的重點是變更的波及範圍分析，在做變更的影響分析時，要考慮對：其他需求、對設計、對編碼、對測試、對進度、對工作量、對人員、對風險的影響。

（ 7

）需求變更時要參考需求跟蹤矩陣

（ 8

）需求變更的控制組應該有客戶參與

（ 9

）客戶方的需求變更流程也應該規範

（ 10

）在商務合同中要對需求變更的流程進行定義，規範雙方的介面

sp1.4

維護需求的雙向可跟蹤性

（ 1

）需求跟蹤矩陣的主要作用：

驗證需求的可實現性、可測試性；

進行需求變更的影響分析。

維護階段，管理需求的變更

（ 2

）何時使用需求跟蹤矩陣：

需求、設計、測試用例評審時；

需求、設計、測試用例等變更時；

功能審計時。

(3)

需求跟蹤矩陣分為：

縱向跟蹤關係：客戶需求到產品需求；需求到設計、測試用例、**：需求責任分配

橫向跟蹤關係：需求與需求之間的關係，該跟蹤關係對產品整合過程有影響。

（ 4

）在需求、設計、測試用例評審時跟蹤矩陣要一起評審

sp1.5

確認專案工作和需求間的差異

（ 1

）在需求評審時、計畫評審時、設計評審時、測試用例評審時要識別是否和需求一致。

（ 2

）在需求變更、設計變更、測試用例變更時，要判斷是否和需求一致。

（ 3

）在日常工作中也可能發現和需求的不一致。

（ 4

）識別出的不一致問題要有記錄，並跟蹤問題的關閉

需求管理過程域的要點

實踐 理解與實施要點 sp1.1 理解需求 與需求提供者一起理解需求的含義。1 先判斷需求提供者是否合適，即哪些人是合法的需求提供者，建立確認合適的需求提供者的準則,2 再判斷提出的需求是否可接受，建立需求可接受的準則 3 最後和需求提供者對需求達成一致的理解 4 上述的準則可以定義在需求開發計畫書...

五步走 軟體需求的管理過程

摘要 角色 職責描述 市場人員 負責discover階段所有工作，並幫助開發專案經理在define階段初期很快地了解業務和客戶 開發專案經理 協調discover階段的所有活動 負責完成需求文件 維護scope matrix。行業專家 提供行業諮詢 高層團隊 指導discover和define階段的...

spring boot bean 的管理過程

從磁碟中讀取 class檔案 放到map存放配置資訊的map中 需要時通過bean的名，從bean配置資訊容器中找到相應的配置資訊建立物件 當需要此物件時，bean例項容器中沒有時 會到配置資訊的map中找是否有此類的配置資訊 有就直接根據配置資訊建立物件放到bean例項池中 如果沒有則會丟擲nos...