客戶想要的是橙子，而你卻給了橘子

甲方：

“我需要一種水果，皮是黃色的，葉子是綠色的，果肉是甜的，產地是江西的，質量是優等。。。”

乙方：

根據甲方的需求描述，乙方認為甲方要的肯定是橘子，於是把橘子送到了甲方那裡！

甲方：

我要的不是橘子，於是甲方取消了和乙方合作。

乙方：

投入了大量人力物力，但沒有獲得專案，非常傷心！

導語：

如果沒有準確理解客戶的軟體需求，提供了與客戶預期不一致的軟體，那麼專案必定是失敗的。本期，我們來談談軟體需求的重要性，以及軟體需求對軟體功能規模度量的影響。

需求分析是專案開局起步的第一項工作，尤其關鍵。

上述工作也只有需求分析是甲乙雙方共同完成的，也意味著甲方在專案開發過程基本上只參與了需求分析。因此，需求分析的好壞直接決定了後續的設計、編碼等工作，進而決定了開發的專案是否滿足甲方需求。

在大型專案中，需求分析的

重要程度一般超過了設計或編碼工作

，如果需求獲取方式不對、需求內容不準確、需求反覆變化等原因，造成軟體設計、編碼工作反覆調整，少則影響專案進度，重則造成專案下馬，造成甲乙雙方的巨大損失。

IEEE軟體工程標準定義

使用者解決問題或達到目標所需條件或權能（Capability）。

系統或系統部件要滿足合同、標準、規範或其它正式規定文件所需具有的條件或權能。

一種反映上面1或2所述條件或權能的文件說明。它包括

功能性需求及非功能性需求

，非功能性需求對設計和實現提出了限制，比如效能要求，質量標準，或者設計限制。

總結

：簡單來說，就是軟體開發的條件，包括功能需求和非功能需求兩類。

例如

：一種水果，皮是黃色的，葉子是綠色的，果肉是甜的，這些條件就是

功能需求

；產地是江西的，質量是優等。。。，這些條件就是

非功能需求

。

功能需求：

一般把功能需求可以按3個不同的層次區分，可以分為

業務需求

、

使用者需求

和

功能需求

三類。

業務需求（Business requirement）

表示組織或客戶高層次的目標。業務需求通常來自專案投資人、購買產品的客戶、實際使用者的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。

使用者需求（user requirement）

描述的是使用者的目標，或使用者要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達使用者需求的有效途徑。也就是說使用者需求描述了使用者能使用系統來做些什麼。

功能需求（functional requirement）

規定開發人員必須在產品中實現的軟體功能，使用者利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavīoral requirement），因為習慣上總是用“能夠”對其進行描述：“系統能夠傳送電子郵件來通知使用者已接受其預定”。功能需求描述是開發人員需要實現什麼。

非功能需求

非功能性需求一般會稱為系統的“

品質

”，有時也會稱為“

限制

”、“

品質屬性

”、“

品質目標

”、“

品質屬性

”、“

品質服務需求

”或“

非行為性的需求

”。

非功能性需求可以分為以下的二類：

執行品質（Execution qualities）

：可以在系統運作時觀察到的品質，例如安全性及易用性等。

發展品質（Evolution qualities）

：和軟體系統結構及開發過程有關的品質，例如軟體可測試性（英語：software testability）、可維護性、可擴充套件性、可伸縮性（scalability）等。

非功能性需求一般是隱性的，容易被需求分析人員或軟體工程師忽略。非功能性需求的分類方法較多，名稱/叫法以及分類方法上可能略有差異，但是其含義和指向一般趨向一致的，一般較多采用的分類如下：

1.效能/容量

效能和容量比較容易理解，包括像需要支援的

使用者數量

（尤其是峰值的併發使用者數量），使用者能夠接受的

響應時間

，

資料規模

（例如百萬級的驚人資料規模，上億的檔案儲存啦等等）

2.可靠性/可用性/可復原性

在規定的一段時間和條件下，軟體維持其功能服務以及效能水平的能力有關的一組屬性

（可用性是另外一種說法）。例如，我們要求系統7x24小時執行，全年持續執行故障停運時間累計不能超過10小時等等，都屬於這方面的要求。 可復原性與在是發生錯誤和故障後重建其效能水平並恢復直接受影響資料的能力。例如，支付寶需要保證如果在交易提交失敗以後，需要保證回滾，不能這頭銀行的錢沒有付成功，那頭卻顯示付款成功或者反之這頭銀行扣款了，那頭在改變交易狀態的時候缺因為冗塞或者其他原因導致交易還是未付款狀態。

3.可維護性/可管理性

系統在無人工干預條件下的穩定性，自排錯能力，可測試性都屬於這個範疇。

故障的可排查能力，系統的修正，升級，備份，恢復機制以及方便與否，都屬於這個範疇。這通常會極大決定系統的執行維護成本及維護難度。

4.安全性

包括傳輸加密、儲存加密、可破解性以及各種未被授權的使用者行為如何防範和控制

，都是安全範疇，這裡的安全不單針對外部普通使用者，也針對內部不同級別的許可權使用者的的控制。小到如何防範和處理使用者在輸入框裡輸入特殊字元來獲得設計者未曾預料的結果，大到防範外部駭客和內部內鬼。安全很多時候不單依賴技術實現，同時非常依賴相應的制度和審計。

5.易用性

易用性是非功能性需求中現在唯一被高亮出來，受到廣泛關注

。易用性設計現在已經上升到了一個新的高度，叫作人機體驗，UE設計，雖然現在UE到底是劃分在功能性需求還是非功能性需求上，尚有一些爭議，但是主流觀點都認為，這是非功能性需求的一個典型部分。

6.資料一致性

包括資料的編碼和語言，冗餘資料的一致性要求（含時間要求）等等

。例如，為了效能的考慮，資料庫整體設計未採用巴斯克正規化，而採用了第二或者第三正規化的要求來設計，一些資訊（例如使用者註冊資訊），可能同時存在於系統的多個地方（例如多個表中），當發生註冊資訊變更時，如何保證多處地方記錄的資訊都被修改，以及這個全部修改的時限要求是多少等等都是這個範疇的內容。

7.系統/環境 條件及限制

現有的軟硬體條件，平臺的條件，網路的條件都屬於這個範疇

。典型的例如很多移動網際網路產品，必須要考慮行動網路的頻寬條件，終端運算效能和能力，以及其行動網路穩定性等等。

總結：很多軟體專案及產品，其在非功能性需求上的成本，難度和工作量，是要超過功能性需求的

。在特定的軟體領域，例如，網站（尤其是淘寶，facebook這樣海量使用者規模的網站），金融（銀行證券），電信領域，其非功能性需求實現的重要性，工作量，技術難度要遠遠大於功能性需求的實現。

功能性的需求的實現，其實在大多數情況下，更依賴於業務的高手（或者好的產品經理）而不是技術的高手，而非功能性需求的實現，恰恰是挑戰技術高手的重要課題。

不屬於需求的內容

專案中通常還包括其他型別的需求，如

開發環境需求，進度或預算限制，幫助新使用者跟上進度的培訓需求，或者釋出產品使其轉入支援環境的需求

。這些都屬於專案需求而不是產品需求，因此不屬於軟體需求的討論範圍。

軟體需求與功能規模度量的關係：

功能需求直接決定了軟體原始功能點的規模，非功能需求直接決定了部分調整因子的取值，

所以說，準確的功能需求和非功能需求，是確定原始功能點數和調整因子的前提，

是合理準確度量軟體功能規模和軟體工作量的必要支撐

。