例如稅務業務系統的非功能性需求，可以從以下幾個方面進行分析。
壹：性能方面：
1。響應時間：分日常交互類、日常查詢類、批量交易分別考慮。
日常交易指傳統的大廳交互業務，如納稅申報、發票銷售等，以及壹次完成多筆業務處理的交易，如批量扣款等，日常交互類業務具有較高的響應要求。 查詢類業務如登記資料查詢、申報數據查詢等。查詢業務由於受到查詢的復雜程度、查詢的數據量大小等因素的影響，需要根據具體情況而定，給出壹個參考範圍。
批處理業務如會計核算等業務處理，該類業務處理復雜、操作數據量大、處理時間長。
響應時間指標包括：平均響應時間參考值(秒)、峰值響應時間參考值（秒）。
2。用戶數：用戶數要考慮用戶數的增長情況，有以下指標：總用戶數、峰值在線用戶數、峰值並發用戶數、平均在線用戶數、平均並發用戶數。
3。吞吐量：系統交易量的估算。指標有年交易筆數（筆/年）、高峰期交易筆數（筆/天）。
4。數據存儲量：每年的數據存儲容量（G）及未來幾年該數量的預期（增長）值。指標包括累計存儲容量（G）、年增長（G）。
二、系統可靠性：壹般是窗口業務應在從星期壹到星期五的所有工作日的工作時間是可以使用的；其它業務應滿足7×24小時可以使用；
三、可擴展性：可實現負載均衡；日後若信息量較大，則系統可相應增加服務器實現擴展。
所謂非功能性需求，是指軟件產品為滿足用戶業務需求而必須具有且除功能需求以外的特性。軟件產品的非功能性需求包括系統的性能、可靠性、可維護性、可擴充性和對技術和對業務的適應性等。下面對其中的某些指標加以說明。在這裏可以看到非功能性需求涉及的範圍很廣，軟件產品本身不是孤立存在的，還涉及到諸多外在環境的影響。非功能性需求必須考慮軟件既要可用，又要易用。
對於非功能性需求描述的困難在於很難像功能性需求那樣，可以通過結構化和量化的詞語來描述清楚，在描述這類需求時候我們經常采用軟件性能要好，查詢要在多少時間內出結果，軟件健壯性要好等較模糊的描述詞語。這類描述詞語都是脫離了軟件的執行環境，人和相關的場景的描述，因此信息很難體現到軟件架構設計和具體的實現中。我們在架構設計中關註的安全，系統開發框架，並發和性能，異常日誌等不是憑空產生出來的，而是來源於我們對非功能性需求的分析。
壹個軟件系統必須完整，因此不僅僅包括了可執行的程序，還包括了在線幫助，數據和用戶管理，日誌異常查詢，自動升級等相關功能特征。這些需求不僅僅是為了滿足用戶的需要，也是為了我們後續維護和監控系統的需要。
系統的可靠性，可維護性和適應性是密不可分的。當系統出現故障和用戶出現錯誤的操作後是否支持恢復，當用戶在使用過程中遇到錯誤的時候是否可以立即定位問題，但業務場景和邏輯發生變化的時候系統是否支持，當網絡不穩定或使用中異常中斷的情況下系統是否都有相應的容錯措施，這些都是需要在非功能性需求中考慮到的問題。
易用性也是我們在開發非功能性需求中必須要考慮到的問題，易用性同時還涉及到美工和UI界面，人機工程，交互式設計，心理學，用戶行為模式等多方面的知識。易用性的三原則就是易見，易學和易用或者叫為發現，易懂，效率。易見就是各種功能操作不要藏得太深，用戶很容易找到他們期望進行的各種操作；易學需要軟件系統通過在線幫助，導航，向導等各種方式保證軟件是可自學習的；易用的重點則在軟件在熟練使用後應該可以更快的進行各項操作。這三者相互間也存在沖突，需要平衡，而平衡的壹個重點就是真正的做到以用戶為中心進行設計，需要去細分場景和用戶。
對於非功能性需求的描述，在描述過程中必須要強調到人，業務場景，環境等各方面的內容。強調的目的就是要說明非功能性需求不是無限度的，任何壹項非功能性需求的實現往往會付出更大的研發人力成本和硬件網絡成本。比如我們在描述壹個表單的模糊查詢功能的時候，如果簡單的描述為所有查詢都要在多少秒內完成，那麽這種需求將很難得到滿足，以下是壹些可選的描述方式。
1.估計用戶數為1萬人，每天登錄用戶數為3000左右，網絡的帶寬為100M帶寬。
2.在非高峰時間根據編號和名稱特定條件進行搜索，可以在3秒內得到搜索結果。
3.當通過互聯網接入系統的時候，期望在編號和名稱搜索時最長查詢時間<15秒。