作
俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。
４） 从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出生的需求分析师来说是一个巨大的考验。
５） 文档考古
对于一些数据流比较复杂的、工作表单较多的项目，有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究，考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告，获得所需的信息。
６） 需求讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。
在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。
７） 原型法
原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
原型法的优点是：
i）鼓励业务管理者的积极参与；
ii）有助于解决业务管理者之间的差异；
iii）能给业务管理者一个对最终系统的直观感受；４）周期短；５）成本低；６）用户较满意。
但原型法也有缺点，主要为：
i）导致人们认为最终系统将很快产生；
ii）对系统操作权限的说明较弱；
iii）不适合于开发大系统；
iv）开发过程管理困难。
在实际开发过程中，笔者所在公司一般比较常用的需求获取方法是用户访谈、需求讨论会和原型法。对于相对较小的项目，笔者极力推荐原型法，因为通过可视化的界面，可更容易的、更快的挖掘客户的需求。
二、人员配置
在整个项目的生命周期中，可能涉及到开发方的角色如下：
1、需求分析师
完成产品或项目的需求调研和开发，将客户的需求变成产品需求，参与需求的讨论和分析，完成需求规格说明书等的编写。
2、系统架构师
系统架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，他侧重于系统的质量属性设计，包括系统的可靠性、可测试性、可重用性、可维护性、可重用性、可扩展性、性能指标、组件框架设计、共用基础结构等。
3、系统分析员
该角色是系统设计中的一个主要角色，他参与需求分析、系统功能设计、系统质量属性设计等过程。
4、项目经理
项目经理是项目沟通的纽带，他执行项目的进度跟踪、质量管理、客户非技术人员业务交流、项目成员共同、非技术风险管理等职责。
5、配置管理员
该角色的职责是完成项目中各文档的管理等。
6、QA
重点关注软件过程的质量，在项目