1、1,需求的相关概念问题域：现实世界中系统处理的业务范围。 系统责任：所开发的系统应该具备的职能。 系统边界：开发出的系统和与该系统打交道的人或物之间的明确边界。,2,涉及人员 需求者：客户和使用者 系统分析员：分析阶段活动的主体 开发者：包括设计，编程和项目管理者组成 分析员的素质： 能力(总体，抽象，本质) 过程(保证整个过程的善始善终) 交流 技术(了解问题域),3,需求阶段的工作获取 (1)需求获取 目的：了解用户的对软件的要求 途径： 了解系统的需求 市场调查 访问用户和领域专家 考察现场,4,内容： 物理环境 界面 用户或人的因素 功能 文档 数据 资源 安全性 质量,5,(2)需求
2、获取的困难 误解 交流障碍 缺乏共同语言 完整性问题 需求永远不会稳定 用户意见不统一 错误的需求 认识混淆,6,需求阶段的工作分析 目的：解决需求获取阶段得到的需求的不一致性和二义性 方法： 结构化(SA、SD) 面向对象(OOA、OOD) 实体关系(ER Method) Etc.,7,需求分析的任务与步骤,需求分析关系到软件系统开发的成败，是决定软件产品质量的关键，只有通过需求分析才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。,8,需求分析的任务,用户和开发者共同明确将要开发的是一个什么样的系统。 通过对问题及其环境的理解、分析和综合，建立分析模型（A
3、nalysis Model）; 在完全弄清用户对软件系统的确切要求的基础上，用“软件需求规格说明书”把用户的需求表达出来。,9,1. 建立分析模型,分析模型 定义：描述软件需求的一组模型。 作用 精确记录用户对原始问题和目标软件的描述； 帮助分析人员发现用户需求中的不一致性，排除不合理的部分，挖掘潜在的用户需求。,10,需求分析的实现步骤,理解需求表达需求,获得当前系统的物理模型：物理模型是对当前系统的真实写照； 抽象出当前系统的逻辑模型：去掉一些次要的信息，建立起反映系统本质 的逻辑模型； 建立目标系统的逻辑模型：分析目标系统与当前系统在逻辑上的差别，建 立符合用户需求的目标系统的逻辑模型；
4、 补充目标系统的逻辑模型：对目标系统进行补充、完善。,11,2. 编写需求说明,“需求说明”的要求 准确性和一致性 清晰性和没有二义性 直观、易读和易于修改,12,3.1.2 需求分析的步骤,需求获取 需求提炼：分析建模 需求描述：编写SRS 需求验证,13,1.需求获取,双方确定问题的综合需求。 这些需求包括 功能需求（最主要的需求） 性能需求 环境需求 用户界面需求 可靠性、安全性、保密性、可移植性、可维护性等。,14,2. 需求提炼：分析建模,任务：建立分析模型。 常用模型 数据流图 实体关系图 控制流图 状态转换图 用例图 类对象关系及其行为图,15,3. 需求描述：编写SRS,主要内
5、容 描述目标系统的概貌、功能要求、性能要求、运行要求和将来可能提出的要求。 组成部分 在分析过程中得出的数据流图 简要描述的系统主要算法 用户需求和系统功能之间的参照关系 设计约束等等 必须用统一的文档进行描述,16,4. 需求验证,作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性以及其他需求给予评价。,17,教材销售的需求分析过程,1. 通过对现实环境的调查研究，获取当前系统的 具体模型。,图1 学生购买教材的具体模型,18,2. 分析需求，建立系统分析模型。 去掉具体模型中的非本质因素，提炼出当前系统的逻辑模型；,图2 学生购买教材的逻辑模型,关注系统的功能，而不是执行功
6、能的人或机构,19,分析当前系统与目标系统的差别，建立目标系统的逻辑模型。,图3 计算机售书系统的逻辑模型,20,3. 整理综合需求，编写系统需求说明； 4. 验证需求，完善和补充对目标系统地描述。 通过目标系统的人-机界面，和用户一起确认目标系统功能； 复审需求说明，补充迄今尚未考虑过的细节。,图4 改进了的计算机售书系统,21,3.2.1 常规的需求获取方法,系统分析员 负责需求分析的软件开发人员 系统分析员可以使用的需求获取方法和技术 联合分析小组 用户代表、领域专家和系统分析员 客户访谈 充分准备，寻找共同语言 循序渐进、逐步逼近 问题分析与确认 多个来回,22,3.3.1 两种分析模
7、型,结构化分析模型 面向对象分析模型,23,DD（数据字典）：系统所涉及的各种数据对象的描述。 E-R图（实体-联系图）：描述数据对象间的关系，它代表软件的数据模型。 DFD（数据流图）：指明系统中数据是如何流动和变换的。 STD（状态-变迁图）：用于指明系统在外部事件的变化下将会如何动作，表明系统的各种状态以及各种状态间的变迁。,1. 结构化分析模型,24,1. 数据流图（DFD）,组成符号 圆框-代表加工； 箭头-代表数据的流向，数据名称标在箭头的边上； 方框(或立方体) -表示数据的源点和终点； 双杠（或单杠）-表示数据文件或数据库。注意：每个图形符号都必须标上名字，加工框应加上编号。,
8、加工名,实体名,25,输出(B)、(C)、(B和C)三种可能,输出(B)、(C) 之一,输出(B和C),附加符号：*(与) 、+(或与) 、(或),26,例：将图4改画成DFD图。,图4,图4的DFD图,27,(1) DFD中的箭头仅表示系统中数据的流动，不表示实物，为代表实物的信息。(2) DFD不能表示程序的控制结构，不包含“控制流”、“控制结构”、“激发条件”之类的信息。(3) DFD表现范围具有很大的灵活性，常用一组DFD由粗到细表示一软件在不同抽象级别上的逻辑性质。,DFD的性质,28,DFD的性质-数据流图与程序流程图的比较,数据流图 用作软件分析阶段的工具 从数据的角度描述一个系
9、统 图中的箭头是数据流 程序流程图 表示程序的过程设计 从对数据进行加工的工作人员的角度描述一个系统 图中的箭头是控制流，表达的是程序执行的次序,29,2. 数据字典(DD),定义（作用） DFD中所有元素的定义的集合. 用途 分析阶段的交流工具 包含控制信息 数据库设计的基础 基本内容 名字：描述对象的主要名称； 别名：第一项中对象的其他名字； 内容描述：描述对象内容的符号； 补充信息：关于数据类型、预置值、限制等的其他信息。,30,软件中的数据类别 只含一个数据的数据项（或数据元素）； 由多个相关数据项组成的数据流； 数据文件或数据库。,31,各类数据的字典条目,数据流条目 给出一个数据流
10、定义方法，通常是列出该数据流的各个数据项。,例3.3：为图3.8中的数据流“发票”编写字典条目,32,注： 对较长或复杂的数据流可用分层次描述发票= (学号)+姓名+发票行+书费合计发票行=书号+单价+数量+总价 不允许同一个数据在系统中使用不同的名字,33,数据文件条目 给出文件的定义，通常是列出记录组成数据项和文件的组织。也可以列出数据文件或数据库(表单)的结构。,例3.4：数据文件“各班学生用书表”的字典条目,34,数据项条目 包含在数据流或文件中的数据项（数据元素），如果某数据项是很明显的，不会产生二义性，则允许不单独编写数据项条目。 一般包括数据项名、别名、取值、备注。,例3.5：数
11、据项字典条目示例 年级：属于数据文件“各班学生用书表”； 数量：属于数据流“发票”； 书费合计：属于数据流“发票。”,35,数据项“年级”的字典条目,36,数据项“数量”的字典条目,数据项“书费合计”的字典条目,37,数据字典的实现1.表示形式卡片式：适用于三种字典条目，一般应用于数据项。符号式：一般应用于数据流和数据存储。2.数据字典的管理形式计算机自动或人工方法,38,数据字典定义中常用的符号,“=” 定义符号，表示对名字的定义； “+” 与符号，表示由几个数据项组成，即连接两分量； “” 选择符号，表示括号中内容可任意选取一个项； “” 重复符号，表示括号中的内容可重复使用零次或多次；
12、“()” 可选符号，表示括号中的内容可以由设计者确定取舍； “*” 注释符，表示两个*号之间的内容为对条目的注释,39,3. 加工说明(PSPEC),加工说明 对DFD中的每个加工所作的说明。由输入数据、加工逻辑和输出数据等部分组成。 加工逻辑 阐明把输入数据转换为输出数据的策略，是加工说明的主体。 描述工具 结构化语言 判定表 判定树,40,结构化语言 是一种介于自然语言与程序设计语言之间的语言，既具有结构化程序的清晰易读的优点，又具有自然语言的灵活性。 可使用顺序、选择、循环等控制结构，形式简洁，易于理解。,判定表或判定树 采用表格的方式，适用于表达含有复杂判断的加工逻辑。 若在加工逻辑中
13、存在顺序、选择、循环3种结构，则不宜单独使用判定表。,41,3.5 结构化分析方法,T.DeMarco的定义 使用DFD、DD、结构化语言、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档。 是一种面向数据流的分析方法。 基本步骤 由顶向下对系统进行功能分解，画出分层DFD图； 由后向前定义系统的数据和加工，编制DD和PSPEC； 写出SRS.,42,3.5.1 画分层数据流图,由顶向下，逐步细化 从系统的基本模型开始，逐层的对系统进行分解 每分解一次系统的加工数量就增多一些，每个加工的功能也更具体一些。 继续重复这种分解，直到所有的加工都足够简单，不必再进行分解为止。 原则：
14、先全局后局部，先整体后细节，先抽象后具体,43,分层的数据流图,44,在多层数据流图中 顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据； 底层流图是指其加工不需再做分解的数据流图，它处在最底层； 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,首先要注意抽取数据流图的四种成分：源点/终点、处理、数据存储和数据流,45,参考原则 一个加工每次分解得到的子加工数最多不要超过7个。 分解要自然，概念上要合理、清晰。 只要不影响数据流图的易理解性，可适当地多分解成几部分，以减少分解图的层数。 一般在上层可分解得快些，而在中、下层
15、应分解得慢些。,46,例3.14 用结构化分析方法为教材 购销系统画出分层的DFD图,图3.34 教材购销系统的顶层DFD,47,图3.35 教材购销系统的第二层DFD,48,分层DFD的优点,便于实现 逐步细化的扩展方法有利于控制问题的复杂度 便于使用 用一组图代替一张总图，用户可以各取所需。,49,3.5.2 确定数据定义与加工策略,分层DFD图为系统描绘了一个概貌，下一步需要考虑系统的细节问题，即定义系统的数据、确定加工的策略等问题。 应从数据的终点开始，因为最底层DFD图包含了系统的全部数据和加工。,50,综上，分层DFD图产生了系统的全部数据和加工，通过对这些数据和加工的定义，常常对
16、分析员提出了一些新问题，促使其进行新的调查研究，并可能导致对DFD的修改。画DFD，定义加工和数据，再画，再定义，形成一个循环的过程，直至产生一个为用户和分析员一致认可的文档-需求规格说明书。,51,3.5.3 需求分析的复审,复审重点 文档的完整性、易改性和易读性； 尽可能多发现和改正文档中存在的矛盾、冗余和遗漏。 参与人员 用户 系统分析员 系统设计员,52,分层DFD中易出现的问题 父图和子图不平衡 未区分局部文件和局部外部项 分解的速度太快 不遵守加工编号规则,53,父图和子图不平衡,父子平衡-父图和子图的输入数据和输出数据分别保持一致。 特殊情况 出错信息处理在低层考虑 数据流满足某
17、些关系 例如,发票 = 学生 + 教材,54,未区分局部文件和局部外部项,规则 除底层DFD需画出全部文件外，各中间层的DFD仅显示处于加工之间的接口文件，其余文件均不必画出。,55,分解的速度太快,逐步细化 上层分解快一些，下层应慢一些 同一图中的各个加工，分解速度应大致均匀，保持同步扩展。 每一加工每次可分为24个子加工，最多不超过7个。,56,不遵守加工编号规则,加工的编号规则 顶层加工不编号； 第二层的加工编号为1、2、3、N号； 第三层为1.1、1.2、1.3、N.1、N.2、N.3号。 各层DFD的编号规则 顶层DFD图无图号； 第二层编为“图0”； 第三层编为“图1”直至“图n”。,57,画DFD的4步骤 1、抽取数据流图的四种成分：源点或终点、处理、数据存储和数据流。 2、绘制基本系统模型顶层数据流图，基本系统模型 3、细化基本系统模型，描绘系统的主要功能功能级数据流图在图中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。 4、对功能级数据流图中描绘的系统主要功能进一步细化模块级数据流图,
