04、软件需求分析(北邮课件).pptVIP

软件工程模型与方法  Models Methods of Software Engineering 第四章 软件需求分析 修佳鹏 media@bupt.edu.cn 本章内容 4.1 什么是软件的需求 4.2 软件需求分析的目标和任务 4.3 软件需求分析建模的原则和方法 4.4 软件需求工程 4.5 软件需求分析过程 本章目标 为何要进行软件的需求分析？ 软件的需求分析处于软件生命周期的那个阶段？起到什么作用？ 怎样才能做好软件需求分析？ 软件需求分析的过程和步骤是什么？ 软件需求分析的最终结果是什么？ 4.1 什么是软件的需求 4.1.1 需求的定义 4.1.2 需求分析失败案例 4.1.1 需求的定义 需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 。 Boehm 给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。 “需求、设计、编程、测试四者究竟哪个环节最重要？” 首先，每个环节都是很重要，任何一个环节出现问题，都会导致软件的质量问题。 但是，从风险管理的角度来看，需求是软件产品的起源，因而是最重要的一个环节。 4.1.2 需求分析失败案例 某大型的电信设备供应商，案例中涉及6个部门A,B,C,D,E和F，它们之间的关系如下图所示： 4.1.2 需求分析失败案例 A觉得机会难得，于是向C申请立项。 立项后，A把项目外包给专业做网管软件的公司E，期望半年内完成。 由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。 B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。 4.1.2 需求分析失败案例 祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。” A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策，设法把事情搞定。 大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。 4.2 软件需求分析的目标和任务 需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用： 它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。 它能准确表达用户对系统的各项要求。 4.2 软件需求分析的目标和任务 软件需求分析的对象是用户要求。 其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。 作为目标系统的参考，需求分析的任务就是借助于（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。 4.2 软件需求分析的目标和任务 （1）获得当前系统的物理模型：分析、理解当前系统（人工处理或原计算机系统）是如何运行的，了解其组织机构、输入输出、资源利用情况和日常数据处理过程 。 （2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质 。 （3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，进而从当前系统的逻辑模型导出目标系统的逻辑模型。 （4）对逻辑模型的补充 ：包括说明目标系统的用户界面 、系统细节和性能限制等。 4.3 需求分析建模的原则和方法 4.3.1 数据建模 4.3.2 功能和行为建模 4.3.3 问题划分 需求分析的三元模型 需求分析方法的一组操作性原则是： 问题的信息域必须被表示和理解。 软件将完成的功能必须被定义。 软件的行为（作为外部事件的结果）必须被表示。 描述信息、功能和行为的模型必须被划分，使得可以用层次的方式揭示细节。 分析过程应该遵从自顶向下，逐层细化的原则。 需求分析的三元模型： 数据模型——第1条原则 功能模型——第2条原则 行为模型——第3条原则 需求工程的指导性原则 首先要正确地理解问题，再建立分析模型。 记录每个需求的起源及原因，保证需求的可回溯性。 开发一个能使用户能够了解人机交互过程的原型。因为对软件质量的感觉经常基于对界面“友好性”的感觉。 使用多个需求视图。建立数据模型、功能模型和行为模型，为软件工程师提供三种不同的视图，增加识别不一致性的基础。 给需求赋予优先级。紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。 努力删除歧义性。因