博客阅读作业

博客链接地址：

http://blog.csdn.net/yqmfly/article/details/7679781

感受理解：

为什么要需求分析：失败的项目却各有各的问题，但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。

需要学习的方面：有效建模、统一语言和持续学习。

1、掌握统一建模语言.

用例图：用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。

用例说明：在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。
在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。

文字描述：图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。

行动图和状态图：正如任何事物都有两面性，用例图也不例外，也有自己不利的一面——不生动形象。用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。

2、各种文档的编写形式。

测试计划、软件概要设计说明书、软件概要设计说明书、软件概要设计说明书、软件概要设计说明书、项目开发计划等等。

3、需求分析流程

第一阶段：

　　总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。 

该阶段的主要工作方法：客户访谈 

输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结） 

第二阶段：

　　详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。 

该阶段的主要工作方法：访谈、业务分析、原型设计演示

输出成果：调研分析报告、原型反馈报告、业务流程报告 

第三阶段：

　　需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 

实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 

输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档。

 

4、培养为人处世，交流能力。

很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。