第三篇 需求分析(结构化分析).pptVIP

第三章 需求分析（结构化分析） 3.1需求分析概述 对目标系统提出完整、准确、清晰和具体的要求 结果：写出需求规格说明书 参加人员 用户 知道需求 表述可能不完全 分析员 不清楚需求----逐渐明确需求----描述出来 3.1需求分析的任务 1，明确对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理需求 接口需求 约束 逆向需求 将来可能提出的需求 3.1需求分析概述 需求包括 (1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档 (7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (11)质量保证 3.1需求分析概述 3.1需求分析概述 准则 理解并描述问题的信息域------------数据模型 定义软件应完成的功能--------------功能模型 描述作为外部事件结果的软件行为----行为模型 对信息、功能、行为等模型进行分解，用层次的方式展现细节 3.1需求分析概述 获取需求 分析系统的数据 建立数据字典 导出系统的逻辑模型 修正系统开发计划 反复求精 验证需求说明 3.1需求分析概述 结构化分析（工具 DFD,PSPEC)—分析模型（分层DFD）+SRS 结构化设计（工具 SC图）--初始设计模型（初始SC图）---最终设计模型（最终SC图） 3.2与用户沟通获取需求的方法 访谈 正式的：事先准备好一些具体问题 非正式： 调查问卷 情景分析 3.2与用户沟通获取需求的方法 3.2与用户沟通获取需求的方法 3.2与用户沟通获取需求的方法 简易的应用规格说明 与用户合作，共同标识问题，提出解决方案 步骤 这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求。今天，简易的应用规格说明技术已经成为信息系统界使用的主流技术。 尽管存在许多不同的简易应用规格说明方法，但是它们遵循的基本准则是相同的。 在中立地点举行由开发者和用户双方出席的会议。 制定准备会议和参加会议的规则。 3.2与用户沟通获取需求的方法 提出一个议事日程，这个日程应该足够正式以便能够涵盖所有要点，同时这个日程又应该足够非正式，以便鼓励自由思维。 由一个“协调人”来主持会议，他既可以是用户也可以是开发者还可以是从外面请来的人。 使用一种“定义机制”(如，工作表、图表等)。 目标是标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求。 3.2与用户沟通获取需求的方法 快速建立原型 快速 易于修改 修改-试用-反馈 3.3 分析建模 模型有一组图形符号和组织符号的规则组成 结构化分析的本质是创建模型的过程 3.3 分析建模 3.3.1功能模型 3.3.1功能模型 3.3.1功能模型 举例1:某高校向学生销售教材的手续是: 先由系办公室张秘书开一张购书证明 学生凭证明到教材科王会计处开购书发票 到李出纳处交书款 到书库赵保管员出领书 3.3.1功能模型 当前系统的物理模型 学生购买教材的实际处理流程—当前系统物理模型 3.3.1功能模型 去掉具体模型中的非本质因素， 抽取现实系统的实质，抽象出当前系统的逻辑模型 学生购买教材的逻辑模型 3.3.1功能模型 3.3.1功能模型 成立综合需求，编写需求规格说明书 3.3.1功能模型 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型 计算机教材管理系统的逻辑模型 3.3.1功能模型 数据流图 3.3.1功能模型 举例2:假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。 3.3.1功能模型 3.3.1功能模型 3.3.1功能模型 3.3.1功能模型 DFD的性质 (1) DFD中的箭头仅表示系统中数据的流动，不表示实物，为代表实物的信息。 (2) DFD不能表示程序的控制结构，不包含“控制流”、“控制结构”、“激发条件”之类的信息。 (3) DFD表现范围具有很大的灵活性，常用一组DFD由粗到细表示一软件在不同抽象级别上的逻辑性质。 数据流图 用作软件分析阶段的工具 从数据的角度描述一个系统 图中的箭头是数据流 程序流程图 表示程序的过程设计 从对数据进行加工的工作人员的角度描述一个系统 图中的箭头是控制流，表达的是程序执行的次序 3.3.1功能模型 命名(P38) 1. 为数据流(或数据存储)命名 2. 为处理命名 3.3.1功能模型 3.3