Download
1 / 64
640 likes | 772 Views
软件工程. 第三 章 需求分析. 第三章 软件需求分析. 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 2.4 数据流图 2.5 数据字典 3.4 常用的动态分析方法 3.5 数据及数据库需求 3.6 数据规范化 3.7 其他图形工具 3.8 验证软件需求 3.9 小结. 教学要求. 教学目的： 了解需求分析的任务和步骤、评审标准和过程；掌握基本技术，理解需求规格说明书的作用与组成。 教学重点： 基本技术、需求规格说明书的作用与组成。 教学难点： 基本需求分析技术。.
E N D
软件工程 第三章 需求分析
第三章 软件需求分析 • 3.1 需求分析的任务 • 3.2 与用户沟通获取需求的方法 • 3.3 分析建模与规格说明 • 2.4 数据流图 2.5 数据字典 • 3.4 常用的动态分析方法 • 3.5 数据及数据库需求 • 3.6 数据规范化 • 3.7 其他图形工具 • 3.8 验证软件需求 • 3.9 小结
教学要求 教学目的：了解需求分析的任务和步骤、评审标准和过程；掌握基本技术，理解需求规格说明书的作用与组成。 教学重点：基本技术、需求规格说明书的作用与组成。 教学难点：基本需求分析技术。
需求分折简介 软件需求指用户对所开发的软件在功能、性能、环境、可靠性等各方面的要求。 需求分析主要回答待开发的系统必须“做什么”，并用 《 需求规格说明书 》 的形式准确、详细、规范地表达出来。四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
需求分折简介 需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 。 Boehm 给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。 “需求、设计、编程、测试四者究竟哪个环节最重要？” • 首先，每个环节都是很重要，任何一个环节出现问题，都会导致软件的质量问题。 • 但是，从风险管理的角度来看，需求是软件产品的起源，因而是最重要的一个环节。
3.1 需求分析的任务 需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用： • 它使得软件开发人员在可行性分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。 • 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。 • 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。 • 它能准确表达用户对系统的各项要求。
3.1 需求分析的任务 软件需求分析的对象是用户要求。 其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。 软件开发的目标 需求分析的目标
3.1 需求分析的任务 （1）获得当前系统的物理模型：分析、理解当前系统（人工处理或原计算机系统）是如何运行的，了解其组织机构、输入输出、资源利用情况和日常数据处理过程 。 （2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质 。 （3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，进而从当前系统的逻辑模型导出目标系统的逻辑模型。 （4）对逻辑模型的补充 ：包括说明目标系统的用户界面 、系统细节和性能限制等。
3.1.1 确定对系统的综合要求 1. 功能需求 指定系统必须提供的服务，划分出系统必须完成的所有功能。 2. 性能需求 指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 3. 可靠性和可用性需求
3.1.1 确定对系统的综合要求 4. 出错处理需求 当应用系统发现它自己犯下一个错误时所采取的行动。但是，仅限于对系统的关键部分有选择地提出这类出错处理需求。 5. 接口需求 描述应用系统与它的环境通信的格式。 常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
3.1.1 确定对系统的综合要求 6. 约束 描述在设计或实现应用系统时应遵守的限制条件。 常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 7. 逆向需求 说明软件系统不应该做什么。 用于澄清真实需求，消除可能发生的误解的那些逆向需求。 8. 将来可能提出的要求 对系统将来可能的扩充和修改预做准备。
3.1.2 需求分析的过程 (1) 问题识别 • 从系统的角度来理解软件并评审软件范围（功能要求）是否恰当 • 确定对目标系统的综合要求，即软件的需求（区别用户要求） • 提出这些需求实现条件，以及需求应达到的标准
3.1.2 需求分析的过程 (2) 分析与综合 • 从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
3.1.2 需求分析的过程 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 (OOA) 等
3.1.2 需求分析的过程 (3) 编制需求分析阶段的文档 • 软件需求说明书 • 数据要求说明书 • 初步的用户手册 • 修改、完善与确定软件开发实施计划
3.1.2 需求分析的过程 (4) 需求分析评审 • 系统定义目标是否与用户的要求一致; • 系统需求分析阶段提供的文档资料是否齐全; • 文档中的所有描述是否完整、清晰、准确反映用户要求; • 与所有其它系统成分的重要接口是否都已经描述;
3.1.2 需求分析的过程 • 被开发项目的数据流与数据结构是否足够，确定; • 所有图表是否清楚，在不补充说明时能否理解; • 主要功能是否已包括在规定的软件范围之内，是否都已充分说明; • 设计的约束条件或限制条件是否符合实际; • 开发的技术风险是什么;
3.1.2分析系统的数据要求 需求分析流程
3.1.3 软件需求分析的原则 • 需要能够表达和理解问题的信息域和功能域 • 要能以层次化的方式对问题进行分解和不断细化 • 要给出系统的逻辑视图和物理视图
从现实中分离功能，即描述要“做什么”而不是“怎样实现”从现实中分离功能，即描述要“做什么”而不是“怎样实现” • 要求使用面向处理的规格说明语言（或称系统定义语言） • 如果被开发软件是大系统（环境）中的一个元素，那么整个大系统也包括在规格说明的描述之中
规格说明必须包括系统运行环境 • 规格说明必须是一个认识模型 • 规格说明必须是可操作的 • 规格说明必须容许不完备性并允许扩充 • 规格说明必须局部化和松散耦合
3.1.4 导出系统的逻辑模型 用数据流图、实体一联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。 3.1.5 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
图:软件需求分析的通信途径 • 分析小组成员主要包括领域专家、系统分析员； • 客户访谈 • 问题分析与确认
3.2 与用户沟通获取需求的方法 3.2.1 访谈 3.2.2 面向数据流自顶向下求精 3.2.3 简易的应用规格说明技术 3.2.4 快速建立软件原型
3.2.1 访谈 • 正式 • 非正式 • 调查表 • 情景分析技术
3.2.2 面向数据流自顶向下求精 结构化分析方法的实质。 进一步细化可行性研究阶段获得到高层数据流图。包括建立： • 详细的数据流图，描绘数据在软件系统内从输入移动到输出的过程中所经受到变换； • 数据字典：定义数据流图中包含的元素； • 实体关系（ ER ）图：从用户角度描述数据； • IPO 图：描述数据流图中处理框的功能和算法。
3.2.2 面向数据流自顶向下求精 复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。 追踪更详细的数据流，把数据流图扩展到更低的层次。通过功能分解完成数据流图的细化。 在分析追踪时可能产生新的问题，这些问题的答案可能又在数据字典中增加一些新条目，或产生新的或精化的算法描述。 最终得到对系统数据和功能要求的满意了解。
3.2.3 简易的应用规格说明技术 一种面向团队的需求收集法，提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 具体过程见教材 P60 面 提问：此方法将产生什么样的产品？
3.2.4 快速建立软件原型 快速原形就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 要点： 实现用户看得见的功能，省略目标系统“隐含”功能。
3.2.4 快速建立软件原型 建立和修改原型的方法和工具： (1)第四代技术。包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。能快速生成可执行的代码。 (2)可重用的软件构件。使用一组已有的软件构件（也称为组件）来装配（而不是从头构造）原型。 (3)形式化规格说明和原型环境。在交互式环境下，用自动工具把基于形式语言的规格说明翻译成可执行的程序代码。
3.3 分析建模与规格说明 什么是模型？ 为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。 模型通常由一组图形符号和组织这些符号的规则组成。 根据结构化分析准则，需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型。
3.3.1 结构化分析方法 结构化分析方法（ Structured Analysis , SA）是面向数据流进行分析的方法，适合于数据处理类型软件的需求分析，主要建立以下几种模型： • 数据流图（Data Flow Diagram,DFD） ：用来创建功能模型，描述信息流和数据转换（处理） • 状态转换图 （State-Transition Diagram,STD）用来创建行为模型，描述系统状态如何响应外部事件，而进行转换。 • 实体关系图(Entity-Relationship Diagram,E-R图)来创建数据模型，描述系统中所有重要的数据对象；
面向对象分祈方法（OOA）建立的摸型 对象模型(Object model)：定义实体，描述系统的静态结构，定义“对谁做” 动态模型(Dynamic model):描述对象之间的交互过程，规定“何时做” 功能模型作 (Functional model) ：描述内部数据的处理，指明系统应“做什么”
3.3.1 结构化分析方法 结构化分析方法使用工具： • (2.4)数据流图 • 数据词典 • 结构化英语 • 判定表与判定树
2.4 数据流图(DFD,Data Flow Diagram) 数据流图(DFD)是系统逻辑功能的图形表示，是一种图形化技术，描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。 在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件（无法表示分支条件或循环）描述数据处理过程的工具。
2 .4.1 符号 数据流图中的主要图形元素 外部实体 数据变换
2 .4.1 符号 数据加工（处理）可以代表单个或系列程序或者程序的一个模块或人工处理过程。 数据存储也并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等；数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上。 数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。
数据流与数据加工之间的关系 4 1 5 2 6 3
应该注意的几个问题 “数据存储”代表数据静止状态， “数据流”代表数据的运动状态； 数据流与控制流的区别； 通常数据流图中忽略出错处理、打开或关闭文件之类的内务处理。 若数据的源点和终点相同，则应该有两个箭头和这个数据源（终）点相连；或重复画一个源（终）点。
2.4.2 命名 数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。 1. 数据流(或数据存储)命名 (1)名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。 (2) 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”等)。 (3) 无法命名时，考虑对数据流图的重新分解。
2.4.2 命名 2. 处理命名 (1)通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。 (2)名字应该反映整个处理的功能，而不是它的一部分功能。 (3)名字最好由动宾结构组成，尽量避免使用“加工”、“处理”等空洞动词作名字。
2.4.2 命名 (4)通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 (5)如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。 数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”等)。
2.4.3 数据流图的层次结构 对于大型系统，往往采用自顶向下逐层分解的方法，用分层数据流图表示所有数据流和加工。 对任何一个数据流图来说，它的上层图为父图，在它的下一层的图为子图。
说明： • 在多层数据流图中，顶层流图仅包含一个数据处理，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 • 中间层流图则表示对其上层父图的细化。它的每一数据处理可能继续细化，形成子图。 • 底层流图是指其数据处理不需再做分解的数据流图，它处在最底层。
检查和修改数据流图的原则 • 数据流图上所有图形符号只限于前述四种基本图形元素 • 数据流图的主图必须包括前述四种基本元素，缺一不可 • 数据流图的主图上的数据流必须封闭在外部实体之间 • 每个加工至少有一个输入数据流和一个输出数据流
检查和修改数据流图的原则 • 在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系 • 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡 • 可以在数据流图中加入物质流，帮助用户理解数据流图
