本文轉載自CSDN博主「麥哲思科技任甲林」
原文鏈接：https://blog.csdn.net/dylanren/article/details/79215402
非功能性需求是需求的一個重要組成部分，它影響了系統的架構設計，需要開發人員重點關注。但是在工程實踐中，往往客戶不會提出非功能性需求，需求人員在描述需求時不知道如何描述，在國際的各種標準中，對非功能性需求有定義，但是比較抽象。因此我整理如下常見的非功能性需求的描述案例，供需求人員進行參考。
1、性能需求描述案例：
響應時間：
在95％的情況下，一般時段響應時間不超過1.5秒，高峯時段不超過4秒。
定位系統從點擊到第一個界面顯示出來所需要的時間不得超過300毫秒。
在網絡暢通時，撥號連接GPRS網絡所需時間不得超過5秒。
在網絡暢通時，電子地圖刷新時間不超過10秒。
在推薦配置環境下：登錄響應時間在2秒內，刷新欄目響應時間在2秒內，刷新條目分頁列表響應時間2秒內，打開信息條目響應時間1秒內，刷新部門、人員列表響應時間2秒內。
在非高峯時間根據編號和名稱特定條件進行搜索，可以在3秒內得到搜索結果。
業務量：
每日最大成交數3000筆業務。
平均交易併發數爲20，最大交易併發數爲50。
估計用戶數爲1萬人，每天登錄用戶數爲3000左右，網絡的帶寬爲100M帶寬。
系統可以同時滿足10,000個用戶請求，併爲25,000個併發用戶提供瀏覽功能。
系統容量：
支持3萬用戶，支持GB級數據。
數據庫錶行數不超過100萬行，數據庫最大容量不超過1000GB，磁盤空間至少需要40G以上。
精度：
定位精度誤差不超過80米。
當通過互聯網接入系統的時候，期望在編號和名稱搜索時最長查詢時間<15秒。
計算的精確性到小數點後7位。
資源使用率：
CPU佔用率<=50%。
內存佔用率<=50%。
2、安全需求描述案例：
嚴格權限訪問控制，用戶在經過身份認證後，只能訪問其權限範圍內的數據，只能進行其權限範圍內的操作。
不同的用戶具有不同的身份和權限，需要在用戶身份真實可信的前提下，提供可信的授權管理服務，保護數據不被非法/越權訪問和篡改，要確保數據的機密性和完整性。
提供運行日誌管理及安全審計功能，可追蹤系統的歷史使用情況。
能經受來自互聯網的一般性惡意攻擊。如病毒（包括木馬）攻擊、口令猜測攻擊、黑客入侵等。
至少99%的攻擊需要在10秒內檢測到。
3、可靠性需求描述案例：
對輸入有提示，數據有檢查，防止數據異常。
系統健壯性強，應該能處理系統運行過程中出現的各種異常情況，如：人爲操作錯誤、輸入非法數據、硬件設備失敗等，系統應該能正確的處理，恰當的迴避。
因軟件系統的失效而造成不能完成業務的概率要小於5‰。
要求系統7x24小時運行，全年持續運行故障停運時間累計不能超過10小時。
系統缺陷率每1,000小時最多發生1次故障。
在1,000,000次交易中，最多出現1次需要重新啓動系統的情況。
4、兼容性需求描述案例：
系統應支持IOS，Android , windows操作系統;
系統應支持Oracle, DB2 數據庫系統;
最多隻有5%的系統實現需要具體到特定的操作系統。
替換關係數據庫系統的平均時間不超過2小時，並且保證沒有數據丟失。
5、數據保密需求描述案例：
網絡傳遞數據應經過加密。需要保證數據在採集、傳輸和處理過程中不被偷窺、竊取、篡改。業務數據需要在存儲時進行加密，確保不可破解。
6、環境需求描述案例：
7、易用性需求描述案例：
在引入該產品的3個月內，60％的用戶應該可以在45秒內用它來完成轉賬的任務，失敗率控制在萬分之一以內。
60％的用戶在第一次看見該產品的5秒內，就會意識到這是**銀行的網銀。
80%的用戶在接受一個2小時的系統介紹培訓後，可以在5分鐘之內成功預訂房間。
8、可用性需求描述案例：
有些農村地區網絡質量差，帶寬小。在網絡環境差的條件下保證系統的可用性等。
在95%的故障中，系統最多需要20秒重啓。
提供數據備份和恢復功能，使得在由於系統的錯誤或其他原因引起系統的數據丟失或系統的數據被破壞時，能夠及時恢復和還原數據（由硬件及第三方軟件提供此功能）。
9 、可測試性需求描述案例：
一個模塊的最大圈複雜度不能超過15。
交付的系統必須通過單元測試，並且是100%覆蓋。
開發活動必須使用迴歸測試，並允許在12小時內重新進行完整的測試。
10、可維護性需求描述案例：
從接到修改請求後，對於普通修改應在1~2天內完成；對於評估後爲重大需求或設計修改應在1周內完成。
90%的BUG修改時間不超過1個工作日，其他不超過2個工作日。
代碼的圈複雜度必須在10以內。
任何對象的任何方法都不允許超過200行代碼。
安裝新版本必須保持所有的數據庫內容和所有個人設置不變。
產品必須提供可跟蹤任何數據庫字段的工具。