計劃專案 (CMMI)
就規劃專案來說，大家都期望得到的計劃中包含範圍、時程、預算、風險管理計劃等資訊，並得到所有專案關係人的承諾和核准。 在大家一致通過的專案計劃中，您的進度會是先分析、設計、開發、測試，最後才是交付。
您可以使用反覆開發方法來降低風險。 反覆項目能讓您在每個反覆項目完成時示範可部分運作的產品，並依據示範時得到的意見採取動作。 因此，計劃能提供整體的架構，在各反覆項目開始之前，也會隨時加以檢閱與修改。
收集需求並將需求模型化
這個活動是和商務專案關係人、可能的使用者及主題專家討論系統應該具備的功能。 了解業務環境是很重要的事。 如果要求您為警務人員撰寫應用程式，若能了解他們的專用術語、程序及規定的話將更有幫助。
UML 模型是有助於表達及思考複雜關係的工具。 您可以在 Visual Studio 繪製這些項目，並將它們連結到其他文件和 Team Foundation 工作項目。 如需詳細資訊，請參閱模型化使用者要求。
在專案進行時更新及修改需求模型。 在每個反覆項目進行時，將更詳細的資料加入和該反覆項目相關的模型中。 您可以從模型衍生出驗證測試。
建立遞增的產品需求
從客戶收集來的需求和排定遞增開發之時程的目的間並沒有直接的關係， 例如，為了要釐清使用者在網站上購買某項商品的程序，您可能已經寫好一系列的詳細步驟：客戶瀏覽型錄、將商品放入購物車、結帳、提供地址及付款、倉庫排定交貨時間等。 這些步驟 (或同等的活動圖表) 並不是遞增的需求。
反之，系統中的第一項遞增項目可能只提供一項商品販售、交貨到一個地址，並僅使用付款服務執行一項測試交易。 第二個遞增項目可能是提供含有簡單清單的型錄。 之後的遞增項目可能會加入讓客戶選擇商品包裝或要求其他供應商提供的型錄等選項。 某些遞增項目可能與服務品質有關，例如，處理 1,000 位客戶 (而不只是一位客戶) 的能力。
換句話說，早期的遞增項目應著重於端對端的主要使用案例，然後再逐漸加入功能。
如果您要處理現有的產品，原則仍然相同，只不過您是從現有的功能開始。 如果您不熟悉產品的內部設計，更新的成本可能會難以估計。 因此，在估計早期的變更時，大方一點也無妨。
如需詳細資訊，請參閱開發需求。
輸入和編輯產品需求
在 Team Foundation 中將遞增的產品需求記錄為需求工作項目，並將需求類型設定為 [功能]。 使用 TWA 或 Team Explorer，您可以建立 要求的待處理項目 。 如果您想要同時建立數個工作項目，您可以使用 Excel。
評估產品需求
開發小組應評估開發每個產品需求時的必要工作。 在輸入這些評估時應以小時為單位，於工作項目的 [原始評估] 欄位中輸入。
在專案的早期，需要的只是大略的評估。
請將大型的產品需求細分成較小的需求。 最理想的情況是，每個產品需求都只需要幾天的開發時間便能完成。
將產品需求指派給反覆項目
商務專案關係人代表和開發小組應協力將產品需求指派給反覆項目。 這項作業通常會在會議中進行，因為您可以在會議中分享或投影「產品需求」查詢的 Office Excel 檢視。
這項指派作業是利用下列資訊來完成的：
需求的優先順序。 請參閱下一小節的備註。
評估後的成本。 在指定小組成員的數量和反覆項目的時間長度後，每個反覆項目都只有固定數量的時數能用來進行開發。 此外，將有一定數量時數會用來規劃反覆項目與其他和開發不直接相關的工作。
產品需求間的相依性。 在一系列遞增的需求中，最簡單的需求必須在相同領域中的加強功能之前優先處理。
您可以指定各種資訊，藉此定義工作項目中的需求，如下圖所示：
.png "Requirement work item form")
一些和排定優先順序有關的方針
有許多用於排定優先順序的詳細配置。 在考量反覆項目的規劃時，我們會檢驗這些配置中的某些配置。 由於我們現在仍處於專案層級，因此要納入一些有助於風險管理和充分發揮附加價值的方針。
將基礎的端對端案例優先排序。
盡可能努力在專案早期完成簡單的端對端案例。 稍後再將更多功能加入案例的其他部分。 這種做法可確保在早期實現平台的主要功能和需求的主要構想。
相對地，請勿根據架構細分排程。 因為一項依序完成資料庫、業務邏輯和使用者介面的排程一定會經歷許多重新作業才能在結束時整合各個部分。 相同地，我們也不建議水平分隔，例如 {銷售元件；倉庫元件；付款元件}。 這種做法也許會產生完美的網路購物系統，但在這項業務能從客戶處獲得營收之前，便已將時間花費殆盡。 僅當完整的元件確實屬於選用的附加套件時，才將這些元件排程在較後期的反覆項目中。
將技術風險優先排序。
如果案例中的項目含有技術風險，請在排程的早期進行開發。 對風險採取「及早準備」的方式。 如果有無法完成的項目，您會希望能在專案早期便得知，這樣才能取消該項目或以替代方法來取代。 因此，請將含有技術風險的需求優先排序在早期的反覆項目中。
將可降低不確定性的措施優先排序。
業務專案關係人可能會不確定某些需求是否合適。 要預料何種產品行為能在業務環境中獲得最佳結果是很困難的。 因此，請將能降低不確定性的工作優先排序。 開發較簡單的案例供使用者實驗通常便能達成此目的。 請將完整案例延至較後期的反覆項目，此時，這些實驗的結果便能做為參考。
將較有價值的需求優先排序。
若可以的話，請嘗試針對各案例建立延遲機會成本功能。 使用這些案例決定哪些需求能夠盡早帶給客戶更多價值。 請將這些需求優先排序在早期的反覆項目中。 這也許能讓您選擇是否要提早發行一部分的產品。
把多位人員通用的案例分組。
如果您的案例中有適用於兩位以上人員的公用程式，請將這些案例分為同一組。 再依照需要這些案例的人員數量來排序。 請將適用於許多人員的案例優先排序在早期的反覆項目中。
把人員排序。
人員可代表市場區隔或使用者群組。 行銷人員或企業擁有人應該能依據要交付的公用程式或區隔的價值說明這些區隔的優先順序。 如果區隔或使用者群組能按照優先順序排序，請按照順序列出每個區隔的人員。 請找出順序最高之人員的案例，並將其優先排序在排程中較早期的反覆項目。
一般說來，我們會優先排序降低風險的措施是為了避免失敗。 我們會優先排序通用的功能是因為這些功能很可能會用到，且不太可能會變更。 我們會將較有價值的需求優先排序。 我們會優先排序所有滿足任何人員之需求所需的案例，以便選擇是否要提前將產品發行給人員的子集。
規劃測試
每項需求的工作預估必須包含測試需求時所需的勞力，不論是手動測試或是建立自動化測試。
每項產品需求必須連結至一組測試案例工作項目 (這些測試案例工作項目能示範需求是否已滿足)，且必須通過測試才能將專案視為完成。
當您在建立或修改產品需求時，請務必更新對應的測試計劃。
修訂產品需求
請在每個反覆項目開始前重新審視此活動，以考量是否要修訂或新增需求、修訂優先順序及修訂預估。 在前幾個反覆項目中會發生較多修訂。
在經歷過前幾個反覆項目之後，開發小組的成員將會對預估較有信心。 他們會在接下來的一或兩個反覆項目中逐一檢視預估，並修訂先前指派給反覆項目之需求的 [原始預估] 欄位。