原文地址：http://blog.csdn.net/yqmfly/article/details/767978
文章开头作者首先举了几个他以前失败的软件开发案例，这些案例失败的原因各有不同，但大都都是在需求分析方面出现了问题，下面是我总结的在软件需求与分析中需要掌握哪些必要的内容。
（一）软件需求的前期调研
软件需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
1.初始——人与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。注意以下三点：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
2.拜访——软件供应商与客户建立的是长期共赢的战略协作关系，这更需要我们与客户建立长期友好的关系。经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
3.研讨会——在业务研讨会后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。但注意两点：有效抑制个性化差异、分模块组织专项研讨会。
4.需求研讨——需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代——需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。需求分析就是按照迭代的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
6.需求捕获——我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。
（二）软件的需求分析
1.功能角色分析与用例图——在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary)，用例描述的是系统为用户提供的功能，也就是系统能为用户做什么；参与者（角色），就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责；系统边界，就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
2.业务流程分析——两个方向细化需求：业务流程分析与业务领域分析。我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细，无疑会加重基层业务人员的负担，而适当的信息化管理则可以提高工作效率。
4.用例说明——要将业务流程分析落到纸面上，这就是用例图说明，图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
5.查询报表分析——报表作用体现的是报表对于不同用户的真实意图，对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。
6.子用例与扩展用例——在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程，将这部分流程提取出来形成的就是子用例，子用例应当是在逻辑上相对独立的一系统流程组成的用例；扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例。对子用例与扩展用例的分析，提高了系统的内聚并降低了系统的耦合。
7.行动图和状态图——有效地弥补了用例说明中对流程的描述都是用枯燥无味的文字来表述的、缺乏生动形象的图形表示这点不足。
8.业务领域分析——通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
9.原文分析法——是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。
10.领域驱动设计——比如说你正在做的软件是关于某个领域的，你要持续学习，你每认识深入一点儿，就可能会体现到你的分析设计中，并最终体现在开发的软件中。你对领域知识认识再深入一点儿，软件就再完善一分。
11.非功能需求——千万不要忽略这些非功能需求，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
（三）软件的需求确认
1.需求列表——它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
2.一个需求的实例——当需求分析工作完成时，我们将一项一项检查用例模型是否满足需求列表的内容；当软件开发完成时，我们将一项一项检查软件功能是否满足需求列表的内容；当用户验收时，我们同样使用需求列表，一项一项检查我们的软件是否满足用户需求。
3.快速原型法——当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。
4.需求规格说明书——之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。
一般包括：
5.评审与签字确认会——需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。
在软件需求与分析课上主要要掌握软件调研、软件需求分析、软件需求确认这三大方面。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。由于人在知识水平、观点看法、性格特质的不同，听者常常会误解对方的意思。有了复述的步骤，误解就会立即被纠正，沟通得以顺畅。在需求分析中，这个复述的步骤就是需求确认。所以三者密不可分。