阅读博客——我们应当怎样做需求分析？
链接地址：http://blog.csdn.net/yqmfly/article/details/7679781
发表一篇阅读笔记，说明本学期《软件需求与分析》需要掌握哪些必要的内容？针对每个内容点说出自己的理解，并绘图示意相互之间的关联关系。
通过读《我们应当怎样做需求分析》这篇博客后，我对认为本学期《软件需求与分析》需要掌握以下三点：
一、需求调研
需求调研是需求分析最重要的一环，它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。要想保质保量的完成一个项目，需要我们明确了解用户的需求是什么。了解用户的需求，是成功完成一个项目的基础。而需求调研则是我们了解用户需求的重要一环，在这个环节中，我们需要与用户沟通，在沟通过程中我们要找到用户的需求。
而这个沟通过程是比较困难的，在这里作者给出了三点比较有效的建议。①建立良好的职业威信。我们应该给用户留下一个良好的印象，在保持适当谦卑的同时又要提出自己的建议。能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。②进行详细角色分析，将与会各方代表对号入座。弄清楚每个角色的需求提出者与决策者能帮助我们更快的明确需求3）从宏观上制订目标与方案。在这个过程中，我们要努力发展可以争取的盟友，而对于那些不支持我们的人，我们也要坦荡、真诚的与人交往。
当进行初步的收集后，我们要开业务研讨会，研讨会形式灵活，但需注意有效抑制个性化差异、分模块组织专项研讨会。在需求分析过程中，客户经常性的提不出正确的需求。所以，我们在进行需求分析时，我们可以先和客户探讨客户现有的业务知识，只有这样才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。而且，我们可以努力学习跟本次项目有关的知识，深入了解这个业务流程。
而且，我们应该学会需求整理。需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。最后，当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。
二、需求分析
当采集到用户需求后，我们应及时进行需求分析，通过分析客户提出的需求，明确开发的方向。而如何进行需求分析才能做到不遗漏，有条理很重要。不同类型的软件项目其分析方法可能存在差异，这个需要我们认真学习。
信息化管理类软件项目通常从功能角色分析、业务流程分析与业务领域分析。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。但是我们还需要进行细化需求，有两个方向细化需求：业务流程分析与业务领域分析。我们进行流程分析，就是要求分析哪些是系统之内的，哪些是系统之外的。业务领域分析是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。不同的知识领域拥有各自不同的领域知识，需求分析人员就应该通过客户中的领域专家去学习这些知识、掌握这些要点，并最终体现在我们的需求分析中。我们对业务领域的认识深入一点儿，我们的软件系统就完善一分，再深入一点儿，就再完善一分。
三、需求确认
需求确认是在完成需求分析后，需求分析人员将分析结果与客户再次进行确认，看看是否有误解或者不合适的地方。需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。
但是不论我们如何分析与设计，我们都要如实记录原始的需求，并以此来验证我们最终的软件。这个如实记录原始需求的文档，就是需求列表。需求列表需求列表不掺杂我们对业务需求的任何分析与设计。需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。需求列表也是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。
想要做好需求确认，我们要学习如何制定需求列表、需求规格说明书等相关文档，书写文档是需求分析人员的基本功，需要我们加强练习，努力掌握。
通过阅读《我们应该怎样做需求分析》这篇博客，我发现需求分析并没有我想象的那么简单，它是一个漫长、甚至枯燥的过程，需要需求分析人员有耐心、细心以及专业素养，这些东西也是我们需要学习的。
