開發需求

需求說明專案關係人希望從產品得到的功能。 您應該使用商業領域的詞彙和概念，以容易和商業專案關係人討論的方式來表達需求。 需求不應該討論實作，也不應該以實作為基礎。 需求不僅包括使用者對於行為和服務品質的預期，還包括法規限制和商業標準。

在 Visual Studio Team Foundation Server 中使用需求工作項目來記錄需求，具有下列優點：

• 透過將需求連結至測試案例，進一步確認需求獲得滿足。

• 透過將需求連接至工作項目，進一步監視實作需求的進度。

• 將需求按整體需求和細部需求的結構來組織整理，方便您進行管理，也方便進度報表彙總資訊。

• 透過將模型項目連結至 Team Foundation Server 中的需求，在 Visual Studio Ultimate 中建立需求的模型。

有關如何決定需求，目前已有十分大量的相關文獻，因此本主題不再加以贅述， 而是提出以符合 CMMI 的方式來使用 Visual Studio 工具的一些重點。如需 CMMI 的詳細資訊，請參閱 CMMI 的背景。

就像任何開發活動，本主題所說明的活動不應該以嚴格順序執行。 在撰寫情節的同時開發領域模型，因為這兩項活動將有助於改善彼此的品質。 等到撰寫情節程式碼的時機將至時，再開發情節。 將之前撰寫和展示程式碼得到的經驗，運用在尚未實作的情節。

本主題內容

何時開發需求

撰寫願景聲明

撰寫情節

建立商業領域的模型

開發服務品質需求

檢閱需求

驗證

檢查和編輯需求

何時開發需求

Team Foundation Server 支援反覆式工作，這種作法很適合用來運用早期反覆項目來取得潛在使用者和其他專案關係人的意見。這些意見可用來在未來的反覆項目改善所聲明的需求。 比起在相同的時間開發，卻未讓任何使用者試用的產品，用這種方式開發的產品將發揮大許多的效益。 如果您的專案只是大型程式當中眾多元件的其中一個元件，早點與其他元件整合可讓程式架構設計人員更有時間改善整體產品。

這些彈性必須在兼顧答應客戶或平行專案合作夥伴達成的時程和品質下進行。

因此，需求將能在整個專案中於受控制的情況下完成開發和調整。 在專案進行期間，細部需求會視情況變更，因此在尚未適當實作之前就決定所有細部需求，到最後都可能只是白費心力。

• 在反覆項目 0，請開發一組需求，這些需求說明主要功能，並只提供一些讓產品計畫足以成型的細節。 產品計畫負責將各個需求指派給各個反覆項目，並陳述當每個反覆項目結束時所要完成的需求。 建立由主要的概念和活動組成的領域模型，並且定義這些概念的詞彙，以便用於與使用者討論和用在實作過程中。 判斷所有功能都適用的廣泛需求，例如安全性和其他服務品質需求。

• 在每個反覆項目開始或即將開始時，進一步開發這些功能的細部需求。 判斷使用者會採取的步驟，並利用活動或順序圖表定義出來。 定義發生例外情況時要採取何種處理方式。

• 盡量經常去確認所有已實作的需求。 普及性需求 (例如安全性) 必須在每次一有新功能出現時，就以經過擴充的測試進行驗證。 可能的話，請將測試自動化，因為自動測試可以不間斷地執行。

管理需求變更

下列方針可協助您採取累進式程序，同時又能監視該程序以滿足 CMMI 規範。

• 不要變更已設定給反覆項目的需求。 萬一遇到環境突然生變的罕見情況，您可以取消反覆項目、檢閱產品計畫，然後啟動新的反覆項目。

• 找出需求中的不確定性。 試著安排計畫，讓早期反覆項目中的使用者經驗產生有助減少不確定性的資訊。

• 使用變更要求工作項目，將要變更已實作之行為的要求記錄下來 (除非該改善要求原本就是計畫的一部分)。 將每個變更要求都連結至適當的需求工作項目。 如需詳細資訊，請參閱變更要求 (CMMI)。

• 在每個反覆項目開始之前，不但要檢閱產品，還要檢閱變更要求。 檢查要求會對相依專案和使用者造成的影響，並且預估在您的程式碼中進行變更會衍生的成本。 如果接受變更要求，就更新需求。

• 因應每項需求變更來更新測試。

• 指定截止日期 (例如，過了反覆項目 2 或 3 後)，過了這個日期之後，必須有非常充分的理由才會接受需求變更。 如果專案是為了滿足付款的客戶，則這個日期也就是要讓客戶確認一組基本需求，並從小時計費轉變成固定計費的日子。

