需求可以按多种方式分类（例如，按功能和非功能分类）。使用需求模式有一个优点，如果对模式分类，自动就对使用这些模式的需求分类。分类告诉我们一些使用模式的需求的本性。
使用这些分类的其他方式是按照分类找到需求以及统计需求。人们喜欢统计（至少有一些人，通常他们是高级行政人员，我们应该让他们高兴）。对系统的需求的统计可以在很多方面有用。可以帮助大概了解系统的复杂性和规模。为了这个目标，需要对每个需求标记所需统计的数值。（需求管理工具通常定义一些额外的需求属性，然后对每个需求输入属性的数值，这是个乏味的工作。）使用需求模式可以节省这方面的工作，因为使用模式产生的所有需求有共同的属性。它们只需要在模式编写的时候定义一次。这个信息记录在每个模式的“模式分类”部分。
于如何保存需求。（这留给读者练习）一个直接的办法就是把需求拷贝到excel中，添加一列确定需求使用的需求模式，对每一个分类添加一列。（按模式名排序可以更容易一次处理多个分类数值。）
本书中的需求模式只包含了少量的基本分类方式，定义在下面。你可以定义自己额外的分类方式，并用它们对模式分类。如果是这样的话，按照下面的方式编写合适的定义，然后把它们放在引用它们的需求模式的地方。
分类可以帮助使用需求的任何人，包括开发人员。因此，不必要所有人都理解每一个分类。基于这个原因，每一个分类要有一个主要读者，并且明确的陈述。如果你不属于这部分读者，不要担心不能理解它的目的或者对它不感兴趣。
需求模式的分类需要合适和精确的定义，否则基于分类的统计就不可能可靠。每个分类需要定义以下内容：
| 名称： |
分类的唯一的，明显的名称 |
| 读者： |
关于谁可能对这个分类感兴趣的解释：目标是谁。 |
| 目的： |
描述分类使用的意图是什么。 |
| 允许值： |
定义在模式中这个分类可以有的值，解释它们的含义。最通常的方法是定义数值列表。数字的或者文字的或者任何其他数值都可以使用，只要读者了解这些数值的含义。 |
| 缺省值： |
如果在模式中的分类没有定义（明确陈述），这就是采用的数值。这样可以不必在模式中明确的定义分类，如果这个分类只对相对少量的模式有意义（换句话说，就是只对少量模式重要）。 |
本书中用到三个需求模式分类，下面使用这种格式描述。
“功能”分类
| 名称： |
功能 |
| 读者： |
对挑选系统功能感兴趣的任何人，或者对功能数量感兴趣的人。 |
| 目的： |
指出这种类型的需求是否定义了系统必须提供的功能 |
| 允许值： |
是 |
每一个这种类型的需求是功能需求。 |
| 可能是 |
有些这种类型的需求是功能需求；有些不是。编写一个模式时，小心使用这个值。确定模式是否定义清楚了；可能应该分成两个，一个是功能部分一个是非功能部分。 |
| 否 |
这种类型的需求不是功能需求 |
| 缺省值： |
否 |
“普遍性”分类
| 名称： |
普遍性 |
| 读者： |
软件开发人员 |
| 目的： |
指出这种类型的需求是否是普遍性的（也就是说，适用整个系统）。它的目的是提醒开发人员注意，不管他们正在开发系统的那一部分，这个需求都影响他们。 |
| 允许值： |
是 |
这种类型的需求是普遍性需求。 |
| 可能是 |
有些这种类型的需求是普遍性的，有些不是。 |
| 否 |
这种类型的需求不是普遍性需求 |
| 缺省值： |
否 |
“影响数据库”分类
| 名称： |
影响数据库 |
| 读者： |
数据库管理员（以及软件开发人员） |
| 目的： |
指出这种类型的需求是否会影响系统数据库的设计。它的目的提醒负责设计数据库的人员关注 |
| 这些需求 |
| 允许值： |
是 |
这种类型的需求影响数据库。 |
| 可能是 |
有些这种类型的需求影响数据库，有些不影响。 |
| 否 |
这种类型的需求不直接影响数据库。（尽管这并不意味着数据库管理员可以不关心它）。 |
| 缺省值： |
可能是 |