首先，性能需求模式。被分为响应时间、吞吐量、动态容量、静态容量、可用性五种需求模式。
|
模式名称-> |
响应时间 |
吞吐量 |
动态容量 |
静态容量 |
可用性 |
|
相关模式（与之有联系的模式） |
|
可伸缩性、响应时间、系统间接口 |
|
数据寿命、数据归档、可伸缩性 |
|
|
预期频率（预期使用频率） |
0到3个需求之间，很少更少 |
简单情况下一个 |
可以达到两个 |
0到2个需求 |
通常不超过一个需求 |
|
适用性 |
定义系统需要多长时间对一个请求作出反应 |
定义一个速率，系统或者一个特定的系统间接口，必须能够以这种速率处理某些类型的输入或者输出 |
定义系统必须能够同时处理的某种实体数量。 |
定义系统能够永久保存某种类型实体的数量 |
定义什么时候系统对用户是可用的：系统的“正常开放时间”以及对于系统可用的以来程度 |
|
内容（模式包含哪些名次，还有基本概念） |
操作类型、例外情况、定时边界、可容忍的时间长度、时间长度的理由、预计硬件配置、高负载警告、动机 |
吞吐量对象标准、吞吐量指标以及时长单位、关于偶然性描述、系统的部分、理由、指标达到时限、预计硬件描述 |
实体类型、实体数量、实体条件、峰值持续时间、峰值时的让步、达到时限 |
实体类型、实体数量、实体归入标准、达到时限 |
正常可用性范围、可用的含义、可容忍的宕（dang ）机 |
|
开发考虑 |
考虑开发人员将如何处理响应时间需求 如果没有定义有助于获得快速的响应时间的需求，考虑有什么办法可以获得 |
设计提高处理大容量交易的效率，即使没有监控吞吐量的需求，至少要提供基本的方式显示当前的吞吐量 |
考虑如何处理“过时”用户会话 |
对于所有受静态容量需求影响的系统功能，检查是否是实用的，并且系统的响应时间是可以接受的 |
整个系统在开发的过程中，记录所有可能影响系统可用性的问题，并解释如何处理他们以及发生时如何恢复 |
|
测试考虑 |
考虑是否有合适的硬件配置可以用来测试响应时间需求 |
大部分情况下，试图手工生成大量对系统的请求是不可能的。只能用自动化的方法。 |
动态容量指标可能非常高，手工模拟非常难。 | 必须有办法产生足够多数量的数据 | 典型的可用性需求（“24*7可用，或者99.9%可用”这种类型）很难测试，甚至根本不值得一试，这也是反对这种需求的根源 |