來源：https://blog.csdn.net/jjm1437/article/details/53911262
非功能性需求是除開功能性需求外需要滿足的系統要求，可以理解爲系統的質量要求，一般包括性能、安全性、可靠性、可用性、可維護性、完整性、可測試性、有效性等。細分下來有很多，不過前輩們和一些權威機構幫我們做了很好的歸類。
常見的軟件質量模型有：
● Jim McCall 軟件質量模型（1977 年）
● Barry W. Boehm 軟件質量模型（1978 年）
● FURPS/FURPS+ 軟件質量模型
● R. Geoff Dromey 軟件質量模型
● ISO/IEC 9126 軟件質量模型（1993 年）
● ISO/IEC 25010 軟件質量模型（2011 年）
我個人認爲IBM的RUP裏的“FURPS+”是比較好的方法，可以作爲檢查表來用，避免需求遺漏；而ISO的軟件質量模型當然是最權威的了。下面簡單說明一下這兩個方法。
1.“FURPS+”模型
● 功能性（Functional）：特性、功能、安全性；
● 可用性（Usability）：人性化因素、幫助、文檔；
● 可靠性（Reliability）：故障頻率、可恢復性、可預測性；
● 性能（Performance）：響應時間、吞吐量、準確性、有效性、資源利用率；
● 可支持性（Supportability）：適應性、可維護性、國際化、可配置性。
● “+”是指一些輔助性的和次要的因素，比如：
○ 實現（Implementation）：資源限制、語言和工具、硬件等；
○ 接口（Interface）；強加於外部系統接口之上的約束；
○ 操作（Operation）：對其操作設置的系統管理；
○ 包裝（Packaging）例如物理的包裝盒；
○ 授權（Legal）：許可證或其他方式。
2. ISO/IEC 25010 軟件質量模型
在工作中，一般不會全部都考慮到，但一些常用的維度還是要有，如性能、可靠性、可維護性、安全性、可用性等，其中最爲重要的無疑是“性能”這一點，效率上無法保障其他的都面談，因此在功能設計上要時刻考慮對性能帶來的影響。
但是對於需求分析師來說，調研非功能性需求比調研功能性需求難很多。其中一個原因是非功能性需求沒有放之四海而皆準的通用標準。我們經常在寫需規的時候都會複製粘貼一些常見的指標，如：
● 登陸時間≤5秒
● 頁面間跳轉時間≤3秒
● 精確查詢（包括請求服務）響應時間≤1秒
● 模糊查詢響應時間≤5秒
● 支持靜態用戶（註冊用戶）在50000以上
● 支持動態用戶（在線用戶）在1500以上
● 支持併發數300以上
但實際上非功能性需求很難做到具體的量化，例如同樣是模糊查詢，對固定需求分析師如何做好非功能性需求求也有所不同。
另一個非功能性需求不好調研的原因是它更接近架構設計的範疇，是架構師考慮的事，剛好這些是需求分析師不擅長的，正因爲這個不擅長也導致需求分析師經常選擇性的忽略這部分內容。
那麼應該如何調研非功能性需求呢？我認爲可以從以下幾方面出發考慮。
第一，時刻關注非功能性需求
在調研業務需求時，要時刻留意功能實現對非功能性指標所帶來的影響，並在調研過程中有意識地瞭解系統運行的相關情況，例如客戶提供的硬件設備，用戶量，業務量，業務辦理頻率、峯值等問題。
第二，讓架構師提前參與
對於一些客戶明確提出的關鍵指標或可預見的問題，如大數據應用的性能問題，或者像可靠性、可用性等問題，需要讓架構師提前考慮，在技術上給出解決方案。
第三，多總結
在工作中及時總結，記錄問題和解決方案，並進行歸類整理，在下一個同類的系統或項目時，做到提前考慮。