软件开发的很多中文名词含义不太确切。需求分析严格地讲是指分析用户需求和软件规格之间差异的过程。但很多人说需求分析的时候，实际是想表达需求开发过程。我推测问题中的需求分析实指需求开发过程。
需求开发过程主要完成哪些工作呢﹣﹣发展一批理解需求的人（见≪需求探索≫）。这最简明扼要地表达了需求的工作。以此出发点的，考虑到项目特点，用户信息化成熟度和习惯，自己的能力和习惯，因地制宜地采取合适的需求开发方式。需求开发方式的不同，做的工作会有不同。
以下以其中一种需求开发方式，举例说明需求开发过程的工作。
需求调研
确定需求调研对象（和用户的领导会议展开协商需求调研需哪些用户代表何时参与需求调研过程）
制定需求调研计划。
需求调研。需求调研的产出物通常不要强调结构化表达，以一般会议记录的方式即可。
用户需求
显化现业务流程
显化现业务流程问题及改善
显化新业务流程
业务角色列表
业务改善方针（说明为了改善现业务，管理方面需做哪些调整、需准备哪些基础数据、需规范哪些旧数据）
系统功能列表（说明为了改善现业务，需调整或增加哪些系统功能）
制作界面图片（与新业务中人和系统协助完成的处理对应）
制作接口列表（与新业务中系统间交换数据的处理对应）
制作后台处理列表（与新业务中纯后台的处理对应）
文件列表（与新业务中，需导入/导出文件，用户会关心日志的处理对应）
…
用户需求评审
需求分析
显化用户需求与软件规格的差异（有些用户需求点能完全通过软件功能去满足，有些用户需求点只能通过软件功能部分地满足，有些用户需求点不通过软件功能去实现）
对用户需求的优先级进行排序
软件规格
功能结构（划分系统模块、功能点）
系统角色及权限列表
界面及功能说明
接口定义及功能说明
后台处理功能说明
文件处理功能说明
性能、容量方面的约定
……
软件规格评审
需求问题管理表（整个需求过程中，需跟进、协调的重要问题）
以上大纲中的个要点，除了指写文档，还指协调相关人员（用户，团队的设计、开发、测试人员……）周期地反复Review文档。
以上列的需求工作，需要用户有阅读需求文档的习惯，能定期Review需求文档，对于需求人员的文档水平要求较高，开发团队内部也能按此思路阅读需求文档，这几个要求缺一不可，否则会造成仅是制作了文档，而没有达到发展一批理解需求的人都目的。
有些企业用户并不乐于阅读文档（甚至可以说有些企业已经习惯文档仅是个形式的看法），需求人员的文档水平低，建议不使用上述的需求开发方法，否则很容易形成文档仅仅是文档，而没有达到发展一批理解需求的人的目的。或者采用轻文档（每个用户需求仅用简洁的文字描述）更直观（用原型或按优先级各个小阶段开发出来的程序与用户交流）的方式去展开需求开发工作。但也不是说不能采用举例中的方法，如果是和用户长期合作，并且用户的领导支持，可以在需求开发的过程中，教导用户（按上述大纲的方式、步骤，一个方面一个方面地探讨、Review需求），使得用户能与需求开发过程配合起来。这种方式会很艰辛。
