适合的抽象层上，重点就是讨论做什么而不是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完成需求。在讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正，因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候，会议就算成功完成了。但是要清楚需求过程本身就是一个迭代的过程，在以后的过程活动中不可避免的将要修改和完善这份报告。
7、分析用户工作流程
分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号，为每个用例分配一个唯一的编号，为需求的追溯提供了方便；参与者，与这个用例交互的actor；前置条件，开始用例前所必须具备的系统状态；后置条件，用例完成后系统达到的状态；基本路径，用例完成的关键路径，也是用户期望的路径；扩展点，基本路径的分枝，表示意外情况；字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用；设计约束，实现用例的非功能约束。写基本路径时应该使用主动语句；句子以actor或者系统作为主语；一句表示一个actor动作，一句表示系统动作，交叉表现交互；不要涉及界面细节，比如"用户在文本框输入名称，下拉框选择类型".
用例：用户注册，用户注册成为系统会员编号 UC1参与者 用户前置条件 用户访问系统，系统运行正常后置条件 系统记录用户注册信息基本路径
1.用户请求注册。
2.系统显示注册界面。
3.用户提交注册信息。
4.系统验证注册信息是否正确。
5.系统生成用户名和密码，保存注册信息。
6.系统显示"注册成功"信息，进入会员页面。
扩展点 4a. 用户提供的信息不正确：4a1.系统提示输入正确信息4a2.返回3补充说明 注册信息包括＝用户实名＋电话＋传真＋Email＋联系地址联系地址＝省份＋城市＋街道＋邮编设计约束 注册反应时间不能超过3秒
8、确定质量属性
在功能需求之外再考虑一下非功能的质量特点，以及确定由于特殊的商业应用环境对系统提出的功能或性能上的约束，这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义，并且要将质量属性分配到每个用例的设计约束中去。
9、检查问题报告
通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
10、需求重用
如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。