性能需求文档
在确定和量化性能需求时，确定某一特殊要求背后的推理是很重要的。 这是规划过程总能力的一部分。 用户可能会将其需求声明基于与程序员的假设不匹配的程序逻辑的假设。
性能需求集至少应记录下面几点：
- 各种特定类型的用户 - 计算机交互作用在大部分时间会经历的最佳响应时间，以及对大部分时间的定义。 响应时间从用户执行“运行”这个操作的时间直到用户从计算机接收到足够反馈以继续执行任务来衡量。 这是用户的主观等待时间。 它不是从一个子例程的入口到第一个写语句的时间。
如果用户对响应时间不感兴趣，而仅仅对结果感兴趣，您可以询问“当前独立执行时间估计值的十倍”是否可以接受。 如果回答“是”，您就可以继续讨论吞吐量。 否则，您可以在用户十分注意的情况下继续讨论响应时间。
- 最低程度可接受剩余时间的响应时间。 较长的响应时间会使用户认为系统当机。 您还需要指定剩余时间，例如，一天的高峰时刻，百分之一的交互作用。 在一天的某特定时间减少响应时间很难办到，或者代价更高。
- 需要的典型吞吐量和将发生的次数。 这并不是临时注意事项。 例如，一个程序的需求可能是它每天运行两次: 在 10:00 a.m。 和 3:15 p.m。 如果这是一个运行 15 分钟且计划在多用户系统上运行的受 CPU 限制的程序，那么需要进行一些协商。
- 最大吞吐量周期的大小和计时。
- 综合预期请求及其如何随时间变化。
- 多用户应用程序中每台机器的用户数及总用户数。 此描述应包括这些用户登录和注销的次数，以及假设的击键速率、完成的请求和思考次数。 您可能想弄清楚思考次数是否随前后请求而系统地变化。
- 用户所做的关于工作负载要在其上运行的机器的任何假设。 如果用户头脑中存在一台具体的机器，那么确保您早就了解它。 同样，如果用户所采用的是特殊类型、大小、成本、位置、互联或任何其他变量，而这些变量将限制您满足前述需求的能力，那么假设也变为需求的一部分。 满意程度可能不会在程序开发、测试或首次安装的系统上进行评估。