探索與分享軟件工程中的創新
思考需求
是什么讓程序員們“改改改”！是什么導致程序員們“拖拖拖”！是什么導致開發團隊被奴役，陷入時間漩渦，使軟件質量失控？總結一下也許能找到100個理由，恐怕其中有50個理由和需求有關！毫不夸張的說需求問題摧毀了整個軟件。
我們需要的是一套完整的、正確的、一致的、可行的、無二義的、健壯的、必要的、可測試的、可修改的、可跟蹤的需求。然而哪怕需求分析師們使出渾身解數，哪怕他們使用了“洪荒之力”，需求的變化不可避免，這個環節的變化導致其它環節更大的變化，在這些變化中導致的疏漏難以避免。為此我們可以采取兩種措施應對。一種以不變應萬變進行需求凍結，一種順勢而為進行需求補充。
需求凍結意味著生產資源按既定的方案進行分配，并推進生產實施。不言而喻，它的風險在于輸出的成果與實際需求脫節，客戶得到他不想要的或者是過時的內容。為了避免這種情況，把需求目標定義的足夠小，然后快速完成必要的內容并交付。敏捷開發就是這樣一個理念，通過小目標的迭代來完成一個大目標。然而這并不是一個完美的方案，過時的內容意味著生命周期結束，當整個項目沒有結束時，就必須要替換已經處于生命周期結束內容，迭代變成了替換，也許就在替換過程中就出現了新的問題。如果采取強硬的姿態拒絕替換，那意味著軟件的某些功能不足，質量受到影響。
需求補充并不是那么輕松。需求的確定需要經歷采集、整理、測試、確認幾個過程。需求的變更使得生產者要不斷的在需求分析階段投入資源，在實際生產中這樣做恐怕會是難以承受成本投入。無疑這使我們陷入困境，難道我們對此就束手無冊了嗎？在中外各國的資料里沒有找到答案，這就需要自已想辦法解決問題！
我們需要對需求做一次需求分析。我國是一個高速發展的國家，這就意味著在政治經濟領域的變化快且頻繁。一黨執政多黨參政的政治協商制度使我國的政策延續時間較長且有累進的特征，政策轉向發生在某些明顯畸形行業里的概率較高，信息化尚屬于發展階段，對信息化產品的需求以內容為主。尚缺少核心的信息化基礎軟件產品，如操作系統，開發語言，驅動程序，虛擬化工具等。
在這樣的環境下，軟件需求普遍的矛盾在于對產品/項目的需求隨時間變化可能產生變化，而需求文檔只能靜態的表達當前的需求；用戶對新概念的產品/項目的認知不足，包括對它的內容、適用邊界、操作界面、操作方式、成本及收益等，導致需求文檔無法確切的表達這些內容。我們無法預測未來會發生什么事件，但從金融領域得到靈感，未來的發展趨勢未必不可預測。因此無法在需求文檔里體現變化的內容，但可以預估未來變化的趨勢。任何產品都會有一個生命周期過程，在這個周期中它的成熟度會有一個規律性的變化。描述它的規律可以使用戶比較直觀的理解產品或項目本身。因此在需求文檔里可以體現產品的成熟過程，以表達它的部分特征。從而使需求文檔本身就能包容有限的變化。
軟件的發展趨勢或者成熟度變化都是一個種抽象的、模糊的的信息，如果用大段的文字表達這種信息，極有可能會使每個使用者各有各的理解。因為每個人的知識、閱歷并不相同，對同一段文字所形成的思維模型出現差異并不奇怪。然而對需求文檔而言就會詞不逮理，這是典型的二義性特征。用盡可能簡單的圖表來表達，顯然會是一個目達耳通的策略。不論是發展趨勢還是成熟度變化，從邏輯上都是對“成長”的描述，這就為我們創建單一的表達方式創造了條件。
而我想到的最簡單的方法是在需求理整階段繪制一張“需求堆砌層次圖”。所有講需求分析的教材中都會提到“馬洛斯需求層次理論”，這個理論所搭配的圖就是一個層次圖。這個圖表達了每個層次的目標，層次與層次之間是一個直觀的演進方向。把需求采集的內容整理成這樣一張層次圖，不僅表達清楚了需求目標，也顯示出了需求演進。這為發掘潛在的需求提供了一種方法。
漢語的語言表達邏輯為建立層次圖的過程提供了便利。需求歸類為基礎需求、期望需求、興奮需求、反向需求，我把漢語詞匯歸納行為詞（通常是動詞）、修飾詞（通常是形容詞）和目的詞（通常是名詞）?？梢园l現一個經驗規律：在漢語構成了某一個需求描述中，修飾性詞往往表達了期望需求和興奮需求，目的詞很大概率表達了基礎需求，行為詞則表達了需求點呈現的聯系。而層次圖中底層表示的是基礎需求，頂層則有很大概率表達了興奮需求，上層是對下層的演進。然而我們還需要發掘隱藏的需求，需求描述也許沒有表達清楚實際目的，但描述信息則可能已經包含了實際目的的概念，因此把現有需求目的詞抽象化用這種方法探測潛在的需求。抽象化可能產生多個概念，這些概念可能只有一個與實際需求有關，此時行為詞呈現的聯系就能幫助我們篩選出那個真正的需求。這就完整的構成了“需求堆砌層次圖”。
如果有這樣一個需求：
一匹跑得更快的馬
| 需求描述 | 描述抽象 |
|---|---|
| 更快 | |
| 馬 | 動物，牲畜，交通工具 |
能發現什么嗎？
