软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
在阅读了《我们应当怎样做软件需求分析》这篇文章后，我对本学期的《软件需求与分析》课程需要掌握的几个必要内容作出以下总结：
1.需求调研
1.1用户沟通
需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
需求调研毫无疑问考研沟通的能力，我们与客户的沟通结果对接下来的工作有着举足轻重的作用，沟通过程中需要注意3点：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
1.2研讨会
同时，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题，所以业务研讨会是必须的场景。业务研讨会有两种场景，一种是集中式的业务研讨会，另一种与之相对，是分散式的业务研讨会。业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
1.3需求研讨
在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。所以说，做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。需求分析不是一种简单的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
1.4迭代
首先我们要铭记一条道理，需求分析不是一蹴而就的，而是一个反复迭代的过程，一直持续到整个项目生命周期。
我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
1.5需求捕获
需求捕获，就是我们与客户在一起开研讨会，讨论需求的活动。需求捕获也是迭代过程的开始，也是整个需求分析工作中最重要的部分。
2.需求分析
2.1功能角色分析与用例图
在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。需要注意的是，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。
2.2业务流程分析
首先将系统划分成了几个功能模块。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言。
2.3用例说明
当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。
用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，最终偏离原始的需求（这种情况特别容易出现在日后的升级维护中）。因此，将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
2.4查询报表说明
报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。客户方的领导，特别是那些中层和高层领导，通过对这些报表的阅读，就可以掌握他们的工作进程、加强他们的人员管理、发现他们的管理漏洞、指导他们的战略决策。
2.5行动图和状态图
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在行动图中，往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
2.6业务领域分析
在需求分析工作中，最后一项分析工作就是业务领域分析。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。
我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
2.7非功能需求分析
需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。非功能需求，我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它。
3.需求确认
3.1需求列表
需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。
需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。
其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。
最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
需求列表是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。
3.2需求规格说明书
从理论上讲，需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。
3.3评审与签字确认
外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。
