要求每位与会者在开会的前几天认真复审产品需求，并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。此外，还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理或功能)。最后，还应该列出约束条件(例如成本、规模、完成日期)和性能标准(例如速度、精度)。并不期望每位与会者列出的内容都是毫无遗漏的，但是，希望能准确表达出每个人对目标系统的认识。

　　会议开始之后，讨论的第一个议题是是否需要这个新产品，一旦大家都同意确实需要这个新产品，每位与会者就应该展示他们在会前准备好的列表供大家讨论。可以把这些列表抄写在大纸上钉在墙上，或者写在白板上挂在墙上。理想的情况是，表中每一项都能单独移动，这样就能删除或增添表项，或组合不同的列表。在这个阶段，严格禁止批评与争论。

　　在展示了每个人针对某个议题的列表之后，小组共同创建一张组合列表。在组合列表中消去了冗余项，加入了在展示过程中产生的新想法，但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后，由协调人主持讨论。组合列表将被缩短、加长或重新措辞，以便更恰当地描述将被开发的产品。讨论的目标是，针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。

　　一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的一个或多个项目制定出小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。

　　然后，每个小组都向全体与会者展示他们制定出的小型规格说明供大家讨论。通过讨论可能会增加或删除一些内容，也可能做一螋进一步的精化工作。在讨论过程中还可能提出一些无法在这次会议中解决的问题，应该保存问题清单，以便这些想法在以后的活动中起作用。

　　在完成了小型规格说明之后，每个与会者都制定出产品的一整套确认标准，并把自己制定的列表提交会议讨论，以创建出意见…一致的确认标准列表。最后，由一名或多名与会者根据会议成果起草完整的规格说明。

　　简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是，这种面向团队的需求收集方法确实有许多突出的优点：开发者与用户不分彼此，集思广益，益密切合作;即时讨论和求精;有能导出规格说明的具体步骤。