软件工程教学课件第五章 需求分析

《软件工程教学课件第五章 需求分析》由会员分享，可在线阅读，更多相关《软件工程教学课件第五章 需求分析（69页珍藏版）》请在金锄头文库上搜索。

1、第5章 需 求 分 析意义： 软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。需求分析是软件定义时期的最后一个阶段 ，它的基本任务不是确定系统怎样完成它 的工作，而是确定系统必须完成哪些工作 ，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结 束之前，由系统分析员写出软件需求规格 说明书，以书面形式准确地描述软件需求 。即：- 准确地回答“系统必须做什么 ?”。 在分析软件需求和书写软件需求规格说 明书的过程中，分析员和用户都起着关 键的、必不可少的作用。 需求分析的结构化方法

2、都遵守下述准则：(3) 必须描述作为外部事件结果的软件行为，这 条准则要求建立行为模型。(2) 必须定义软件应完成的功能，这条准则要求 建立功能模型。(1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。(4) 必须对描述信息、功能和行为的模型进行分 解，用层次的方式展示细节。软件的需求包括： 功能需求功能需求 性能需求性能需求 环境需求环境需求 可靠性需求可靠性需求 安全保密要安全保密要 求求 用户界面需用户界面需 求求 资源使用需求资源使用需求 成本消耗需求成本消耗需求 开发进度需求开发进度需求 预先估计以后系统预先估计以后系统 可能达到的目标可能达到的目标5.1 需求分析的重

3、要性 需求分析的输入是软件合同或软件 立项建议书以及对用户现场的调研、分 析和确认，输出是用户需求报告/需 求规格说明书。 需求分析是软件设计中最为重要的一环，主要表 现在以下几点： （1）许多大型应用系统的失败，最后均归结到 需求分析的失败： （2）需求分析的输出文档是用户需求报告 （3）需求分析要占用整个软件开发时间或工作 量的30左右。 （4）需求获取中的错误属于软件开发中的早期 错误，它会在后续的设计和实现中进行发散式的 传播。 需求获取困难的原因 （1）用户需求具有动态性，即需求的不稳 定性：在整个软件生存周期内，应用软件 的需求会随着时间的进展而有所变化，个 别用户甚至会朝三暮四地

4、变化。 （2）用户需求具有模糊性，即需求的不 准确性。由于用户的水平不是很高，业务 流程不很规范，所以需求表达不很清楚也 不够明确。 （3）开发者和用户要对需求达成完全一 致的认识，用户要在需求报告上签字，要 承担责任。 （4）中国的国有企业正处于变动期（体 制改革与企业重组），中国的民营企业正 处于成长期（发展壮大与不完全成熟）。 而处于变动期和成长期的企业需求是不成 熟、不稳定和不规范的，这就给信息系统 的需求分析增加了难度系数。 相关的名词解释 需求分析的理论基础 软件需求的概念从根本上讲，软件需求就 是为了解决现实世界中的特定问题，软件 必须展现的属性。这里的问题可能是用户 的任务自动

5、化，或者由软件来完成一个组 织的业务处理，或者控制一个设备等。因 此，可能涉及使用软件的不同层次和不同 人员。软件需求的属性主要是可验证性、 优先级和唯一性。 （1）可验证性。可验证性是软件需求的基本属 性。软件需求必须是可验证的，否则软件的评审 和测试就没有相应的依据。但在某些情况下，很 难对某些软件需求进行验证或需要的代价很高。 软件需求人员和测试人员应以合理的代价实现需 求的验证。（2）优先级。软件需求应具有优先 级，可以在有限的资源（资金、人员、技术）情 况下进行取舍。（3）唯一性。软件需求应唯一 地标识出来，以便在软件配置管理和整个软件生 命周期中进行管理。 需求来源 （1）系统目的

6、。系统目的是指软件的整体目的或高 层的目标。这是进行软件开发的动机，但它们通常表 达比较模糊。软件分析师需要仔细地评估这些目标的 价值和成本，对系统的整体目标进行可行性研究。 （2）行业知识。软件分析师需要获取业务领域内的 相关知识。考虑到大众对于通用的行业知识会一概而 过，一些行业惯例需要软件分析师根据环境进行推断 。当需求发生矛盾时，软件分析师可以利用行业知识 对各种需求进行权衡。 （3）软件涉众。应充分考虑不同软件涉众的需求 。如果只强调某一角色的需求，忽略其他角色的需 求，往往会导致软件系统的失败。软件分析师应从 不同的角度去识别、表述用户的需求。用户的文化 差异、客户的组织结构，常常

7、是系统难以正常实施 的原因。 （4）运行环境。软件的运行环境包括地域限制、 实时性要求和网络性能等。系统的可行性和软件架 构都依赖于这些环境需求。 （5）组织环境。软件作为一个组织的业务流程支 持工具，受到组织结构、企业文化和内部政策的影 响。软件的需求也与组织结构、企业文化和内部政 策有关。5.2 需求分析的任务 需求分析的任务就是借助于当前系统的逻辑需求分析的任务就是借助于当前系统的逻辑 模型导出目标系统的逻辑模型，解决目标系模型导出目标系统的逻辑模型，解决目标系 统的统的 “ “做什么做什么” ” 的问题。的问题。 确定对系统的综合要求-功能需求、性能需求、可靠性和可用性需求、出错处理需

8、 求、接口需求、约束、 逆向需求 、将来可能提出的要求。 分析系统的数据要求 （1）输入数据。 （2）中间数据。 （3）输出数据。 导出系统的逻辑模型 在研究现行系统过程中，得到了现行系统的物理 模型和逻辑模型。然后，在现行系统的逻辑模 型上加上目标系统的新的需求来改变现存系统 逻辑模型中可能存在的不合理的部分，以得到 新系统的逻辑模型，最后加上计算机需要的处 理细节的有关内容以得到新系统的物理模型。 在这里所应用的方法和可行性研究中所用的完 全一样，只是可行性研究阶段得出的是新系统 顶层的逻辑模型与物理模型。在这里需要得到 所有层次上的模型，也就是说既有顶层的概括 模型，也有底层的细节模型。

9、 修正系统开发计划通过用户需求的调研与分析，对于 新系统的功能与规模有了更深入的理解， 用户也可能提出一些在可行性研究范围之 外的功能。这些都产生了对成本和进度重 新估算的需要。如果重新估算的成本和进 度显著地不同于可行性研究的结果，应该 修改系统开发计划。 开发模型系统系统开发模型系统是指在需求分析 阶段建造软件“样机”。它的目的主要是显 示系统的功能。6 写出需求规格说明书需求规格说明书，又称软件规格说明书，它是 软件需求分析工作的重要成果，是软件开发 、软件验收和软件管理的依据。因此，要特 别重视，不能有丝毫错误或不当。它被当作 是用户和开发人员双方达成的协议书。其中 ，阐明的需求是经过

10、分析以后双方对问题的 共同理解，而且是准备组织力量加以实现的 。5.3 需求分析的过程 （1）调查研究 （2）分析与综合 （3）书写需求分析的文档 （4）需求分析评审5.4 用户需求获取 需求收集是需求分析的第一步，需求获取是 一个确定用户的要求是什么的信息收集过程 。开发人员在需求收集时要同各种用户进行 交流，收集各种用户的信息，理解用户的各 项要求。然后开发人员才能对信息进行分析 ，澄清一些模糊的要求，向用户解释不合理 的或暂时无法实现的要求，以求得用户的谅 解。用户需求的特点现行系统的逻辑模型表达了现行系统的功能目 标，这是设计新系统的重要基础。 用户还希望实现某个特殊的功能、人机界面或

11、操 作方式，系统的环境还可能有某些约束、要求等 。 这些需求对新系统的实现起着很大的作用，对软 件的质量、生命力、命运起着不可低估的影响。 实际上，它们与现行系统的逻辑模型一起构成了 整个系统的需求，分析阶段的工作目标就是要实 现这样两个任务。用户需求的范围和目标 以下四个要点可作为控制范围大小的原则： （1）反对随意扩大系统范围边界的做法。 （2）系统范围大小和目标功能的多少、强弱的 确定，应在用户对项目的热情下降到危及项目开 发的冰点之前完成。 （3）系统的范围和功能目标中一定要包含边界 的定义及其精心地考虑。 （4）在确定系统需求范围时，要把效益高的部 分划进来，把效益低的部分划出去。

12、总之，确定目标和范围的原则就是尽可能地小一 些，保证尽快完成，接口要适应现行环境，要把 立竿见影的部分划进来。 非功能目标的确定 （1）灵活性和可维护性 （2）进度和成本 （3）效率 （4）集成 （5）安全性 （6）可靠性 （7）移植性和兼容性 （8）简明性需求收集的方式 访谈问卷调查场景使用用户资料收集(1). 访 谈 正式的访谈- 系统分析员将提出一些事先准备好的具体问题 。 非正式的访谈- 分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。 在访问用户的过程中使用情景分析技术往往非常有效。

13、所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而 便于用户理解，而且还可能进一步揭示出一些分 析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技 术能保证用户在需求分析过程中始终扮演一个积 极主动的角色。需求分析的目标是获知用户的真 实需求，而这一信息的惟一来源是用户，因此， 让用户起积极主动的作用对需求分析工作获得成 功是至关重要的。用户需求的获取过程 （1）非形式化方法 （2）半形式化方法 （3）形式化方法5.5 需求分析工具 判定表 判定树 结构

14、化分析语言LSA（Language of Structure Analysis） 结构化分析语言是一种说明需求分析中加 工基本说明的好工具。它是受结构化程序 设计思想的启发而扩展出来的。结构化分 析语言主要包括祈使语句、判断语句、循 环语句或者三者的复合组成。 PSL（Problem Statement Language，问题 陈述语言）/PSA（Problem Statement Analysis 问题陈述分析） 采用PSL/PSA辅助工具产生需求分析文档的 步骤是选用PSL写出系统的定义，步骤是： （1）确定对象和对象模型，并给对象起名字 。 （2）使用对象类型的记号画出系统图 （3）确定

15、对象之间的关系 （4）描述系统需求分析阶段的描述工具 层次方框图 Warnier图 IPO图改进的IPO图5.6 需求管理 需求管理主要活动 需求管理强调： （1）控制对需求基线的变动 （2）保持项目计划与需求一致 （3）控制单个需求和需求文档的版本情况 （4）管理需求和联系链，或者管理单个需 求和其他项目可交付产品之间的依赖关系 （5）跟踪基线中的需求状态需求管理原则 过程能力成熟度模型（CMM）是在软件开 发机构中被广泛用来指导软件过程改进。 该模型描述了软件处理能力的5个成熟度 级别。 为了达到过程能力成熟度模型的第二级， 组织机构必须具有6个关键过程域KPA（ Key Process Areas）。需求管理是其中 之一，它的目标是： （1）为软件需求建立一个基线，提供给软 件工程和管理使用。 （2）软件计划、产品和活动与软件需求 保持一致。 关于需求管理过程域内的原则和策略，可 以参考： （1）需求管理的关键过程领域不涉及收集 和分析项目需求，而是假定已收集了软件 需求或者已由更高一级的系统给定了需求 。一旦需求获得并且文档化了，软件开发 组和有关的团队（例如质量保证和测试组 ）需要评审文档。 （2）开发人员在向客户及有关部门承诺 （Commitment）某些需求之前，应该确 认需求和约束条件、风险、偶然因素、假 定条件等。 （3）关键处理领域同样建议通过版本控 制