為什么非功能性需求很重要？

　　不要脫離實際環境

　　有時，我們會因為讀到一篇文章或一本書，或者看到一個感覺不完善的介紹而變得異常偏執。在每種情況下，人們只討論一些技術、解決方案和選項的某些方面，而忽視了一個至關重要的問題:非功能性需求。

　　誠然，功能性是非常重要的。畢竟，如果您不能展示您構建的系統實現了您想要的功能，那么誰會有興趣呢?采取一種新穎、巧妙、更簡單、更漂亮或更得體的方法來解決某種問題固然很好，但是如果您沒有考慮非功能性需求，則您的解決方案可能無法取得實效。

　　我們都碰到過這樣的情況，許多解決方案雖然合理，但是當真正考慮將它們用于大型系統的實際環境，而管理這些系統的人員又非常忙時，它們就變得很荒謬可笑了。造成這些災難的原因是不重視或忽略了系統的非功能性需求。

　　非功能性需求是這樣一種需求，它不一定解決“我想要我的系統實現這種功能”，而是解決“如何使這個系統能在實際環境中運行”。對于這些實際環境，您很少聽到人們提及的一些問題是:

• 　　對在線系統的請求過多:用戶太多了，全都在一塊了!
• 　　部署應用程序的管理員負擔過大:在實際環境中，管理員對每個應用程序都將部署多次，而在部署之后必須對每一個應用程序進行監視。
• 　　管理員會犯錯誤:畢竟，我們大多數都是普通人!雖然無差錯地執行 100 次手動部署步驟在理論上是可能的，但是實際環境中沒有出現過。
• 　　會有惱人的腳本小子 (script kiddy) 和真正的破解高手攻擊我們的系統:安全是多么重要啊!

　　所以，什么是非功能性需求呢?我們可以找到許多很好的定義，不過，我們首先來看 Software Characteristics 的 ISO 9126 列表;除功能性(這是理所當然的)以外，這些特性包括:

　　可靠性

　　只顯示系統可以做某些事情是不夠的。如果一個系統不能可靠地運行(例如，在加載時，或者在系統故障時，等等)，則它就不能滿足客戶的需要。

　　有一些問題應該自問一下:

　　即使硬件出現故障，系統也可以可靠運行嗎?

• 　　復制和故障轉移方案是什么?
• 　　需要手動干預，還是系統可以自動進行故障轉移?
• 　　實現可靠性會對性能造成負面影響嗎?
• 　　實現可靠性的成本有多高?

　　可靠性需要考慮的一些具體方面是:

• 　　安全性:假設攻擊者就在外面。如何知道系統用戶就是他們所聲稱的，并只讓他們訪問經過授權的功能?如何保護我的系統不受攻擊?考慮到網絡攻擊、機器攻擊，甚至從您自己的系統內部發起的攻擊。
• 　　事務性:如何設計系統來保存工作單元的 ACID 屬性?如果在設計中涉及多個獨立的子系統(Web 服務和 SOA 就是這種情況)，則這一點就顯得特別重要。不要假設始終可以進行兩階段提交 (two phase commit)。

　　可用性

　　如果用戶不能夠從他們可用的渠道(例如 Web)方便地訪問您的產品，那么它的好處何在呢?這有時是作為功能性的一部分一起考慮(或者應該在理想的環境下)的，但是常常被忽視，以致于整個項目處于危險之中。這里需要考慮的一些問題是:

• 　　您是否為用戶帶來不適當的負擔(例如，需要特殊的瀏覽器版本)?
• 　　系統是否根據模型-視圖-控制器 (Model-View-Controller) 體系結構設計以使多用戶界面成為可能?如果是這樣，如何將它們綁定在一起?
• 　　是否界面本來就有狀態而功能無狀態(反之亦然)?

　　有效性

　　如果沒有有效地使用資源(例如處理器、內存和磁盤空間)，功能性、可靠性和可用性再好的系統最后都會失敗。我們經常發現將有效性劃分成兩個子范圍是很有用的，這兩個子范圍都應該加以考慮:

• 　　性能:這個系統的運行情況有多好?它只是平穩緩慢地運行嗎?系統可以達到其響應時間目標嗎?應用程序的設計是否符合性能要求?您利用緩存了嗎?
• 　　可伸縮性:如果系統在小范圍內運行看起來相當快，那么當擴展至每秒、每分鐘或者每小時幾千或成千上萬個活動的時候呢?它的設計是否達到吞吐量目標?可以復制系統來實現線性擴展嗎?是否存在瓶頸(例如公共數據庫)?

　　可維護性

　　這是一個極其重要的需求，因為如果開發人員、管理員和操作人員不能夠解決如何管理應用程序的問題，則它在首次發布之前就會夭折。假設您是一位管理員，您承擔了解決此問題的任務，那么您如何配置它?如何監視它?如果您一件事情需要執行很多次(例如，安裝許多應用程序)，那么會怎么做呢?您是否有一個可復制的部署流程呢?您是否可以使重復的任務自動化，使之在大范圍內可行呢?

　　可移植性

　　雖然列在最后，但它并非最不重要。例如，如何采用標準來提供某種形式的平臺中立性呢?是否計劃將應用程序遷移到您的最新和最高版本的應用服務器上呢?如果不打算這樣做，則當供應商撤消對該版本的支持時您要怎么做呢?如果您的項目基于開放源代碼，則也有類似的問題。如果每當某人有個更好的捕鼠器 (mousetrap) 您就必須重寫整個應用程序，則沒有人會問津。

　　在完美的世界中，我們希望每篇文章、論文、紅皮書、幻燈片和系統設計都率先解決這些重要問題。它們非常重要。差不多始終都要進行一些折衷，它們應該顯式進行以便確定特定的設計是否符合您的需要。如果您閱讀的文章沒有解決這些問題，將這作為我們的警告——一些重要的東西往往會被忽視。如果您是一位作者，請考慮我們的懇求:不要忽視這些問題!

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