不要脫離實際環境
誠然，功能性是非常重要的。畢竟，如果您不能展示您構建的系統實現了您想要的功能，那麼誰會有興趣呢？採取一種新穎、巧妙、更簡單、更漂亮或更得體的方法來解決某種問題固然很好，但是如果您沒有考慮非功能性需求，則您的解決方案可能無法取得實效。
我們都碰到過這樣的情況，許多解決方案雖然合理，但是當真正考慮將它們用於大型系統的實際環境，而管理這些系統的人員又非常忙時，它們就變得很荒謬可笑了。造成這些災難的原因是不重視或忽略了系統的非功能性需求。
非功能性需求是這樣一種需求，它不一定解決「我想要我的系統實現這種功能」，而是解決「如何使這個系統能在實際環境中執行」。對於這些實際環境，您很少聽到人們提及的一些問題是：
可靠性只顯示系統可以做某些事情是不夠的。如果乙個系統不能可靠地執行（例如，在載入時，或者在系統故障時，等等），則它就不能滿足客戶的需要。
有一些問題應該自問一下：
即使硬體出現故障，系統也可以可靠執行嗎？
複製和故障轉移方案是什麼？
需要手動干預，還是系統可以自動進行故障轉移？
實現可靠性會對效能造成負面影響嗎？
實現可靠性的成本有多高？
可靠性需要考慮的一些具體方面是：
安全性：假設攻擊者就在外面。如何知道系統使用者就是他們所聲稱的，並只讓他們訪問經過授權的功能？如何保護我的系統不受攻擊？考慮到網路攻擊、機器攻擊，甚至從您自己的系統內部發起的攻擊。
事務性：如何設計系統來儲存工作單元的 acid 屬性？如果在設計中涉及多個獨立的子系統（web 服務和 soa 就是這種情況），則這一點就顯得特別重要。不要假設始終可以進行兩階段提交 (two phase commit)。
可用性如果使用者不能夠從他們可用的渠道（例如 web）方便地訪問您的產品，那麼它的好處何在呢？這有時是作為功能性的一部分一起考慮（或者應該在理想的環境下）的，但是常常被忽視，以致於整個專案處於危險之中。這裡需要考慮的一些問題是：
您是否為使用者帶來不適當的負擔（例如，需要特殊的瀏覽器版本）？
系統是否根據模型-檢視-控制器 (model-view-controller) 體系結構設計以使多使用者介面成為可能？如果是這樣，如何將它們繫結在一起？
是否介面本來就有狀態而功能無狀態（反之亦然）？
有效性如果沒有有效地使用資源（例如處理器、記憶體和磁碟空間），功能性、可靠性和可用性再好的系統最後都會失敗。我們經常發現將有效性劃分成兩個子範圍是很有用的，這兩個子範圍都應該加以考慮：
效能：這個系統的運**況有多好？它只是平穩緩慢地執行嗎？系統可以達到其響應時間目標嗎？應用程式的設計是否符合效能要求？您利用快取了嗎？
可伸縮性：如果系統在小範圍內執行看起來相當快，那麼當擴充套件至每秒、每分鐘或者每小時幾千或成千上萬個活動的時候呢？它的設計是否達到吞吐量目標？可以複製系統來實現線性擴充套件嗎？是否存在瓶頸（例如公共資料庫）？
可維護性
這是乙個極其重要的需求，因為如果開發人員、管理員和操作人員不能夠解決如何管理應用程式的問題，則它在首次發布之前就會夭折。假設您是一位管理員，您承擔了解決此問題的任務，那麼您如何配置它？如何監視它？如果您一件事情需要執行很多次（例如，安裝許多應用程式），那麼會怎麼做呢？您是否有乙個可複製的部署流程呢？您是否可以使重複的任務自動化，使之在大範圍內可行呢？
可移植性
雖然列在最後，但它並非最不重要。例如，如何採用標準來提供某種形式的平台中立性呢？是否計畫將應用程式遷移到您的最新和最高版本的應用伺服器上呢？如果不打算這樣做，則當**商撤消對該版本的支援時您要怎麼做呢？如果您的專案基於開放源**，則也有類似的問題。如果每當某人有個更好的捕鼠器 (mousetrap) 您就必須重寫整個應用程式，則沒有人會問津。
在完美的世界中，我們希望每篇文章、**、紅皮書、幻燈片和系統設計都率先解決這些重要問題。它們非常重要。差不多始終都要進行一些折衷，它們應該顯式進行以便確定特定的設計是否符合您的需要。如果您閱讀的文章沒有解決這些問題，將這作為我們的警告——一些重要的東西往往會被忽視。如果您是一位作者，請考慮我們的懇求：不要忽視這些問題！
軟體客戶需求權利書 軟體客戶需求義務書
我們在進行軟體專案需求分析時，經常遇到客戶不夠配合的情況。如果我們能跟客戶籤乙個 軟體客戶需求權利書 軟體客戶需求義務書 的話，或許事情就好辦的多了哦！軟體客戶需求權利書 客戶有如下權利 1.要求分析人員使用符合客戶語言習慣的表達。2.要求分析人員了解客戶系統的業務及目標。3.要求分析人員組織需求獲...
軟體需求分析規格說明書格式
1.引言 1.1 編寫的目的 說明編寫本說明書的目的 1.2 背景說明 給出待開發系統的全名及專案提出者，開發者，及使用者。同時說明該軟體系統將做什麼和不做什麼。1.3 術語定義 1.4 參考資料 2.任務概述 2.1 功能概述 簡要敘述本系統預計實現的主要功能及功能之間的相互關係，最好用圖表明。2...
軟體需求分析規格說明書格式
1.引言 1.1 編寫的目的 說明編寫本說明書的目的 1.2 背景說明 給出待開發系統的全名及專案提出者，開發者，及使用者。同時說明該軟體系統將做什麼和不做什麼。1.3 術語定義 1.4 參考資料 2.任務概述 2.1 功能概述 簡要敘述本系統預計實現的主要功能及功能之間的相互關係，最好用圖表明。2...