Lect4：可行性分析和需求分析.pptVIP

数据字典 * * 实现方法 人工 全自动化生成（利用数据字典处理程序） 混合过程（用正文编辑程序，报告生成程序等已有的实用程序帮助人工过程） 数据字典 * * 要求： 通过名字能方便地查阅数据的定义 没有冗余 尽量不重复在规格说明的其他组成部分中已经出现的信息 容易更新和修改 能单独处理描述每个数据元素的信息 定义的书写方法简单方便而且严格 需求分析维度空间 * * Performance Reliability Test that the application behaves consistently and predictably. Test the online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test application from the perspective of convenience to the end user. Supportability Test the ability to maintain and support the application under production use. 系统流程图 * * 注：符号 = 系统部件 箭头 = 信息流动路径 事务 库存清单程序 库存清单主文件 定货 信息 报告生成程序 定货报告 即库存量变化 系统流程图 * * 画法 习惯上信息在图中从顶向下或从左向右流动 可以在图上加注释，注释较多时，可以另外加一个文档来进行解释 复杂系统可以用分层方法来表示 首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能 每个关键功能扩展到适当的详细程度，画在单独的一页纸上 数据流图 * * 数据流图描绘系统的逻辑模型，图中无具体的物理元素，只是描绘信息在系统中流动和处理的情况 数据流图可以作为 计算机人员与客户之间的通信工具 软件设计的出发点 System = data + function 数据流图 * * 1、符号 input Data storage function Data flow output 数据流图 * * 数据流图 * * 注意点 数据流与程序流程图中用箭头表示的控制流有本质不同 在数据流图中应描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件 处理并不一定是一个程序，可以代表一系列程序、单个程序或者程序的一个模块，甚至人工处理过程 一个数据存储也并不一定是一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等等 数据流图 * * 通常在数据流图中忽略出错处理，也不包括如打开文件、关闭文件之类的内务处理 数据流图的要点是描绘“做什么”，而不是“怎么做” 数据流图 * * 重复元素的画法 有时数据的源点和终点相同 数据存储有时也要重复 ——为了表示方便，代表同一事物的同样符号在图中出现在n个地方，则在这个符号的一个角上画n-1条短斜线做标记 数据流图 * * 命名 为数据流（或数据存储）命名 名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分 不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类） 如果在为某个数据流（或数据存储）起名字时遇到了困难，则可能是因为数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难 数据流图 * * 为处理命名 通常先为数据流命名，然后再为与之相关联的处理命名 名字应该反映整个处理的功能，而不是一部分 名字最好由一个具体的及物动词，再加上一个具体的宾语构成 通常名字中仅包括一个动词，如果必须用两个动词才能描述清楚，可能分成两个处理更恰当 如果再为某个处理命名时遇到困难，则可能是发现了分解不当的迹象，应该重新分解 数据源点/终点是目标系统的外围环境，采用它们在问题域中习惯使用的名字（如“采购员”，“仓库管理员”等） 数据流图 * * 为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统 数据流图 * * 数据流图 * * 在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 底