阅读博客——我们应当怎样做需求分析？
链接地址：http://blog.csdn.net/yqmfly/article/details/7679781
发表一篇阅读笔记，说明本学期《软件需求与分析》需要掌握哪些必要的内容？针对每个内容点说出自己的理解，并绘图示意相互之间的关联关系。
读了《我们应当怎样做需求分析》后，我认为本学期《软件需求与分析》应该掌握以下几点：
一、需求调研
需求调研是需求分析最重要的一部分，原文中提到：需求分析的特点——既是一种体力活，更是一份技术活。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
所以需求调研并不是一份简单的工作，在这个过程中，我们要学会与用户进行沟通，从与他们的沟通过程中，我们要明白用户所真正的需求。然而沟通的过程是比较困难的，作者给了我们三点建议：1）建立良好的职业威信。2）进行详细角色分析，将与会各方代表对号入座。3）从宏观上制订目标与方案。
另外，业务研讨会也是与用户沟通的所必须条件，研讨会的形式很灵活，但是仍需注意有效抑制个性化差异、分模块组织专项研讨会。而且在软件需求分析的过程中，用户并不能准确的描述出他们所真正需要的东西——即并不能真正的提出准确的需求。因此，在业务研讨会中，我们可以有时间，有地点，能好好的从与用户的探讨过程中分析出他们真正的需求。同时，我们应该知道，用户为什么会提出这样的需求，提出这样的需求的出发点是什么。只有真正弄明白了这些，我们才可以准确快速的利用我们的专业知识，提出关于这些需求的解决方案。
最后，我们应该学会需求整理。划分整个系统的功能模块，以及各个模块的业务流程。在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。最后，当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。
二、需求分析
1、功能角色分析与用例图
我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。
2、业务流程分析
根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。
3、用例说明
在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，因此用例说明可以更好的让我们理解用例图。
4、查询报表分析
我们应根据需求实际设计不同的查询报表，按照用户的需求进行设计。
5、子用例与扩展用例
在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。
6、行动图和状态图
用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
7、业务领域分析
业务领域分析就是通过与该业务领域的专家进行学习，了解该领域的一些基础知识，然后构建该领域的知识体系，了解该领域需要什么实体，并可以对业务流程更加熟悉，有助于在项目开发中进行参考，从而提高项目的正确性和提高项目的开发效率。
8、原文分析法
原文分析就是分析需求的原文，提取出业务领域的名词，对名词进行分析提取出业务领域的实体。
三、需求确认
需求确认是在完成需求分析后，需求分析人员将分析结果与客户再次进行确认，看看是否有误解或者不合适的地方。需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。在开始因为没有实物，客户往往描述不清楚自己的确切需求，所以需求往往不明确，我们应该根据用户的初步需求利用快速原型法快速构建出一个实物供用户参考，然后再让用户提出更深一层次的需求，从而不断地深化、细化需求，从而使用户的需求都展现给需求人员。我们不能仅利用用户原始的需求进行开发，应该制定用户需求规格说明书，因为用户描述的需求是脱离了技术实现的，所以我们应该编写自己的需求规格说明书，本着实事求是、切实可行的态度去描述用户的业务需求。
想要做好需求确认，我们要学习如何制定需求列表、需求规格说明书等相关文档，书写文档是需求分析人员的基本功，需要我们加强练习，努力掌握。
