敏捷過程中的軟件需求分析

在日趨激烈的電信業競爭態勢下，持續而快速地發掘和響應商機成為新的課題。作為響應機制中的關鍵環節，需求工程應用敏捷過程方法，以關注商業價值、快速響應、持續迭代的特征來應對變化和難測的未來，是嘗試提高組織敏捷能力的核心。在這其中，作為溝通橋梁的需求分析同樣可以應用敏捷的過程方法參與到生命周期的演進。敏捷需求分析將在需求時機與過程、文檔要求、變更、參與者角色等方面展現其不同傳統的特性。本文將結合電信業背景及企業實際情況，對敏捷需求分析作出初步的探索。1. 敏捷需求分析：電信行業背景與敏捷過程的需要
從中國電信行業ITSP戰略推出至今，數年中我們已經看到了明顯的變化，作為其信息化體系落地的CTG-MBOSS，也已初具規模和成效。大規模實施的下一個階段，將是在商業價值引領下的重構競爭模式、市場細分，以及作為支撐的需求深入研究。在項目實施過程中，各種挑戰和困難紛至沓來，項目管理者不管是做時間、成本、質量的三角平衡，還是人與技術的雙向選擇，始終無法繞開的一個問題跟源是：如何快速響應環境的變化，使客戶在優化的體驗過程中滿足其商業目標，從而實現企業本身的價值？
用失控的過程膨脹來形容近10年的許多軟件公司的情形是很合適的。雖然有很多團隊在工作中沒有使用過程的方法，但是采用龐大、重型的過程方法的趨勢卻在快速增長，在大公司中尤為如此。但現實的發展確與此不相同步，競爭態勢造成了更多的不確定性和快速調整的機會。從近年ERP上線的平均速度來看，項目的交付時間都比較長，這讓用戶產生了顧慮[1]。但實際上軟件上線僅僅是一個軟件生命周期早期的階段，軟件的價值是在使用中體現出來的，其投資回報也只能在后期的運營得到完成。未來的變化如同納西姆?塔勒布的黑天鵝一般不可預測且重要，已知和過去瑣碎的重復并不足以預測未來的重大影響[2]。以預測性度量為控制基礎的過程模型，只能以經驗涵蓋一般性事件，所以與此同時，隨機應變，保持快速集成和持續改進以應對商業環境的不確定性，延長軟件的生命周期提高它的最大價值，從而為獲取更多投資回報提供保障，也成為軟件工程發展的必然。
敏捷過程（Agile Process）的主要優勢是能夠適應系統需求的不確定性，將客戶作為需求團隊中密不可分的成員，而在實現過程中盡量在最短時間內實現對用戶來說業務價值最大的需求；同時，敏捷開發（Agile Development）是一種面臨迅速變化的需求快速開發軟件的能力[3] ，它幫助處理了未來不確定性的問題；但是對于過去，應該沒有不確定的事。而敏捷需求分析，是面對迅速變化的商業狀況，提高其響應和組織成可理解和接受的需求說明并對敏捷開發作出能力保證的方法論。
2. 敏捷與過程改進和度量模型
從軟件工程發展起，過程改進在全球日益得到重視，ISO 9000/SW-CMM/CMMI各級的評估也在業界得以推展，這種氛圍下，以RUP等為代表的過程模型也得到了廣泛的應用。但與此同時，敏捷的論調卻異軍突起，方興未艾。軟件過程的多樣性，源于過程環境和層次的不同；而過程選擇的多樣性和CMMI目標的通用性決定了過程改進途徑的多樣化。
運用一系列重方法，將在應對商機方面造成挑戰；尤其是在企業的管理考核和過程模板仍更多的是一種瀑布式體系下，軟件的實現過程將在不同模型下搖擺卻顯得不那么靈活。一個合適的生命周期模型選擇是重要的，由于慣性的教育，瀑布在我們的工作環境中隨處可見。但如果不去分析CMMI等的實質，將無助于改進這一點而提高響應。
強調結構化方法與重型的管理策略，往往在內心中拒絕變更，把變更作為被管理甚至被“管制”的對象；而為了盡可能避免變更，常常要求開發之前的需求獲取、分析與定義要完整無誤且精確。這是一種理論上的理想狀態，盡管我們可以采取諸如CMMI的一些理念及過程改進模板對其管理，但實際上往往會出現與用戶商業價值要求的脫節；而為達成此目標，使得前期的需求開發工作變得小心翼翼，最終有可能在壓力與時間約束下難免簡單化而草草了事，在后期又不能得到及時的修正，從而形成一個隱患。
但實質上，重型、輕型過程方法論之間并不存在根本性的矛盾沖突[4]，這體現于它們最終理念和出發點的一致。把這些互補方法論拼在一起，“恰好可以發現整個軟件過程體系全貌的一部分”[4]。CMM/CMMI 中不包括更為具體一點的如何寫好需求，如何做好設計，如何寫好測試等許多方面的軟件工程技術、技能方面的指導，而這些恰好是敏捷的強項。敏捷方法整合了一套輕量的管理、過程和工程技術方法，這是它作為一種先進方法體系補充于CMMI 的地方。敏捷過程并不像業界所傳的那樣只適合小項目和新項目的研發，實際上它對于各種類型，包括企業所定義的A類、B類、C類在CMMI體系基礎上都是可取舍適用的。這需要過程體系間的適當裁剪和調整組合。敏捷需求分析，將在全過程中扮演銜接、溝通和滲透的作用。
3. 敏捷需求分析的過程特性
IEEE對需求的定義是用戶解決問題或達到目標所需的條件或性能；系統或系統部件要滿足合同、標準或其他正式規定文檔的條件或性能。 需求是設計、構造產品的前提，簡單地說，是必須完成的事及其所必須具備的品質。需求存在的原因要么是該類型的產品要求一定的功能和品質，要么是客戶希望需求成為提交的產品的一部分[5]。
軟件需求包括三個不同的層次—業務需求、用戶需求和功能需求—也包括非功能需求。業務需求（ business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用用例（use case）文檔或方案腳本（ s c e n a r i o）說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性( f e a t u r e )是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。[6]

圖1. 需求的層次及組成
（對于上段文字的部分描述及圖1，參考資料[6]并對
原文進行了部分改編，并非全部的引用，請注意鑒別）
我們可以看到，不管是傳統的還是敏捷的需求開發階段，需求的層級及組成，其基本特性是一致的，這反映方法的差異并不改變需求的本身屬性。一般的需求三個層次，忽略了一個問題，即每個層次所需的知識、技能、經驗、背景等是不同的，不同的層次過程中，需要不同資源的整合。業界相關的論述中，只是給出了籠統的需求分析人員的統一角色，但并未對其作出區別。實際上，這很難映射到中小企業的現實操作層面。

原文轉自：http://www.anti-gravitydesign.com