1、软件工程导论,School of Information Engineering Zhengzhou University Students: SophomoreSemester: Spring of 2011 Instructor: Wang RuiminOffice：Room 219，Building 18 （South Campus） ieR,软件需求分析,3,主要内容,一、软件需求分析概述 二、软件需求分析的任务和步骤 三、需求获取的常用方法 四、分析建模 五、需求规格说明书与需求评审,4,一、软件需求分析概述,软件开发期的第一个阶段 明确软件要“做什么”的问题 是关系到软件开发成败的
2、关键步骤,5,需求问题,需求是软件项目成败的关键所在。 越早发现需求错误，越早改正它，其代价越小 需求是系统必须具有的能力。 好需求的特征： 无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。,6,软件开发的目标,软件开发的目标，简单而言，就是满足用户的需要 。,7,项目失败与成功的原因*,三种最经常使项目“遇到困难”的因素是： 缺乏用户介入：占所有项目的13% 不完整的需求和规格说明：占所有项目的12% 不断改变的需求和规格说明：占所有项目的12% 三种项目最主要的“成功因素”是： 用户介入：占所有成功项目的16% 高层管理的支持：占所有成功项目的14% 需求陈述清晰：占所
3、有成功项目的12%*Standish Group ，1994从历年的Standish Group报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目的变更。,8,2-8 原则*,80%的工程活动是由20%的需求消耗的 80%的软件成本是由20%的构件消耗的 *Royce，1998,9,需求在项目中的作用,在项目开发中，所有的涉众（Stakeholder）都对需求分析阶段倍感兴趣。 未真正明白这些问题就开始编码，结果没有人对产品满意 。,10,什么是需求,需求的基
4、本概念 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。,11,需求的重要性,Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性： 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。,12,需求是产品的根源，需求工作的优劣对产
5、品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。,人们并不清楚究竟该做什么，但却一直忙碌不停地开发。,13,需求错误的代价,在生命周期的不同阶段修复缺陷的相对成本,14,需求缺陷造成的成本增加,重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单告诉用户将以一个修正后的版本来替代有缺陷的版本。 纠正活动消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。 报废包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品
6、以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。,15,高质量的需求过程带来的好处,在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。,16,17,18,19,解密：实际需求,原来如此！,20,Return,2
7、1,将问题与解决方案分开,理解问题：需求获取 问题的形式化表示形式规约，形式建模 就问题性质达成共识验证, 冲突及矛盾消解, 磋商需求管理 维护双方的共识,22,But, what is a requirement?,每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述即是需求。 Herbert Simon, 1969 需求, 即是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的依据。 IEEE 61
8、0.12, 1990,二、需求分析的任务与步骤,2.1 需求分析的任务 2.2 需求分析的步骤,23,2.1 需求分析的任务,1、通过对问题及其环境的理解、分析和综合，建立分析模型； 2、在完全弄清用户对软件系统的确切要求的基础上，用“软件需求规格说明书”把用户的需求不大出来。,24,软件需求分析的过程就是系统分析员、需求工程师与用户共同协商，明确系统的全部功能、性能及运行规格，并且使用软件开发人员与用户具有一致理解的语言准确表达出来。准确、完整和规范化的软件需求是软件开发成功的关键。,25,26,1、建立分析模型,分析模型（Analysis Model）是描述软件需求的一组模型（常由一组图、
9、表加上注释组成） 精确记录用户对原始问题和目标软件的描述。 帮助分析人员发现用户需求中的不一致性，排除不合理部分，挖掘潜在的用户要求。 应包含有对系统信息流、处理功能、用户界面、行为模型、设计约束的描述。,27,精确性、一致性 清晰性、没有二义性 直观、易读、易于修改,2、编写需求规格说明,28,软件需求各组成部分之间的关系,29,需求获取 系统功能、界面、质量等方面的需求 需求提炼（分析） 分析建模，常用建模工具数据流图（DFD）、实体关系图（ER图）、控制流图（CFD）、状态转换图（STD图）、用例图（use case）、类对象关系及行为图 需求描述（规格说明） 编写SRS 需求验证 确保
10、需求规格说明可作为软件设计和最终系统验收的依据,2.2 需求分析的步骤,30,Requirements Engineering Process,31,需求分析阶段的活动,32,需求分析的步骤,通过对现实环境的调查研究，获得当前系统的具体模型； 去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型； 分析当前系统与目标系统的差别，建立目标系统的逻辑模型； 对目标系统进行完善和补充，并写出完整的需求说明； 对需求说明进行复审。,三、需求获取的常用方法,3.1 常规的需求获取方法 3.2 快速原型方法,33,34,3.1 常规的需求获取方法,建立联合分析小组 用户代表、领域专家和系统分析员 客户访谈
11、 充分准备，寻找共同语言 循序渐进、逐步逼近 问题分析与确认 多个来回,3.2 快速原型方法 有效的需求获取方法,步骤 利用各种分析技术和方法，生成一个简化的需求规格说明 对需求规格说明进行必要的检查修改后，确定原型的软件结构、用户界面和数据结构等 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进 将原型提交给用户评估并征求用户的修改意见 重复上述过程，直到原型得到用户的认可,35,四、分析建模,4.1 两种分析模型 软件的分析模型通常用一组模型组成，其中包括信息（或数据）模型、功能模型和行为模型。结构化分析模型面向对象分析模型 4.2 分析模型的组成与描述工具DFD、DD和
12、PSPEC CFD、CSPEC和STD E-R图 用例图，对象-关系图，对象-行为图,36,37,结构化分析模型,加工说明（PSPEC）,数据对象说明,CFD,STD图,DFD图,E-R图,DD,控制说明（CSPEC）,功能模型,行为模型,数据模型,38,面向对象分析模型,39,结构化分析工具 DFD、DD和PSPEC 早期结构化分析模型的基本组成部分 CFD、CSPEC和STD 扩展，用以适应实时软件建模的需要 E-R图 适用于描述具有复杂数据结构的软件数据模型 面向对象分析工具 用例图，类对象图 对象-关系图 对象-行为图,分析模型的组成与描述工具,五、需求规格说明书与需求评审,40,SR
13、S的目标,41,便于用户、分析人员和设计人员进行理解和交流。 支持目标系统的确认。 控制系统进化过程。,42,软件需求说明（SRS）,引言 信息描述 功能描述 行为描述 质量保证 接口描述 其它,给出对软件所含信息的详细描述,包括信息的内容、关系、数据流向、控制流向和结构等。根据系统所选用的不同的分析方法，可以用不同的工具描述软件设计的数据的定义和系统的信息逻辑模型。,对软件功能要求进行说明，包括系统功能划分、每个功能的处理说明、限制和控制描述等。对软件性能的需求，包括软件的处理速度、响应时间和安全限制等内容，通常也在此叙述。,对系统状态的变化以及事件和动作的叙述，据此可以检查外部事件和软件内部的控制特征。,阐明在软件交付使用前需要进行的功能测试和性能测试，并且规定源程序和文档应该遵守的各种标准。,对系统的用户界面、硬件接口、软件接口和通信接口等的说明。,阐述系统设计和实现上的限制，系统的假设和依赖等其他需要说明的内容。,主要叙述在问题定义阶段确定的关于软件的目标与范围，简要介绍系统背景、概貌、软件项目约束和参考资料等。,43,需求评审,在提交设计之前进行。 需求评审的标准： 正确性 无歧义性 完全性 可验证性 一致性 可理解性 可修改性 可追踪性,一般以用户、分析人员和系统设计人员共同参与的会议形式进行。,44,Any Question？ Thanks For Coming!,
