用户提出“需要”的特性并不总是与用户利用新产品来处理他们的任务( t a s k )时所需的功能相等价。因此,当你收集到用户的意见后,必须分析、整理这些需求意见,直到你理解它为止,并把你的理解写成文档,然后与用户一起探讨,这是一个反复的过程, 并且需要花费时间。如果你不在这一方面花时间,对预期产品一致的看法未达成共识—最终的后果可能是返工,并且产品不尽人意。
6. 观察正在工作的用户 对当前系统的用户和将来系统的有潜力的用户,分析员观察“日常工作”以获得经验,这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题,并能分析新的系统可有效支持工作流程的方面(McGraw and Harbison 1997; Beyer and Holtzblatt 1998)。比起仅仅简单地询问用户,并记下用户在处理任务时的步骤来说,直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动,以确保所获得的需求具有普遍性,而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。
7. 用户任务的内容分析 通常通过开发具体的情节( s c e n a r i o)或活动顺序(有时称作“情节”),可以确定用户利 用系统需要完成的任务,分析员由此可以获得用户用于处理任务的必要的功能需求。这是使 用实例方法的精髓