在开发软件项目时，有很多开发失败的案例。探其原因，归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。看了这篇文章，才意识到软件需求分析并不容易。
首先，需求调研是需求分析的第一步。第一，我们需要给客户留下良好的第一印象，当我们对客户提出的需求进行深入理解以后，要运用我们专业的知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉我们说的正是他们想要的。以此来让客户感觉我们的专业，从而树立威信。
在调研不同部门的需求时，将业务人员划分为多个业务组也是一项比较成功的经验。由于业务人员自身的局限，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量。同时，一个管理系统涉及的业务是复杂而系统的，如果划分成多个模块并行地进行业务讨论，也可以大大提高业务研讨的工作效率。
需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获。。。。。。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。
在分析已获取的需求时，主要从功能角色分析、业务流程分析与业务领域分析这三个方面来分析。
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。
企业信息化就是一次改革，这特别集中地体现在了业务流程分析这一部分。当我们详细分析了客户现有的业务流程以后，应当进一步思考这样的流程是否合理，是否值得改进。我们可以用以下思路来进行我们对流程改进的分析：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。现在，在面向对象的时代，我们要掌握绘制行动图、状态图，以及编写用例说明的能力来完成这部分工作，其中，编写用例说明是最主要的工作。
在需求分析工作中，业务领域分析是最后一项分析工作。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。日后我们去设计开发系统时，应当设计哪些类，类中都应当有什么属性和行为，以及怎样去设计数据库，都是以这个领域模型为基础的，虽然有时并不完全与领域模型完全一致。过去，没有一个切实可行的方法来指导我们的业务领域分析，而现在，我们可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。
需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。所以我们要尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计，以提升我们软件的运行性能。
最后一步，在分析完需求后，我们需要做最后的需求确认。首先我们要复述需求，这一步也非常重要。因为人与人的沟通最大的问题就是失真。由于人在知识水平、观点看法、性格特质的不同，听者常常会误解对方的意思。有了复述的步骤，误解就会立即被纠正，沟通得以顺畅。
需求规格说明书要详细清楚的书写，本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求要摒弃，或者换成更加可行的解决方案。