• 使用 Bug 工作項目，將未根據明確或隱含的需求來執行的已實作行為記錄下來。 可能的話，建立可攔截該 Bug 的新測試。

撰寫願景聲明

與小組討論出一份願景聲明，並將這份聲明展示在專案的 Team Foundation Server Web 入口網站上。

願景聲明是一份關於產品會帶來哪些優點的簡短摘要。 使用者將能夠做出哪些之前做不到的事？ 願景聲明有助於釐清產品的範圍。

如果產品已經存在，就為該版本撰寫願景聲明。 產品的使用者將能夠做出哪些之前做不到的事？

撰寫情節

與您的客戶和其他專案關係人一起討論來建立情節，然後輸入這些情節做為需求工作項目 ([需求類型] 欄位設定為 [情節])。

情節 (或使用案例) 是一小段故事，其中說明一連串事件、顯示如何達成特定目標，而且通常涉及人員或組織與電腦之間的互動。

請賦予其一個描述性標題，以便在清單檢視時能夠將之與其他項目清楚區別。 請確定已陳述主要動作項目，而且這些動作項目的目標很清楚。 例如，下面會是不錯的標題：

客戶購買餐點。

您可以撰寫下列形式的情節。 有時候多個形式並用會更好：

• 在工作項目描述中使用一個或兩個句子：

  客戶在網站上訂購餐點，然後使用信用卡付款。 訂單傳給餐廳，餐廳再準備和外送餐點。

• 在工作項目描述中使用編號步驟：

  客戶造訪網站，然後下單訂購餐點。 網站將客戶重新導向付款網站以進行付款。 訂單加入至餐廳的工作清單。 餐廳準備和外送餐點。

• 腳本。 腳本基本上是描述故事的漫畫。 您可以使用 PowerPoint 加以繪製。 您可以將腳本檔案附加至需求工作項目，或者是將檔案上載至小組入口網站，然後將超連結加入至工作項目。

  腳本特別適合展示使用者互動情況。 但是在商業情節中，建議使用草圖樣式，表明這不是最終的使用者介面設計。

• 需求文件。 需求文件可讓您針對每項需求，自由提供適當程度的詳細資料。 如果您決定使用文件，請為每項需求各建立一份 Word 文件，並且將文件附加至需求工作項目，或者是將檔案上載至小組入口網站，然後將超連結加入至工作項目。

• 統一標記語言 (UML) 順序圖表。 順序圖表特別適用於有多方互動時。 例如，訂購餐點需要有客戶、DinnerNow 網站、付款系統和餐廳以特定順序互動。 以 UML 模型繪製順序圖表、將之簽入 Team Foundation Server，並在需求工作項目中輸入連結。 如需詳細資訊，請參閱 UML 順序圖表：方針。

具體情節

先從撰寫具體情節開始，這些情節由依特定順序出現的一組特定動作項目組成。 例如，「Carlos 在 DinnerNow 網站訂購披薩和大蒜麵包。 網站將 Carlos 重新導向 Woodgrove Bank 的付款服務。 Fourth Coffee 準備和外送比薩。」

具體情節可協助您在腦海中形成使用中系統的圖畫，這在您第一次探索某個功能時可帶來最多幫助。

這也適用於建立具名角色，來描述人員和組織的背景與其他活動。 Carlos 不回家睡覺，整天待在網咖；Wendy 住在有大門警衛看守的社區；Sanjay 替在上班的太太訂購餐點；Contoso 在全球有 2,000 家餐廳；經營 Fourth Coffee 的夫婦是靠騎腳踏車來外送餐點。

較一般的情節是以「客戶」、「菜單項目」等詞彙撰寫，這樣雖然比較方便，但比較不容易讓人聯想到有用的功能。

詳細資料程度

在反覆項目 0，有些重要情節可多寫一些細節，但大部分的情節仍以大綱形式撰寫。 當需要實作完整或部分情節的反覆項目快要開始時，請加入更多細節。

當您第一次考慮情節時，說明商業環境資訊 (包括與產品無關的部分) 會很有用。 例如，說明 DinnerNow 外送的方法：是由每家餐廳組織自己的外送項目，還是由 DinnerNow 統籌外送服務？ 這類問題的答案可提供有用的環境資訊供開發小組參考。

您可以在反覆項目開始時開發更詳細的情節來說明使用者介面互動，而腳本可以顯示使用者介面配置。

組織情節

您可以使用下列方法組織情節：

