3.需求分析.pptVIP

电子与信息工程学院 计算机系 软件工程 第 3 章 需求分析 3.1 需求分析的准则和任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 图形工具 3.6 验证软件需求 3.5 需求规格说明书 本章重点： 需求分析的任务 图形工具 需求规格说明书 难点： 数据流图（DFD）的画法和数据字典（DD）的写法 3.1 需求分析的准则和任务 3.1.1 需求分析的准则 1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 2. 必须定义软件应完成的功能，这条准则要求建立功能模型。 3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 4. 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 3.1.2 需求分析的任务 1. 确定对系统的综合要求 1.功能要求 2.性能要求 3.可靠性和可用性要求 4.出错处理要求 5.接口要求 6.约束 7.逆向要求 8.将来可能提出的要求 2. 分析系统的数据要求 3. 导出系统的逻辑模型 4. 修正系统开发计划 3.2 与用户沟通获取需求的方法 3.2.1 访谈 3.2.2 面向数据流自顶向下求精 3.2.3 简易的应用规格说明技术 3.2.4 快速建立软件原型 方法和工具： （1）第四代技术 （2）可重用的软件构件 （3）形式化规格说明和原型环境 3.3 分析建模与规格说明 3.3.1 分析建模 1.模型：是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常由一组图形符号和组织这些符号的规则组成。 2.需求分析过程应建立的模型： 数据模型：实体－联系图（E-R图） 功能模型：数据流图（DFD） 行为模型：状态转换图 3.3.2 软件需求规格说明 通常用自然语言完整、准确、具体地描述系统的数据要求、功能要求、性能要求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。 3.4 图形工具 3.4.1 数据流图（DFD） Data Flow Diagram 数据流图描绘系统的逻辑模型,图中没有任何具体的物理元素,只是描述信息在系统中流动和处理的情况. 设计数据流图只需考虑系统必须完成的基本逻辑功能(做什么),完全不需要考虑如何具体地实现这些功能(怎么做). 数据的源点/终点 数据处理 数据存储 数据流 或 或 或 1. 符号 2. 实例 3. 命名 （1）为数据流（或数据存储）命名 a. 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。 b. 不要使用空洞的、缺乏具体含义的名字。 c . 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。 （2）为处理命名 a. 通常先为数据流命名，然后再为与之相关联的处理命名。 b. 名字应该反映整个处理的功能，而不是它的一部分功能。 c. 名字最好由一个具体的及物动词加上一个具体的宾语组成。 d. 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 e. 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。 4. 用途 （1）作为交流信息的工具 （2）作为分析和设计的工具 3.4.2 数据字典（DD） Data Dictionary 1. 数据字典的定义 数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。 2. 数据字典的内容 （1）数据流 （2）数据流分量（数据元素） （3）数据存储 （4）处理 （5）外部项 3. 数据字典的用途 （1）数据定义 （2）保持数据一致性 （3）数据库设计的依据 4. 数据字典与数据流图的关系 数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，没有数据流图数据字典也难于发挥作用。只有数据流图和数据字典中每个元素的精确定义放在一起，才能共同构成系统的规格说明。 5. 定义数据的方法 自顶向下分解 组成数据的方式： 顺序 选择 重复 可选 使用的符号： = +