01 需求分析.pptVIP

需求分析 * * * 需求是系统的基础，陈述系统做什么，解决do what,而不是how to do。 何谓需求？ 功能需求：是指系统必须完成的那些事，即系统要完成用户提出的各种功能要求； 非功能需求：是指软件必须具备的品质或属性，如可靠性、性能、系统响应时间、容错、系统可扩展性等； 设计约束：一般是指客户提出的一些补充约束说明，如系统必须基于SOA设计模式、必须采用Oracle数据库、必须采用商用服务器、必须做应用服务器的负载均衡、必须采用Unix服务器等技术要求。 需求包含哪些内容？ 需求分析就是分析客户的需求是什么（分析原系统功能、存在的问题以及客户对未来系统的期望），全面地理解客户的各项要求，并准确地表达所接受的客户需求。 简言之，需求分析是获取需求、表达需求和验证需求的过程，最终形成一个客户和开发人员都遵守的规约：软件需求规格说明书，在需求规格说明书中详细记录项目的目标、约束条件、功能需求、非功能需求、接口需求、开发运行环境要求等内容。 什么是需求分析？ 原系统 存在问题 客户期望 需求规 格说明 需求 分析 输入 处理 输出 需求分析输入输出 问卷调查 事先设计好需要提问的问题，然后形成问卷并将 问卷发放给所有和系统相关的客户人员，客户人员根据自己的工作职责，以答卷的形式表达对未来系统的要求。 客户访谈 通过与客户方的项目相关人员面对面交流，直接了解到客户对系统的要求。访谈的形式可以多样化，可以是正规会议、小组讨论或电话沟通。 获取需求方式 软件需求主要包括功能需求、非功能需求和约束条件三个方面，可以采用自然语言的方式来描述，例（一个包含注册功能的网站）： 功能需求部分 注册功能：客户访问网站首页，点击注册链接，之后打开注册 页面，客户输入注册相关信息（用户名、密码、联系 方 式、……）,然后系统保存信息。 XX功能：…… 非功能需求部分 性能要求：网页点击响应时间在5秒内。 可靠性：要求系统7*24小时连续运行。 …… 约束条件 进度要求：从签订合同起三个月内开始试运行。 运行环境：Web服务器：Tomcat 6.0；数据库：MySql 5.0。 …… 表达需求方式—自然语言 需求表达本身没有好坏之分，只要能正确表达即可，但需求表达不是为了表达而表达，重要的在于需求文档要易于交流，与客户交流、与项目团队交流，尤其是与客户交流这一环节，自然语言表达方式不是太直观，在表达功能需求时更侧重于从系统的角度出发，不是从用户的角度出发。 20世纪60年代后期，Ivar Jacobson提出了“用例”的概念。20世纪80年代，他将用例引入了面向对象编程领域，填补了需求分析过程的一个空白。“用例”的另一用叫法是“用况”，都是译过来的词汇，其原文为Use Case，强调的是用户使用系统的情况，一种使用场景，所以用例法更利于用户理解，接下来我们将介绍如何基于用例法表达系统的功能需求。 表达需求方式—用例模型 用例描述了系统完成动作的序列，这一序列动作对执行者产生一个有价值的可见结果。 动作序列：动作序列描述了为产生结果而进行的一系列动作，当执行者提供信息启动该用例，就激活了这些动作； 系统完成：系统为执行者服务； 有价值的可见结果：这是最重要的部分，执行者使用系统一定是为了达成什么目标，用例必须对执行者有价值； 执行者：可以是一个启动用例的个体或设备。 用例是什么？ 用例建模是UML（Unified Modeling Language，统一建模语言）建模的一部分，在我眼里，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求。 用例建模可分为用例图绘制和用例描述两部分，用例图由执行者（Actor）、用例（Use Case）、系统边界、箭头组成，用例描述用来详细描述用例图中每个用例，用文本文档来完成。初学者在这个地方容易走入误区，以为用例建模就是画几个图，其实不然，用例图可以帮助我们表达功能需求的全貌，但用例的根本仍然是文本描述。 用例建模 主执行者 系统边界 用例 箭头 执行者：不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色 。 用例 ：用例是执行者想要系统做的事情。 系统边界 ：是用来表示正在建模系统的边界 。 箭头：用来表示执行者和系统通过相互发送信号或消息进行交互的关联关系。 用例图 用例描述都有的五个必要元素： 名称：每个用例都应该有一个名字，表明执行者对系统的某种要求。通常采用动宾结构短语，简单但有描述性 。 简要描述：用一两句话描述用例的用途 执行者：每个用例必须有执行者，否则该用例存在就是多余的。知道每个用例的执行者是谁可以帮助理解系统，尤其是较复杂