• 繪製使用案例圖表，其中每個使用案例各代表一個情節。 這是建議的方法，因為這樣可以很容易呈現和討論情節。 如需詳細資訊，請參閱 UML 使用案例圖表：方針。

  • 將每個使用案例各連結至定義該情節的工作項目。 如需詳細資訊，請參閱 HOW TO：從模型項目連結至工作項目。

  • 繪製「擴充」關聯性，以顯示某個情節是另一個情節的變體。 例如，「客戶指定不同付款和外送地址」是基本「客戶下訂單」使用案例的擴充。 擴充特別適用於要特別分出來以放在以後的反覆項目中實作的情節。

  • 繪製「包括」關聯性，以區隔數個使用案例通用的程序 (例如「客戶登入」)。

  • 繪製一般化情節 (例如「客戶付款」) 與特定變體 (例如「客戶使用信用卡付款」) 之間的一般化關聯性。

• 在 Team Foundation Server 中的情節工作項目之間建立父-子連結。您可以在 Team 總管 中檢視階層。 如需詳細資訊，請參閱在產品計劃中排列需求。

建立商業領域的模型

建立 UML 模型，用以描述使用產品時涉及的主要活動和概念。 請在情節中、與專案關係人討論時、使用者介面與任何使用手冊中，還有程式碼本身，使用這個模型中所定義的詞彙做為「通用語言」。

有許多需求是客戶不會明確說出來的，要了解隱含的需求，就要靠您對商業領域 (也就是產品的使用環境) 的認識。 因此，在針對不熟悉之領域的需求收集工作當中，有一部分就是要獲得對於該環境的知識。 這類知識在建立之後，將可以用於不只一個專案。

以版本控制儲存模型。

如需詳細資訊，請參閱模型化使用者要求。

建立行為的模型

繪製活動圖表以彙總情節。 使用泳道以將不同動作項目所執行的動作分成不同群組。 如需詳細資訊，請參閱 UML 活動圖表：方針。

雖然情節通常會說明特定事件順序，但是活動圖表會顯示所有可能性。 繪製活動圖表可以提醒您考慮其他事件順序，並詢問您的商業客戶萬一發生那些事件應採取何種處理方式。

下圖顯示簡單的活動圖表範例。

如果訊息交換十分重要，使用順序圖表 (其中包含每個動作項目和主要產品元件的生命線) 或許更適合。

使用案例圖表可讓您彙總產品所支援的各種不同活動流程。 圖表上的每個節點都代表為達到某個特定使用者目標，使用者與應用程式之間的一連串互動。 您也可以將常見順序和選擇性擴充變成個別的使用案例節點。 如需詳細資訊，請參閱 UML 使用案例圖表：方針。

下圖顯示簡單的使用案例圖表範例。

建立概念的模型

繪製領域類別圖表，以說明情節中所提及的重要實體和其關聯性。 例如，DinnerNow 模型會顯示 Restaurant、Menu、Order、Menu Item 等等。 如需詳細資訊，請參閱 UML 類別圖表：方針。

以名稱和基數標示各關聯性的角色 (端)。

在領域類別圖表中，您通常不會將作業附加至類別。 在領域模型中，活動圖表會說明行為。 將責任指派給程式類別是開發工作的一部分。

下圖顯示簡單的類別圖表範例。

靜態條件約束

在類別圖表中加入控管屬性和關聯性的條件約束。 例如，訂單上的項目必須全都來自同一家餐廳。 這類規則對於產品的設計十分重要。

模型一致性

請確定模型和情節一致。 模型其中一個最強大的用處就是解決模稜兩可的問題。

• 讓情節說明使用模型中所定義的詞彙，並且與模型所定義的關聯一致。 如果模型定義的是菜單項目，情節就不應該將同一件東西說成產品。 如果類別圖表顯示一個菜單項目只出現在一個菜單上，情節就不應該談到讓項目出現在多個菜單上。

• 讓每個情節所說明的步驟序列都是活動圖表上所允許的步驟序列。

• 用情節或活動來說明類別圖表中每個類別和關聯性的建立和終結方式。 例如，在哪個情節建立菜單項目？ 何時會終結訂單？

開發服務品質需求

建立工作項目來指定服務品質需求。 將 [需求類型] 欄位設定為 [服務品質]。

服務品質 (或非功能) 需求包括效能、可用性、可靠性、取得性、資料完整性、安全性、可負擔性、服務性和升級性、傳遞性、維護性、設計，以及適用性和完成性。

針對每個情節考慮上述每個分類。

