一旦你開始問那些有關非功能需求的棘手問題，或你已經走運到能收到一些信息，就可能需要提煉它們。
有為數不多的幾次，我接到功能需求規格書中確實包含一些非功能需求的信息，但通常都含糊無用。舉個例子，我曾從潛在客戶那裡收到過一份125頁的文檔，詳述了對軟件系統的需求。其中功能需求的細節佔據了文檔的絕大部分，只有最後半頁是留給非功能需求的。裡面說道：
- 性能 ：系統必須要快；
- 安全性 ：系統必須安全； + 可用性 ：系統的運行時間應該達到100%。
雖然不是很有用，但至少能展開一些討論了。你可以根據交流對像變換問題，而不是問需要多少可用性，然後得到一個不可避免的「24/7」的答案。比如下面這些。
- 「你能忍受的系統停機時間是多少？」
- 「如果系統核心在朝九晚六的正常工作時間內出現故障，會發生什麼？」
- 「如果系統核心在正常工作時間以外出現故障，會發生什麼？」
你現在要做的是探索需求，搞清楚驅動力是什麼。為什麼系統要可見？當我們談論「高安全性」，要保護的是什麼？我們的目標是獲得一組特定的，理論上可以明確量化的非功能需求。比如下面這些。
- 系統平均應該支持多少並發用戶？高峰時段呢？
- 多長的響應時間是可以接受的？系統各個部分都是如此，還是只是針對特定的功能？
- 為了保護系統安全，我們究竟該怎麼做？我們真的需要對數據加密嗎，受限訪問足夠了嗎？
如果你能聯想到一定數量的非功能性需求（如用戶數、數據量、最大響應時間等），就能寫一些驗收標準並客觀地進行測試。