需求的是是非非

需求是一個過程，一個在軟件生命周期中很重要的過程。在上一篇中，我們討論了需求的層次、需求的風險、需求的特點。而在這么多需求要素之上的要素只有一個：溝通。溝通是什么，說小了是需求過程的重要技巧，說大了是軟件企業的生命線。一個項目失敗的原因有很多，而絕大多數都可以總結到溝通不暢。需求過程中充滿了溝通：需求分析員和用戶的溝通，不同的用戶之間的溝通，需求分析員和需求審核人員的溝通，項目經理和需求分析員的溝通。溝通到一個什么程度，是需求成功與否的標志。

曾經和幾個老同學聊天的時候說起他們去用戶哪里做需求調研，用戶報來一堆資料，和他們聊了半天，他們就回去開始設計、編碼。我說你后面肯定吃苦頭了。果不其然，項目返工的時間差不多等于整個項目的時間。這太可怕了，意味著這個項目企業極可能虧本。為什么會這樣呢？項目好比一座大樓，如果設計師連大樓要蓋多少層都不清楚，那你說蓋出來的會是個什么東西。

《軟件需求》一書中提到了一個很有意思的概念：軟件客戶需求義務和權利

優秀的軟件產品是建立在優秀的需求基礎之上的。而高質量的需求來源于客戶與開發人員之間有效的交流與合作。通常，開發人員與客戶或客戶代理人，如市場人員間的關系反而會成為一種對立關系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦，在這種情況下，不會給雙方帶來一點益處。

只有當雙方參與者都明白要成功自己需要什么，同時也應知道要成功合作方需要什么時，才能建立起一種合作關系。由于項目壓力與日漸增，所有風險承擔者有著一個共同的目標這一點容易被遺忘。其實大家都想開發出一個既能實現商業價值，又能滿足用戶需要，還能使開發者感到滿足的優秀軟件產品。

軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求。每一項權利都對應著軟件開發人員、分析人員的義務。而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務。如果愿意，可以將其作為開發人員的權利書。

軟件客戶需求權利書

1. 要求分析人員使用符合客戶語言習慣的表達。
2. 要求分析人員了解客戶系統的業務及目標。
3. 要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規格說明。
4. 要求開發人員對需求過程中所產生的工作結果進行解釋說明。
5. 要求開發人員在整個交流過程中保持和維護一種合作的職業態度。
6. 要求開發人員對產品的實現及需求都要提供建議，拿出主意。
7. 描述產品使其具有易用、好用的特性。
8. 可以調整需求，允許重用已有的軟件組件。
9. 當需要對需求進行變更時，對成本、影響、得失（trade-off）有個真實可信的評估。
10. 獲得滿足客戶功能和質量要求的系統，并且這些要求是開發人員同意的。

軟件客戶需求義務書

1. 給分析人員講解業務及說明業務方面的術語等專業問題。
2. 抽出時間清楚地說明需求并不斷完善。
3. 當說明系統需求時，力求準確詳細。
4. 需要時要及時對需求做出決策。
5. 要尊重開發人員的成本估算和對需求的可行性分析。
6. 對單項需求、系統特性或使用實例劃分優先級。
7. 評審需求文檔和原型。
8. 一旦知道要對項目需求進行變更，要馬上與開發人員聯系。
9. 在要求需求變更時，應遵照開發組織確定的工作過程來處理。
10. 尊重需求工程中開發人員采用的流程（過程）。

需求權利和義務規定了客戶和開發者雙方應該做些什么，雙方共同出力，確保需求過程的有序進行。不過，大多數的軟件公司一般都把“客戶是上帝”這句話貫徹的很好，客戶有什么樣的要求，軟件公司就做什么樣的修改，最終損害的是客戶和自己雙方的利益。一次，我和一個小軟件企業的技術總監聊起這方面的事情，請教他的做法。他在經歷了幾次銷售人員隨意答應客戶要求的痛苦之后，決定親自出動，在和客戶接觸的過程中掌握主動權，判斷客戶是不是一個“好”客戶，再決定做不做這個軟件。實施了一段時間后，發現效果非常的好，成本大幅度下降，客戶也很滿意。軟件開發過程中軟件企業和客戶是一對合作者，一榮俱榮，一損俱損。要達到雙方共贏的局面，只能靠充分的溝通。 需求分析和需求管理

需求的過程包括了兩個過程，需求管理和需求分析。如同一個公司開展業務離不開管理一樣，脫離了需求管理的需求過程很難做到順利的完成需求過程。當然，并不是所有的軟件公司都沒有需求管理，例如安排需求的時間也是需求管理的一方面，大多數的軟件公司都沒有一個科學的、

任何活動都離不開管理，需求過程也不例外。需求過程的活動分為需求管理和需求分析兩種。大多數人說不清楚需求管理和需求分析的差別，但是他們在進行需求過程的時候已經不知不覺的在開展需求管理和需求分析兩種活動了。這種行為就有點像一些小企業主，缺乏科學的、系統的管理知識，但你卻不能說他不懂管理，因為他有大量的實踐經驗。同樣的，一些不夠成熟的軟件企業在進行需求分析的時候，主要還是靠經驗，并沒有一個經過驗證的方法。 需求分析活動包括對一個軟件項目需求的獲取、分析、規格說明及驗證。典型需求分析的結果是軟件需求規格說明（System Requirements Specifications）及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線（baseline）。這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定（agreement）。工程項目可能會有其它的約定，例如可交付性、約束條件、進度安排、預算及合同約定等。但這些并不是需求過程主要考慮的因素。

需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動，如圖所示。需求管理強調：

1、控制對需求基線的變動。
2、保持項目計劃與需求一致。
3、控制單個需求和需求文檔的版本情況。
4、管理需求和聯系鏈之間的聯系或管理單個需求和其它項目可交付品之間的依賴關系。
5、跟蹤基線中需求的狀態。

和任何的管理活動一樣，需求管理的目的也是為了確保需求分析活動按照既定方針執行。 CMM

CMM（capability Maturity Model）過程成熟度模型，這個概念是由位于賓夕法尼亞洲匹茲堡市的卡內基梅隆大學所屬的軟件工程研究所提出的。CMM是在軟件開發機構中被廣泛地用來指導過程改進工作的模型。該方法描述了軟件處理能力的五個成熟級別。處于一級的組織典型地以非正式的方式管理項目進度，要獲得成功，主要依靠天才從業者和管理者的英雄史詩般的奮斗。處于更高成熟度級別的組織把具有創造性、訓練有素的員工同軟件工程和項目管理過程結合起來，將持續不斷地獲得成功。 過程能力成熟度模型對需求管理是一個有用的指導。為達到軟件過程能力成熟度模型的第二級，組織必須具有在軟件開發與管理的六個關鍵過程域（key process areas，KPA）以展示達到目標的能力。需求管理是其中之一，它的目標如下：

1) 把軟件需求建立一個基線供軟件工程和管理使用。
2) 軟件計劃，產品和活動同軟件需求保持一致。

需求管理的關鍵過程領域不涉及收集和分析項目需求。而是假定已收集了軟件需求或已由更高一級的系統給定了需求。一旦需求到手且文檔化了，軟件開發團隊和有關的團隊（例如質量保證和測試）需要評審文檔。發現問題應與客戶或其它需求源協商解決，軟件開發計劃是基于已確認的需求。 開發團隊在向客戶、市場部或經理們作出承諾（commitment）之前，應該確認需求和確認約束條件、風險、偶然因素、假定條件。也許不得不面對由于技術因素或進度原因而不現實的需求作出承諾。但是，決不要承諾任何無法實現的事。