模板
教程
環境
性能
功能
管理
為開發人員提供的需求管理實踐
| 引言 作為開發人員，是否常常有人要求您對代碼作一些小小的改動，從而使現有系統得到改進？您是否感覺這樣的請求無處不在？您經常依據的規格說明書是否完整或精確？是否經常不清楚這些需求要表達的真正意思是什么？是否感覺無法真正解需求，因此覺得目標也總是在變化？是否感覺的自己就像是鞭梢，總是隨著客戶的變化而變化。 如果您對以上任一問題的答案是肯定的，那么請繼續閱讀下文，您的問題很有希望得到解決。作為開發人員，您可能認為需求管理(RM)不如設計和實現技巧來得重要。實際上，很多開發人員認為 RM 是項目團隊中分析人員的責任，開發人員在此過程中的任務僅限于接收需求規格說明書。在一個項目中，如果開發人員的角色僅限于需求的接受者，那么您會發現經常需要返工。這將導致延誤項目交付日期，縮小項目的范圍，而且導致交付給客戶的項目質量不合格。而這些將最終導致客戶不滿，客戶的不滿意反過來又會影響項目團隊的士氣和心情。在成功的項目中，開發人員在 RM 中涉足的范圍更廣，扮演著較為重要的角色。這使得他們對開發對象具有更好的控制力，最大程度地減少返工量，最終也就能夠給向客戶交付正確的解決方案。 本文旨在說明在一個成功的軟件項目團隊中開發人員在 RM 中扮演的重要角色。此外，本文還提供了一些 RM 實施方面的技巧，開發人員可通過應用這些技巧，幫助項目團隊在為客戶提供正確的解決方案方面取得更大的成功。 開發人員為什么要關注需求管理？ 理解開發人員在 RM 中的重要性，有助于反映 RM 的目的。RM 的目的是在客戶和軟件組之間建立共識，其內容包括查找、文檔化、組織并跟蹤不斷變化的需求。與客戶達成共識是計劃和管理項目的基礎。如果項目團隊不能有效管理需求，那么他們達到關鍵里程碑的能力就會受到損害，進而影響項目計劃的精確度和效用。這通常導致開發和測試資源被浪費在錯誤方面。開發人員在 RM 上扮演了重要角色，不僅因為他們根據需求構建軟件，而且因為他們能夠防止項目團隊一開始就使用不完整或者模糊需求。最大化需求的完整性和清晰度是保證整個項目成功的轉折點，可以確保包括測試人員和文檔編寫人員在內的整修團隊能夠在最短的時間內構建質量合格的系統。 RM 的正式程度因項目和項目團隊而異，并且與您的項目團隊在不能交付正確的軟件解決方案方面愿意冒多大的風險直接相關。RM 過程的正式程度越差，項目團隊不能向客戶交付令他們滿意的軟件的風險就越大。幸運的是，項目中 RM 的松散程度是權衡 RM 形式的優缺點之后所作的一個簡明的決定。關于采用松散 RM 過程的最常見的論據包括：它可以使的開發速度更快，可以更好地適應不斷變化的市場，并且不需要正式的需求文檔來了解我們應該創建什么系統。不幸的是，這些論據是項目團隊很難實際把握的，并且需要仔細分析項目成功所需的 RM 正式程度。從根本上說，RM 實踐應該產生：1）所有項目團隊成員都能夠清楚理解的需求，2）對不斷變化的需求的控制，以保證項目團隊能夠跟蹤正確解決方案的交付，3）有效的溝通，以保證整個項目團隊協調一致。 有時使用非常正式的 RM 實踐可能是小題大做。比如，如果您的項目團隊任務是構建一個視頻游戲，那么擴展請求和需求變更就可能頻繁出現，以至于隨后如果使用傳統變更控制過程（需要變更控制委員會的批準）實際上可能妨礙項目成功。這種情況下，變更控制過程實際上限制了開發人員的創新，并且成為軟件交付的瓶頸。然而，即使在這種情況下，項目團隊仍可以使用諸如故事板或原型這樣的RM技術在開發和交付之前驗證游戲創意，并從中獲益。 在另一個極端上，也有極其需要使用非常正式的 RM 實踐的時候。比如，如果項目團隊的任務是開發一個運行醫療設備的軟件，它能根據情況自動管理病人的精確的、正確的用藥量，那么項目團隊就應該采用高度正式的 RM 過程來保證開發出正確的系統。這種情況下需求錯誤的風險可能危及人的生命安全。 那么 RM 如何影響像您這樣的開發人員呢？諸如 Standish Group 報告（見參考文獻）這樣的研究表明，需求錯誤是修復成本最高的錯誤，因為它們出錯的時間越長，影響就越大。隨著軟件開發生命周期的進展，這些錯誤越來越難以糾正，這實際上產生了雪球效應。如果您從一個錯誤的需求或者需求變更開始，那么您的設計就是無效的，這最終會導致進行代價昂貴的構架返工。確認測試也是錯誤的，用戶文檔也不精確，等等。最終，這將導致花費更多的時間來修復問題，而這些是完全可以避免的。 但您是開發人員，而不是分析人員。RM 不是僅用于分析人員的嗎？可以肯定的是，您項目團隊中代表客戶的那些人涉入 RM 最深。分析人員通常負責創建需求。然而，需求的質量不僅僅落在分析人員的肩上。記住，整個項目團隊對需求有一個完整清楚的理解是至關重要的。為了實現這種質量，開發人員必須盡早參與，以幫助澄清最初需求版本中的模糊性。開發人員提供了一種實現視角，能夠提高已編寫需求的質量，并且能夠增加開發解決方案的成功率。與開發人員的合作是"如魚得水"；開發人員負責將概念轉化為現實。因此，開發人員越早參與需求的澄清，項目成功交付正確的軟件解決方案的機會就越大。 開發人員還應該關心適當的 RM，因為它可以簡化他們的工作。當從高質量的需求而不是很差勁的需求（這樣的需求總需要團隊成員查找測試內容，并且用各種問題打斷開發人員）開始工作時，質量保證（QA）或質量工程（QE）和文檔編輯團隊的工作就更有效率。另外，維護活動可以減少到只專注于系統中真正的實施缺陷，而不是由不清楚和不完整的原始需求導致的缺陷。更高質量的需求最終能夠保證軟件的質量更高，這使得開發人員可以集中精力思考如何對系統作出改進。 與拙劣的需求管理相關的軟件問題 問題1：持續變更 該需求問題的根源在于，項目團隊在接受變更或擴展請求之前不能正確評估它們的影響。 讓開發人員對這些直接請求作出響應，可能導致項目團隊不能正確評估接受變更的整體影響。結果，如果開發人員接受這些乍一看很小的請求，就會導致必須對代碼的其他部分作出必要變更的漣漪效應。同樣，漣漪效應超出了代碼范圍，擴大到了項目團隊的其他領域。比如，如果沒有將變更有效地通知測試人員，那么他們可能就不能構建出必要的驗證腳本來測試變更，從而帶來了影響軟件質量的風險。此外，即使變更只需要開發人員的一點點努力就能實現，但是對 QA/QE 或文檔的影響可能延誤整個項目進度。由于漣漪效應的存在，整個項目團隊為出現的變更召開會議就很有必要。 由于這些依賴關系，開發人員將接受變更的權利委派給項目團隊中對項目交付有著高度和完整預見性的人就變得很重要。為了降低破壞項目穩定性的風險，您只希望接受被項目團隊批準的變更，這樣您就知道您正在實現的是一個商定的功能，并且每個人都有義務測試和記錄該功能。
解決辦法：通過評估變更的影響控制需求變更 需求規格說明書應該經過由客戶、開發團隊和測試團隊三方代表組成的小組批準之后才能進行變更。這個小組通常被稱為 CCB。該組的職責是從客戶的角度、開發的角度、測試和文檔化的角度評估每一個被請求的變更。根據應用程序類型的不同，培訓和支持人員可能也需要參與進來。 為什么需要所有這些人參與呢？因為每個代表都在分析實施給定變更請求的潛在影響或成本時具有不同的視角：
為了保證評估過程的有效性，CCB 的每個成員應該負責查找一個適當的替代品，以防萬一，從而保證對變更請求的評估絕沒有偏見。對于所有方面都沒有代表的罕見情況，應該將變更請求推遲到以后再評估。 好的 RM 實踐應該防止開發人員匆忙地對事情做出變更。需求的變更方面，從您編寫它們開始直到交付軟件，都是項目中最難應付的事情。Standish Group 在它 2001 Extreme Chaos 報告中指出："變更需求就像死亡和稅收一樣確定無疑"。掌握管理變更需求的技巧對于項目的成功很重要，并且它還是一種直接影響開發人員生活的實踐。 迭代開發取代傳統的瀑布型方法對管理需求變更是一種很大的幫助。在傳統方法中，需求規格說明書在項目一開始就被凍結了，并且直到軟件發布之后變更還不能加入進入。讓變更進入版本中的唯一方法就是直接找開發人員，請求他們變更代碼。這也正是我們前面看到的由于不能評估變更對項目真正的總體影響而導致項目不穩定的方法。迭代開發允許軟件團隊將工作分割成小的部分，其中需求是穩定的并且在迭代過程中保持不變。在下一次迭代開始時，團隊就有機會更新需求規格說明書，以加入上一次迭代中提交和接受的變更。在迭代開發中，規格說明書只在迭代開始時發生變更，而不能在迭代過程中進行變更。這使得我們可以在迭代期間把注意力集中在一組需求上。當下一次迭代來臨時，您就會被分配一組缺陷和新的或更新過的需求。
問題2：處在影響您工作的變更的盲區 即使在實際中，QE/QA 和文檔化通常比開發人員更處于盲區之中，經常出現這種情況：沒有及時將間接影響開發人員工作的變更通知開發人員。團隊中的分析人員可能與另一位開發人員討論，衡量變更的影響，但是卻沒有意識到它可能對開發人員工作的影響。 解決辦法：需求變更通知 如何知道需求變更何時會影響您的工作？除非您團隊中的某個人對需求與實現這些需求的設計要素之間的關系進行跟蹤，否則很難快速評估需求變更對設計的影響。好的RM都對需求和設計工件之間的依賴關系做了跟蹤，以便在需求發生變更時您能查明設計的哪一部分受到影響。 由于需求是不斷變化的目標，所以RM的一個主要利益是能跟蹤需求是否被實現。這就是所謂的可跟蹤性。存在各種級別的可跟蹤性，但不幸的是，同時也有許多方法在濫用可跟蹤性?？筛櫺缘娜蝿帐潜ＷC您為客戶許諾的功能能夠真正實現（由開發人員來完成），并且按照指定的要求工作（由測試人員確認）。為了保證能夠實現需求，并評估需求變更對設計的影響，需求應該被跟蹤到設計元素。為了保證需求發生變更時能夠得到驗證同時測試驗證也得到更新，需求應該被跟蹤到測試工件（通常為測試用例）。 從需求跟蹤到源代碼會如何呢？雖然乍一看很有吸引力（比如，如果我變更一個需求，我知道哪些代碼必須更新），但實際上代碼在本質上比需求更具動態性。您可以從一個設計開始，然后優化該設計。新設計可能會導致代碼變更，但是它仍與需求一致。維護可跟蹤性鏈接需要花費時間，但是軟件團隊永遠也沒有足夠的時間。所以您應該明智地使用可跟蹤性?？筛櫺缘恼嬲齼r值在于將需求跟蹤到設計和測試。編寫代碼實施規格說明書的方法有很多種，但是最終用戶不會關心您編寫的代碼是什么，只要它滿足需要就可以了（需求是清楚無誤地向整個軟件團隊表達這些需要的媒介）。這種情況的一個例外是如果您工作的系統經過了標準實體（如 FDA）的審計，該標準實體托管了從需求到代碼（有時甚至幾行代碼）的可跟蹤性。即使這種情況，您在構建軟件時仍不應該將需求跟蹤到代碼。您只需要報告最終產品需求跟蹤到了代碼，并且每段代碼都實現了一個需求。管理需求和源代碼之間的可跟蹤性鏈接可能是一個沒有多少實效的耗時工作。
問題3：根據不完整的需求規格說明書編寫代碼 盡管分析人員通過RM會議、聯合應用開發（JAD）會議、會見或者專題組收集和文檔化需求下了不少功夫，但是開發人員在第一次讀完需求之后還是有很多疑問。不管分析人員多么專業，都會出現這種情況。通常，開發人員只提供了一個可能被分析人員忽略的不同的視角。比如，開發人員通常會提出系統用戶可能遇到而分析人員卻沒有意識到的異常情況。因此，開發人員和分析人員必須緊密合作，在開始設計之前精化原始的需求規格說明書。開發人員應該無拘束地向分析人員提出有關需求規格說明書的問題，而分析人員則應該提供答案，必要時甚至可以直接與客戶聯系。
解決辦法：詳細且無歧義的需求規格說明書 除了檢查之外，另一種可用的有效實踐是使用用例來表達功能需求。用例通過從用戶的觀點將系統功能記錄為一系列步驟描述了系統與外部世界交互時的行為。該視角為軟件團隊和他們的客戶提供了對待建系統的預期行為的共同理解。通過最小化需求誤解的風險，用例還能夠提高需求的清晰度。比如，在使用用例的項目中，分析人員通常只注意主要用例（關于如何使用系統的用法場景）并且相信沒有大問題。然而，一旦開發人員開始通過識別所有備用流（在出錯情況下的備用用法場景）來整理用例的細節，真正的問題就浮出水面。如果開發人員在設計之前沒有進行這種細化，那么該設計就需要多次返工，以便包含所有的用戶場景。該細化過程中，能否在開發人員和分析人員之間建立起關鍵的交流關系，通常決定了能否成功交付最終產品。 然而，必須注意到并非所有需求都可以用用例表達。比如，可靠性和性能需求更適合以聲明性的形式表達（如，"系統應該……"），但是用例確實提供了一種從各種視角記錄系統的用戶體驗的機制。通過專注于用戶觀點，用例還避免了在需求規格說明書中引進設計元素的問題，從而將設計者從無根據的設計約束中解脫出來。
問題4：根據過時的需求規格說明書編寫代碼
解決辦法：最新的規格說明書隨時可用 在機構中改善需求管理的六種技巧 技巧1：參與建立變更請求過程
技巧2：在加強已建立的變更請求過程中學會說"No" 為了幫助控制影響您項目團隊的持續不斷的變更，您必須學會向請求者說"不"，并且將他們引導到您已建立的變更控制過程。這看上去可能很容易，但是這通常會導致高壓情形。比如，最成功的銷售人員可能很有影響力和說服力，并且通常是很多特別請求的煽動者。銷售人員通過說這樣的話來施加壓力，"如果您添加那個特性我就用不著 XYZ 賬戶了"或者"我最近從競爭對手那里丟掉了很多生意，因為我們沒有 ABC 特性"。不管他的論據看上去多么充分，您和開發團隊都必須表現出堅定的原則，并禮貌地將這些請求者引導到您已建立的變更控制過程中。這些請求者的行為不可能一夜之間改變，但是假以時日，一定會有所改觀。
技巧3：建立和參與需求規格說明書檢查 作為開發人員，應該主動參與這些檢查會議，并且應該在對需求的解釋的基礎上準備一個初步的設計或者概念。該過程本質上是高度迭代的，因為在開發團隊能夠對需求有一個清楚的理解并且開始設計之前通常需要多次會議。同樣，通過這些迭代，保證所有變更被正確捕獲和記錄就是分析人員的責任了。在您以及其他開發人員開始設計之前，整個項目團隊必須對所有需求有一致的理解。 此外，需求規格說明書檢查的迭代本性為項目團隊提供了一種自我檢查機制，保證了軟件需求和初步設計的質量。通過保持這兩個工件的同步，項目團隊會保持同步前進，并增加交付成功解決方案的機會。因此，在實際階段應該分配時間進行需求規格說明書檢查。經常在設計階段，很多開發人員在需求規格說明書檢查中發現更多的含糊性需要澄清。這里再一次需要需求規格說明書檢查。 技巧4：需要一個術語表 項目團隊的任何成員都可以建議分析人員在術語表中添加詞匯，但是整個項目團隊必須對詞匯的定義達成一致。作為開發人員，您必須保證清楚地理解了影響您正負責開發的系統領域的關鍵詞匯。
技巧5：堅持項目遠景以幫助提供解決方案的環境 讓我們暫且考慮一下車模配件吧，完全包裝在一個很好看的盒子里，盒子上印著一個完整的汽車。您打開之后會看到說明書以及大量需要粘合在一起的零部件。如果您只是一頭扎進說明書，開始構建您的車模，那么您將不能得到包裝盒上所描繪的漂亮的小汽車。您將得到一個不倫不類的東西。然而，如果仔細研究盒子上的圖片，然后再根據說明書組裝汽車，那么您將得到正確的最終產品，一輛令您興奮的小汽車。在這項比喻中，盒子上的汽車圖片就像是遠景，說明書就是需求。同樣，在軟件項目中，項目團隊需要知道遠景，以便為客戶構建正確的解決方案。作為開發人員，在您研究需求并開始設計之前，先檢查項目的遠景文檔。如果它不存在，那么可以向項目領導人或者分析人員提出該問題，并堅持讓他們為您開發一個。這樣就可以節省大量的時間，避免浪費在開發無用軟件上。 技巧6：采用用例來說明系統功能 此外，用例故事板是構建用戶接口原型以確認需求的另一種不錯的方法。用例故事板是關于用例中描述的功能如何以用戶接口表示的邏輯和概念性描述。用例故事板尤其適用于理解可用性需求。它們代表了用戶接口的高級理解，并且開發起來比實際的用戶接口更快。用例故事板因此可用于在各種用戶接口被原型化、設計和實現之前對其進行討論。 編寫良好的用例已成為一種實踐，IBM Rational 在 Rational Edge (http://www.therationaledge.com)上提供了關于如何編寫良好用例的在線研討會和各種文章。此外，對于現有的 IBM Rational 客戶，Rational Developer Network 上也有大量的信息。 利用工具自動完成需求管理過程 IBM Rational 提供了完整的 RM 解決方案，包括 IBM Rational Unified Process? (RUP?)中的過程指南、利用 Rational RequisitePro? 進行的工具自動完成，以及來自 Rational University (http://www.rational.com/university/index.jsp)的公共或現場課堂。IBM Rational還通過當地的客戶服務部門提供了各種形式的現場專業服務。 需求管理最佳實踐 圖1 Rational Unified Process 中的最佳實踐 RUP 還包括工具指導，告訴您如何利用 Rational RequisitePro 實現 RM 最佳實踐。 圖2 Rational RequisitePro Tool
Mentor--Rational Unified Process 中的工具指南 一種用于開發人員的需求管理工具
大多數開發人員發現 Rational RequisitePro 是最容易使用的需求管理工具，因為它集成了 Microsoft Word，而他們已經收到的需求規格說明書可能就是 Word 格式的。 圖3 Rational RequisitePro--需求數據庫與
Microsoft Word 的緊密集成 為了對 Rational RequisitePro 有大致了解，請看下面的演示記錄：
利用開發工具訪問需求 這些集成提供了從用例圖（記錄在 Rational XDE 或 Rational Rose 中）到用例規格說明書（存儲在 Rational RequisitePro 中）的無縫導航。利用這些集成，RequisitePro 將用例規格說明書作為真正的需求文檔維護，從而保證您在文檔化軟件用例的同時得到管理需求的所有利益。 關于這些集成的更多信息，請見 Rational Web 站點上的用例管理白皮書(www.rational.com/products/reqpro/whitepapers.jsp)。 結束語 通過拒絕未經批準的變更，并且在開始設計軟件之前對需求文檔中的模糊性和完整性提出疑問，能夠減少日常返工和挫折，并且還會幫助團隊交付真正解決客戶問題的軟件，而這正是在軟件行業中成功立足之本。 伴隨著快速交付軟件的壓力，需求從一開始就要正確也變得越來越重要，因為您可能沒有機會修復因較差的需求而導致的缺陷。由于需求對開發生命周期其他部分的影響（它們定義了設計內容，測試內容，以及用戶手冊內容），需求錯誤已經成為軟件項目中成本最昂貴的錯誤。但是一旦您知道了要注意哪些方面之后，就可以相對易于避免需求錯誤。我們希望本文能夠在需要注意的這些方面為您指點一條迷津。 原文轉自：http://www.anti-gravitydesign.com 
|
