原文链接：http://blog.csdn.net/yqmfly/article/details/7679781
通过阅读博客“我们应当怎样做需求分析”，在作者列举的一些失败的软件项目中，了解到了需求分析在项目开发中的重要性，并总结出了本学期《软件需求与分析》所需要掌握的三方面的基础内容：需求调研、需求分析和需求确认。下面我分别对这三方面表达一下自己的理解。
一、需求调研
需求调研是需求分析最重要的一环，文章中对如何做需求调研大致分了六部分进行讨论：初识、拜访、研讨会、需求研讨、迭代和需求捕获。
（1）初识
1、树立良好的职业威信，使项目向着一种良性的方向前进；2、进行详细角色分析，将与会各方代表对号入座，找对正确的人；3、从宏观上制订目标与方案，询问客户方领导对这个项目的期望，渴望达到的项目预期，我们对达到这些预期的整体解决方案进行描述
（2）拜访
在有一个良好的开端之后，就要一个一个去摆放他们，展开需求调研。软件供应商与客户建立的是长期共赢的战略协作关系，要分析一个客户人群的关系，选对盟友站在一起，建立战略或合作伙伴关系，依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
（3）研讨会
组织业务研讨很重要又很灵活，没有一个定式，项目经理需要根据实际情况，合理地与客户组织研讨会，这就要求做到有效抑制个性化差异、分模块组织专项研讨会。
（4）需求研讨
在与客户进行需求研讨的时候，首先跟客户研讨的不是软件功能，而是客户现有的业务知识，这样才能去分析他们提出的所有原始需求，才能深刻理解需求，进而运用我们的专业知识，提出更加合理的技术方案。
（5）迭代
需求分析不是一蹴而就的，是一个反复迭代的过程。在第一次的需求分析阶段，一段时间内需要与客户进行反复讨论，就是一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••每深入一步，软件就会更接近客户的满意。
（6）需求捕获
客户没有可以展示和操作的实物，对它们的需求只是凭空想象。我们只有去理解了客户现有的操作流程，并且有意识地发现那些不合理的部分，提出更加合理、更适于信息化管理的流程。
二、需求分析
（1）功能角色分析与用例图
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图有三种元素：参与者，用例和系统边界，它描述的是系统到底为用户提供了哪些功能、哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。
（2）业务流程分析
拿到软解需求，要对其进行细化，细化需求的一个方向就是业务流分析。分清系统外和系统内，对开发进行简化，进而提高工作效率。
（3）用例说明
公认的用例说明的基本元素包括用例名称、用例描述、参与者、前置条件、事件流和后置条件。在用例说明后面可以加上相关的需求列表，便于需求跟踪。
（4）查询报表分析
一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。需求人员在进行需求分析阶段，应当准确地与客户敲定这些格式，并最终在用例说明中体现出来。
（5）自用例与扩展用例
在用例分析中，将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，
（6）行动图和状态图
可以有效的弥补用例说明存在的业务流程整体描述的丢失和缺乏生动图形的缺陷，
（7）业务领域分析
通过与用户进行交流，掌握领域知识，绘制成业务领域模型，来指导我们进行软件开发，提高项目的正确性和提高项目的开发效率。
（8）原文分析法领域驱动设计
这两种方法可以指导我们进行业务领域分析。原文分析发，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。领域驱动设计（在我的理解）就是客户与你之间形成一种统一语言，这种语言有助于两者之间的交流。
（9）非功能需求
非功能需求很重要却常常被忽略，我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。
三、需求确认
在经过需求调研和需求分析之后，需要对需求进行进一步的确认。需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。它包括需求列表；快速原型法来构建出一个实物，不断进行改进；制定需求规格说明书和评审与签字确认会。
其之间的关联关系：