每個服務品質需求的標題都應該含有一個指出環境、動作和度量的定義。 例如，您可以建立下列需求：「進行類別目錄搜尋時，三秒內就要傳回搜尋結果」。

此外，加入更多詳細資料來說明這個需求為何必要的原因會更好。 說明角色為何會重視這個需求，以及為何需要達到這個服務等級。 提供環境和理由。 這樣的說明可能包含有用的風險管理資訊 (例如來自市場問卷、客戶焦點群組或可用性研究的資料)、支援工程師報表/票證，或其他傳聞證據。

將服務品質需求連結至任何受服務品質影響的情節 (需求工作項目)。 連結相關工作項目可讓 Team Foundation Server 使用者追蹤相依需求。 查詢和報表可以顯示服務品質需求如何影響以情節形式指定的功能需求。

檢閱需求

撰寫好或更新好的需求應該要由適當的專案關係人檢閱，以確保其已適當說明所有與產品的使用者互動。 常見的專案關係人包括主題專家、商務分析師和使用者經驗架構設計人員。 此外，情節也要經過檢閱，以確保可以在專案中實作，而不會發生任何混淆或問題。 如果發現任何問題，就必須修正情節，讓情節在這個活動結束時變可行。

建立檢閱工作項目以追蹤檢閱。 這個項目提供 Standard CMMI Appraisal Method for Process Improvement (SCAMPI) 評價的重要證據，同時也是未來進行根本原因分析時的良好資訊來源。

請檢閱每個情節以尋找下列特性：

• 情節是以下列來龍去脈撰寫：使用者必須執行的工作、使用者已經知道的資訊，以及使用者希望與產品互動的方式。

• 情節勾勒問題所在，且未因提議之問題的解決方案而晦澀難懂。

• 已識別所有與產品相關的使用者互動。

• 主題專家、商務分析師和使用者經驗架構設計人員從專案的角度檢閱每個情節，確認可以順利實作所有情節。 如果情節無效，則予以修訂，使其有效。

• 情節可透過現行可用的技術、工具和資源，在預算和排程內成功實作。

• 情節具有易於了解的單一解釋。

• 情節與其他情節不衝突。

• 情節是可測試的。

驗證

在產品出現最終版本之前，規劃將 Beta 版產品部署至工作環境。 根據專案關係人對於該部署的意見，規劃更新需求。

「驗證」表示確保產品在作業環境中真的發揮原本預定的用途。 在 MSF for CMMI 中，驗證是在整個專案期間的每個反覆項目結束時，向專案關係人展示功能正常的軟體來進行。 排程的安排，會讓開發人員在早期展示得到的使用意見，有時間可規劃在剩餘的反覆項目中落實。

為了達到真正的驗證，產品不能只在展示或模擬環境中執行。 只要可行，就應該以真實狀況測試產品。

檢查和編輯需求

情節和服務品質需求 (這是大部分開發工作的起源) 可以透過使用客戶需求查詢來檢視。 如果您偏好顯示所有需求，可以撰寫查詢來傳回所有屬於需求工作項目類型的工作項目。 設定結果的資料行，以顯示反覆項目路徑。 如需詳細資訊，請參閱 小組查詢 (CMMI)。

除了直接在 Team 總管或 Team Web Access 中檢視查詢以外，您還可以在 Office Excel 或 Office Project 中開啟查詢。 這些工具較方便用於批次編輯和加入工作項目。 如需詳細資訊，請參閱在連接至 Team Foundation Server 的 Microsoft Excel 和 Microsoft Project 中工作 和使用工作項目的樹狀清單執行由上而下的計劃 (在 Excel 中)。

您的小組應該在專案的早期反覆項目中就建立大部分的需求。 新的需求會加入，而舊的需求會根據從早期版本得到的意見進行調整。

其他資源

如需詳細資訊，請參閱下列 Web 資源：

• 功能驅動型開發實務手冊 (英文)，Stephen R. Palmer 和 Malcolm J. Felsing；Prentice-Hall PTR，2002 年。

• 最佳化物件模型：模式、規則和實作 (英文)，Jill Nicola、Mark Mayfield 和 Mike Abney；Prentice Hall PTR，2001 年。

• 敏捷式模型：最高程式設計和統一流程的有效實作 (英文)，Scott Ambler；Wiley，2002 年。

• 領域驅動型設計：解決軟體核心複雜性 (英文)，Eric Evans；Addison Wesley Professional，2003 年。

• 物件設計：角色、責任和共同作業 (英文)，Rebecca Wirfs-Brock 和 Alan McKean；Addison Wesley Professional，2002 年。