比如稅務業務系統的非功能性需求，可以從以下幾個方面進行分析。
壹:性能:
1。響應時間:分別考慮日常交互、日常查詢和批量交易。
日常交易是指大堂傳統的交互業務，如報稅、發票銷售等。，以及壹次完成多項業務處理的交易，如批量扣款等。，且日常交互業務對響應要求高。註冊信息查詢、申報數據查詢等查詢業務。由於受查詢復雜程度和數據大小的影響，查詢業務需要根據具體情況給出壹個參考範圍。
批量處理業務，如會計等業務處理復雜，操作數據量大，處理時間長。
響應時間指標包括:平均響應時間參考值(秒)和峰值響應時間參考值(秒)。
2。用戶數:用戶數要考慮用戶數的增長，包括以下指標:總用戶數、峰值在線人數、峰值並發人數、平均在線人數、平均並發人數。
3。吞吐量:對系統事務量的估計。指標包括每年交易筆數(每年交易筆數)和高峰期每天交易筆數。
4。數據存儲容量:年數據存儲容量(g)以及未來幾年該量的預期(增長)值。指標包括累積庫容(g)和年生長量(g)。
二、系統可靠性:壹般來說，周壹至周五工作時間窗口業務應該可用；其他服務應7×24小時可用；
第三，可擴展性:可以實現負載均衡；如果將來有大量的信息，系統可以相應增加服務器來實現擴展。
所謂非功能性需求，是指軟件產品為了滿足用戶的業務需求，除功能性需求之外必須具備的特性。軟件產品的非功能需求包括系統性能、可靠性、可維護性、可擴展性以及對技術和業務的適應性。其中壹些指標解釋如下。這裏我們可以看到，非功能需求涉及的範圍很廣，軟件產品本身並不是孤立存在的，還涉及到很多外部環境的影響。非功能性需求必須考慮軟件應該是可用的、易用的。
描述非功能性需求的難點在於，很難像功能性需求那樣，用結構化、量化的詞語來清晰地描述。在描述這樣的需求時，我們經常使用模糊的描述詞，如良好的軟件性能，查詢需要多長時間才能產生結果，以及良好的軟件健壯性。這種描述文字脫離了對軟件執行環境、人員和相關場景的描述，難以在軟件架構設計和具體實現中體現信息。我們在架構設計中關註的安全性、系統開發框架、並發與性能、異常日誌等等都不是憑空產生的，而是來自於我們對非功能性需求的分析。
壹個軟件系統必須是完整的，所以它不僅包括可執行程序，還包括在線幫助、數據和用戶管理、日誌異常查詢、自動升級等相關功能特性。這些要求不僅是為了滿足用戶的需求，也是為了我們後續的維護和監控系統。
系統的可靠性、可維護性和適應性密不可分是否支持系統故障和用戶誤操作後的恢復，用戶在使用中遇到錯誤是否能立即定位問題，業務場景和邏輯發生變化時是否支持系統，使用中網絡不穩定或異常中斷時系統是否有相應的容錯措施，這些都是非功能需求需要考慮的問題。
易用性也是我們在開發非功能需求時必須考慮的問題。易用性還涉及藝術與UI界面、人體工程學、交互設計、心理學、用戶行為模式等諸多知識。可用性的三大原則是:易見、易學、易用，或者說是發現、易懂、高效。很明顯各種功能操作不要隱藏太深，用戶很容易找到自己期望的各種操作；易學需要軟件系統通過在線幫助、導航、指導等方式保證軟件的自主學習；易用性的關鍵點是軟件在熟練使用後應該能夠更快的進行各種操作。三者之間也有沖突，需要平衡，而平衡的重點之壹就是真正以用戶為中心進行設計，需要細分場景和用戶。
對於非功能需求的描述，在描述過程中必須強調人、業務場景、環境等方面。強調的目的是為了表明非功能性需求不是無限的，任何非功能性需求的實現往往會付出更多的R&D人力成本和硬件網絡成本。例如，當我們描述壹個表單的模糊查詢功能時，如果我們簡單地將其描述為完成所有查詢需要多少秒，將很難滿足這壹需求。以下是壹些可供選擇的描述。
1.預計用戶數為10000，每天登錄用戶數約為3000，網絡帶寬為100M m..
2.在非高峰時段根據號碼和姓名的具體條件進行搜索，3秒內即可得到搜索結果。
3.通過互聯網訪問系統時，預計最長查詢時間為