需求分析是发、求精、建模、规格说明和复审的过程；需求.ppt

软件需求分析的几个阶段 问题分析 问题评估和方案综合 建模 规约 复审 需求获取 需求获取的目的 清楚地理解所要解决的问题 完整地获取用户需求 需求获取的内容 1.用户需求分类 (1)功能性需求: 定义了系统做什么（描述系统必须支持 的功能和过程） (2)非功能性需求（技术需求）: 定义了系统工作时的特性 （描述操作环境和性能目标） 两类需求包括的内容 (1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档 功能需求 系统做什么？ 系统何时做什么？ 系统何时及如何修改 或升级？ 性能需求 软件开发的技术性指标 例如： 存储容量限制 执行速度、相应时间 吞吐量 环境需求 硬件设备：机型、外设、接口、 地点、分布、温度、 湿度、磁场干扰等 软件： 操作系统 网络 数据库 界面需求 有来自其它系统的输入吗？ 到自其它系统的输出吗？ 对数据格式有规定吗？ 对数据存储介质有规定吗？ 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？ 文档需求 需哪些文档？ 文档针对哪些读者？ 数据需求 输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？ 资源需求 软件运行时所需的数据、软件。 内存空间等资源。 软件开发、维护所需的人力、 支撑软件、开发设备等。 安全保密要求 需对访问系统或系统信息加以控 制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序和操作 系统隔离？ 系统备份要求？ 软件成本消耗 与开发进度需求 开发有规定的时间表吗？ 软硬件投资有无限制？ 质量保证 系统的可靠性要求？ 系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？ 需求建模 建模的原因： 在建模过程中了解系统 通过抽象降低复杂性 有助于回忆所有的细节 有助于开发小组间的交流 有助于与用户的交流 为系统的维护提供文档 需求建模 模型化或模型方法是通过抽象、概括和一般化，把研究的对象或问题转化为本质（关系或结构）相同的另一对象或问题，从而加以解决的方法。 模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。 模型的类型 数学模型 描述模型 图形模型 需求分析过程示意 (1) 通过对现实环境的调查， 获得当前系统的物理模型 需求分析过程示意 (2) 去掉具体模型中的非本质因素， 抽象出当前系统的逻辑模型 需求分析过程示意 (3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型 分析阶段中常用的模型（逻辑模型） 数据流图（DFD） 实体―联系图（ ERD ） 类图 实例图 时序图 状态图 协作图 事件列表 数据流定义 数据元素定义 …… 状态图 例： §3.4 分析建摸方法 结构化分析(传统建模方法) 面向对象分析 §3.4.1 结构化分析方法 (Structured Analisys, SA) 基于数据流技术的分析方法 需求获取应遵循的三条基本原则： 分解 抽象 投影 分析模型的主要目标 描述用户需要 建立创建软件设计的基础 定义软件完成后可被确认的一组需求 分析模型的元素 数据字典(DD)：模型核心(中心库) E-R图(ERD)： 数据流图(DFD) 指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能; DFD中每个功能的描述包含在加工规约 (小说明)。 状态变迁图(STD) 指明作为外部事件的结果,系统将如何 动作。 3.4.3 数据建模 E-R图是数据建模的基础 讨论要点 SA方法建立功能模型的描述方法 DFD DD 其他描述方法 3.4.4 功能建模和信息流 一. 数据流图 (DFD，Data Flow Diagram) 描述逻辑模型的图形工具， 表示数据在系统内的变化。 实例 考务处理系统功能 (1)对考生送来的报名单进行检查; (2)对合格的报名