现在我举一个具体实例来看看需求列表是怎样编写的吧。这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后，我们整理出这样一个需求列表：
　　1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。
　　2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，同时填写并提交各自的评审意见。
　　3．评审组长汇总所有的评审意见，并在评审会上依次过所有的评审意见，对评审意见进行修改或删除，填写问题跟踪，形成此次评审会上终的评审意见及问题跟踪表。
　　4．评审组长制作评审报告，并形成评审结论，以邮件的形式通知所有评审者。
　　5．所有评审者对评审报告进行回复意见，如果都选择同意，评审组长关闭此次评审。
　　6．评审组长跟踪所有问题，并可以依次关闭每个问题。
　　当然，在这个需求列表中，客户提出了一些名词，比如评审计划、评审意见、评审组长等。我们在整理需求列表的同时，应当注意整理这些名称，弄清它的内涵外延，以及它们相互之间的关系、作用。这将为我们后面的领域模型分析提供素材。毫无疑问，这样的需求列表过于粗略。因而在后面的业务讨论中，我们逐项对它们进行了细化：
　　1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。
　　1.1 评审时间应当分为数个阶段分别制订时间计划，如评审准备、评审会议、评审报告；
　　1.2 评审内容应当可以上传数个文件，分别描述文件的内容、作者、编写日期、版本号，供评审者下载与查看；
　　1.3 填写评审者时，选择一个评审者为评审组长，评审发起人不能是评审组长；
　　1.4 评审地点与预计评审工作量只需直接填写；
　　在我们后面的用例分析中，我们对这段需求列表进行了大量的分析设计。但这些都是设计与实现，它们会出现在后面的用例分析及其模型中，却不应出现在需求列表中。在后来的升级开发中，客户又提出了发邮件通知的功能。将该功能描述出来，并添加到需求列表中：
　　1.5 评审计划提交以后，以邮件的形式发送给每个评审者，通知该评审任务。
　　有了这样的需求列表，当需求分析工作完成时，我们将一项一项检查用例模型是否满足需求列表的内容；当软件开发完成时，我们将一项一项检查软件功能是否满足需求列表的内容；当用户验收时，我们同样使用需求列表，一项一项检查我们的软件是否满足用户需求。