如果要把一个项目需求描述完整，只有Use Case Model显然不够的，前面说过Use Case只描述了功能需求。除Use Case外的部分，叫法有好几种，有的叫“非功能性需求（Non-functionality）”，IBM RUP中叫“补充说明（Supplementary Document）”，又后来微软的MSF及一些敏捷开发称为“服务质量需求（Quality of Service Requirement）”。不管这些叫法上有什么差异，但是内涵基本一致。
关于完整的需求描述，我喜欢用另一个词：需求模型。
这是因为我一直认为，需求在做分析的人的脑子里应该有个框架。任何需求获取之后，都应该立刻将其放到框架中的某位置；同时这个框架还是指导我们挖掘需求的指南，比如我去遍历一下这个框架中哪些地方还是空的。当然，跟很多模型一样，这个模型是可以根据具体情况裁剪的。
需求模型的组成通常包括：
[1] 业务说明（Business Model）
我认为这是在很多需求说明中是缺失的。Business Model描述的是目标系统存在的现实环境，是产生目标系统需求的原生地。如果脱离Business Model，需求人员可能无法保证描述出来的系统模型符合（Meet）所有需求，也无法让读者清晰理解这些需求，因为对这些抽象出来的功能模型来说失去了场景。
[2] 系统用例模型（Use Case Model）
不用多说了，这是很多人一认识Use Case就喜欢搞的东西。
[3] 补充说明（Supplementary Doc）
这部分经常被忽视但其实非常重要。我一直觉得缺乏好的搜集模式以及搜集过程缺乏趣味性是其经常被忽视的主要原因。J！不像Use Case，可以画小人图，拉来拉去，颇有指点江山的感觉。另外，需求方也很少能在早期就能系统的考虑到各方面的非功能性需求。
非功能性需求往往是零零星星的被提出来的。这个时候，我前面提到的“关于需求的框架”就很重要了。每当需求方或分析人员提出非功能性方面的需求或问题时，立刻将之归为某类，先不管是否合适，抓住了再说，可以以后再分析分类。这样在搜集整理需求过程中逐步的完成非功能性需求的搜集。
[4] 数据需求（Data Requirement）
说明需求中业务内容的数据结构，包括业务名称，业务实体（步骤）名称，字段名，数据类型，长度，规则等。
很多人一看就说，这不是数据库设计吗？这绝对不是数据库设计，数据库设计也绝对不是这样。首先，数据需求描述的是业务中的数据内容，也就是说每个字段在现实业务环境中都是有意义的，而数据库设计是经过抽象和精心设计的，比如，数据库设计中会有什么索引、联合关键字、自增长列、××标志位等，还会有一些现实中不存在的一些字段。数据需求是采自山野的石头，淳朴、自然，毫无修饰；而数据库设计则是出自巧工能匠的工艺品了。
数据需求是进行界面原型制作、领域建模以及数据库设计的重要输入。
[5] 界面原型（UI Prototype）
在很多MIS系统中，界面原型的沟通效果超乎想象。不得不承认这是一个非常有效的描述需求的方式，最强的优势就是直观。以致于很多人甚至舍弃或忽略Use Case说明，当然这是不合适的。因为UI Prototype描述的只是“交互”、“流程”，而无法确切说明系统“功能”，如：“用户注册成功后，系统发送一封电子邮件给系统管理员进行审核”就无法在界面原型中表现。
不过如能将其与Use Case相互补充则可谓珠联璧合。
[6] 术语表
严格来说，“术语表”不能算是“需求”说明，不过其往往主要在需求整理过程中启动并丰富起来，对于需求说明是个非常重要的补充。我放在这里还想提醒你，不要忘了在需求分析过程中持续的搜集和整理术语表，想要一次性把术语表整理完毕是不太现实的。
[7] 其它
