有時，我們會因爲讀到一篇文章或一本書，或者看到一個感覺不完善的介紹而變得異常偏執。在每種情況下，人們只討論一些技術、解決方案和選項的某些方面，而忽視了一個至關重要的問題：非功能性需求。
誠然，功能性是非常重要的。畢竟，如果您不能展示您構建的系統實現了您想要的功能，那麼誰會有興趣呢？採取一種新穎、巧妙、更簡單、更漂亮或更得體的方法來解決某種問題固然很好，但是如果您沒有考慮非功能性需求，則您的解決方案可能無法取得實效。
我們都碰到過這樣的情況，許多解決方案雖然合理，但是當真正考慮將它們用於大型系統的實際環境，而管理這些系統的人員又非常忙時，它們就變得很荒謬可笑了。造成這些災難的原因是不重視或忽略了系統的非功能性需求。
非功能性需求是這樣一種需求，它不一定解決“我想要我的系統實現這種功能”，而是解決“如何使這個系統能在實際環境中運行”。對於這些實際環境，您很少聽到人們提及的一些問題是：
-
對在線系統的請求過多：用戶太多了，全都在一塊了！
-
部署應用程序的管理員負擔過大：在實際環境中，管理員對每個應用程序都將部署多次，而在部署之後必須對每一個應用程序進行監視。
-
管理員會犯錯誤：畢竟，我們大多數都是普通人！雖然無差錯地執行 100 次手動部署步驟在理論上是可能的，但是實際環境中沒有出現過。
-
會有惱人的腳本小子 (script kiddy) 和真正的破解高手攻擊我們的系統：安全是多麼重要啊！
所以，什麼是非功能性需求呢？我們可以找到許多很好的定義，不過，我們首先來看 Software Characteristics 的 ISO 9126 列表；除功能性（這是理所當然的）以外，這些特性包括：
-
可靠性
只顯示系統可以做某些事情是不夠的。如果一個系統不能可靠地運行（例如，在加載時，或者在系統故障時，等等），則它就不能滿足客戶的需要。
有一些問題應該自問一下：
- 即使硬件出現故障，系統也可以可靠運行嗎？
- 複製和故障轉移方案是什麼？
- 需要手動干預，還是系統可以自動進行故障轉移？
- 實現可靠性會對性能造成負面影響嗎？
- 實現可靠性的成本有多高？
可靠性需要考慮的一些具體方面是：
-
安全性：假設攻擊者就在外面。如何知道系統用戶就是他們所聲稱的，並只讓他們訪問經過授權的功能？如何保護我的系統不受攻擊？考慮到網絡攻擊、機器攻擊，甚至從您自己的系統內部發起的攻擊。
-
事務性：如何設計系統來保存工作單元的 ACID 屬性？如果在設計中涉及多個獨立的子系統（Web 服務和 SOA 就是這種情況），則這一點就顯得特別重要。不要假設始終可以進行兩階段提交 (two phase commit)。
-
可用性
如果用戶不能夠從他們可用的渠道（例如 Web）方便地訪問您的產品，那麼它的好處何在呢？這有時是作爲功能性的一部分一起考慮（或者應該在理想的環境下）的，但是常常被忽視，以致於整個項目處於危險之中。這裏需要考慮的一些問題是：
- 您是否爲用戶帶來不適當的負擔（例如，需要特殊的瀏覽器版本）？
- 系統是否根據模型-視圖-控制器 (Model-View-Controller) 體系結構設計以使多用戶界面成爲可能？如果是這樣，如何將它們綁定在一起？
- 是否界面本來就有狀態而功能無狀態（反之亦然）？
-
有效性
如果沒有有效地使用資源（例如處理器、內存和磁盤空間），功能性、可靠性和可用性再好的系統最後都會失敗。我們經常發現將有效性劃分成兩個子範圍是很有用的，這兩個子範圍都應該加以考慮：
-
性能：這個系統的運行情況有多好？它只是平穩緩慢地運行嗎？系統可以達到其響應時間目標嗎？應用程序的設計是否符合性能要求？您利用緩存了嗎？
-
可伸縮性：如果系統在小範圍內運行看起來相當快，那麼當擴展至每秒、每分鐘或者每小時幾千或成千上萬個活動的時候呢？它的設計是否達到吞吐量目標？可以複製系統來實現線性擴展嗎？是否存在瓶頸（例如公共數據庫）？
-
-
可維護性
這是一個極其重要的需求，因爲如果開發人員、管理員和操作人員不能夠解決如何管理應用程序的問題，則它在首次發佈之前就會夭折。假設您是一位管理員，您承擔瞭解決此問題的任務，那麼您如何配置它？如何監視它？如果您一件事情需要執行很多次（例如，安裝許多應用程序），那麼會怎麼做呢？您是否有一個可複製的部署流程呢？您是否可以使重複的任務自動化，使之在大範圍內可行呢？
-
可移植性
雖然列在最後，但它並非最不重要。例如，如何採用標準來提供某種形式的平臺中立性呢？是否計劃將應用程序遷移到您的最新和最高版本的應用服務器上呢？如果不打算這樣做，則當供應商撤消對該版本的支持時您要怎麼做呢？如果您的項目基於開放源代碼，則也有類似的問題。如果每當某人有個更好的捕鼠器 (mousetrap) 您就必須重寫整個應用程序，則沒有人會問津。
在完美的世界中，我們希望每篇文章、論文、紅皮書、幻燈片和系統設計都率先解決這些重要問題。它們非常重要。差不多始終都要進行一些折衷，它們應該顯式進行以便確定特定的設計是否符合您的需要。如果您閱讀的文章沒有解決這些問題，將這作爲我們的警告——一些重要的東西往往會被忽視。如果您是一位作者，請考慮我們的懇求：不要忽視這些問題！
原文地址如下：
英文：http://www-128.ibm.com/developerworks/websphere/techjournal/0601_col_bobrha/0601_col_bobrha.html
中文：http://www-128.ibm.com/developerworks/cn/websphere/techjournal/0601_col_bobrha/0601_col_bobrha.html