一旦你开始问那些有关非功能需求的棘手问题，或你已经走运到能收到一些信息，就可能需要提炼它们。
有为数不多的几次，我接到功能需求规格书中确实包含一些非功能需求的信息，但通常都含糊无用。举个例子，我曾从潜在客户那里收到过一份125页的文档，详述了对软件系统的需求。其中功能需求的细节占据了文档的绝大部分，只有最后半页是留给非功能需求的。里面说道：
- 性能 ：系统必须要快；
- 安全性 ：系统必须安全； + 可用性 ：系统的运行时间应该达到100%。
虽然不是很有用，但至少能展开一些讨论了。你可以根据交流对象变换问题，而不是问需要多少可用性，然后得到一个不可避免的“24/7”的答案。比如下面这些。
- “你能忍受的系统停机时间是多少？”
- “如果系统核心在朝九晚六的正常工作时间内出现故障，会发生什么？”
- “如果系统核心在正常工作时间以外出现故障，会发生什么？”
你现在要做的是探索需求，搞清楚驱动力是什么。为什么系统要可见？当我们谈论“高安全性”，要保护的是什么？我们的目标是获得一组特定的，理论上可以明确量化的非功能需求。比如下面这些。
- 系统平均应该支持多少并发用户？高峰时段呢？
- 多长的响应时间是可以接受的？系统各个部分都是如此，还是只是针对特定的功能？
- 为了保护系统安全，我们究竟该怎么做？我们真的需要对数据加密吗，受限访问足够了吗？
如果你能联想到一定数量的非功能性需求（如用户数、数据量、最大响应时间等），就能写一些验收标准并客观地进行测试。