在进行讨论时，也应该避免受不成熟的细节的影响，在对系统需求取得共识之前，用户能很容易地在一个报表或对话框中列出某些精确设计，如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制，应确保用户参与者将注意力集中在与所讨论的话题适合的抽象层上，重点就是讨论做什么而不是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完成需求。在讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正，因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候，会议就算成功完成了。但是要清楚需求过程本身就是一个迭代的过程，在以后的过程活动中不可避免的将要修改和完善这份报告。
7、分析用户工作流程
分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号,为每个用例分配一个唯一的编号，为需求的追溯提供了方便；参与者，与这个用例交互的actor；前置条件，开始用例前所必须具备的系统状态；后置条件，用例完成后系统达到的状态；基本路径，用例完成的关键路径，也是用户期望的路径；扩展点，基本路径的分枝，表示意外情况；字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用；设计约束，实现用例的非功能约束。写基本路径时应该使用主动语句；句子以actor或者系统作为主语；一句表示一个actor动作，一句表示系统动作，交叉表现交互；不要涉及界面细节，比如"用户在文本框输入名称，下拉框选择类型"。
用例：用户注册，用户注册成为系统会员
编号 UC1
参与者 用户
前置条件 用户访问系统，系统运行正常
后置条件 系统记录用户注册信息
基本路径 1. 用户请求注册。
2. 系统显示注册界面。
3. 用户提交注册信息。
4. 系统验证注册信息是否正确。
5. 系统生成用户名和密码，保存注册信息。
6. 系统显示"注册成功"信息，进入会员页面。
扩展点 4a. 用户提供的信息不正确：
4a1. 系统提示输入正确信息
4a2. 返回3
补充说明 注册信息包括＝用户实名＋电话＋传真＋Email＋联系地址联系地址＝省份＋城市＋街道＋邮编
设计约束
注册反应时间不能超过3秒
8、确定质量属性