软件工程第3章需求分析PPT课件

• 需求分析的任务
就是借助于当前系统的逻辑模 型导出目标系统的逻辑模型，解决 目标系统的 “做什么” 的问题。
需求分析做什么? Is What
Not How
• 准确地回答”系统必须做什么?”这个问题；
• 对系统提出完整、准确、清晰、具体的要求； • 写出软件需求规格说明书； • 用户要很好地参与到需求分析过程中来；(需
面向数据流方法的分析过程
3.2.1 访谈
• 情景分析 (1) 它在某种程度上演示目标系统的行为，便
于用户理解，而且还可能进一步揭示出一些 分析员还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这 种技术能保证用户在需求分析过程中始终扮 演一个积极主动的角色。
可行性
3.2.2 面向数据流的分析自忽 顶向下求精 略了细 节
• 信息系统的本质决定数据是需求分析的起 点
• 系统分析员一定要搞清楚数据的细节
• 分析的对象：高层数据流图（什么阶段得 到的？）
• 主要目标：把数据流和数据存储定义到元
素级别（不可分解为止）
数据的来源、去 向、数据结构定
义等
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
• 结构化分析方法是一种什么方法呢？
求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，
这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行
分解，用层次的方式展示细节。
需求获取面临的挑战
客户说不清楚需求 需求易变性 问题的复杂性和对问题空间 理解的不完备性与不一致性
Baidu Nhomakorabea 优秀需求具有的特性
• 1. 完整性 • 2. 正确性 • 3. 可行性 • 4. 必要性 • 5. 划分优先级 • 6. 无二义性 • 7. 可验证性
• 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。
• 输出数据决定了系统必须具有的最基本的组
成元素（包括功能和数据结构组成）。
3.2.2 面向数据流的自顶向下求精
• 注意1：第2章给出了1种数据流图的分析方 法（教材），其目的主要是导出较高层次 较粗糙的数据流图，而需要准确地收集需 求，采用本章的从数据流图的输出向输入 的回溯方法。
3.1 需求分析的任务
具体任务：
– 确定对系统的综合要求（系统需要什么？） – 分析和设计系统的数据要求 （处理的数据对象
是什么？） – 在可行性分析的基础之上分析和设计系统的功
能模型（系统功能的模型表示是什么？） – 分析和设计描述软件动态变化的行为模型（系
统的状态是如何改变的？） – 编写软件需求规格说明书，可能需要修正系统
• 简易的应用规格说明技术 • 快速原型法
用户和系统其他人员参与需求分析
3.2.1 访谈
• 最早并且仍然广泛使用 • 正式的访谈：具体问题的问答形式 • 非正式的访谈：开放式、交互性的问答 • 需要调查大量人员有时采用“调查表”技术 • 还使用“情景分析技术”（用户角度）,就是
对用户将来使用目标系统解决某个具体问题 的方法和结果进行分析。
3.2.2 面向数据流的自顶向下求精
• 回溯过程中需要回答两个问题
– 输出数据的组成？
深入调查
– 输出数据的来源？
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题：为了得到某个数据元素需要 用到数据流图中还没有的数据元素，或者得出这个 数据元素要用的算法尚不完全清楚。
• 因此，需要向用户等有关人员请教，他们的回答使 分析员对目标系统的认识更深入具体，系统中更多 的数据元素被划分出来，更多的算法搞清楚了。
• 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
• 确定系统综合要求和分析系统数据要求顺 利完成之后即可导出详细的系统功能模型。
• 阶段性成果：
– 细化后并经过多次校验的数据流图(DFD) – 与数据流图相辅相存的数据字典(DD) – 概要性的描述主要加工的处理算法(IPO)
3.1.4 分析和设计系统的行为模型
• 确定系统的动态变化的方式，采用状态转 换图来描述。
• 阶段性成果：
– 状态转换图(STD)
3.1.5 编写需求规格说明，可能需要修正 系统的开发计划
• 根据上述的阶段性成果，汇总为“软件需 求规格说明书”，以提交评审
• 在可行性分析的基础上，较准确地估计系 统的开发成本和进度
• 修正开发计划
3.2 与用户沟通获取需求的方法
• 访谈
• 面向数据流自顶向下求精
求要不断迭代)
• 注意区别”可行性分析”和”需求分析”的异 同；
• 设计出系统的”数据模型”、细化的“逻辑模 型”和“行为模型”；(关键所在)
需求分析做什么?
所有的结构化分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条
准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要
改
3.1.2 分析和设计系统的数据要求
• 软件系统的本质是对数据进行处理。 • 通常要求建立完整的数据模型（E-R模型） • 数据字典缺乏直观性（考虑图形化的描述复
杂数据的组成） • 必要时需要对数据模型进行规范化（范式） • 阶段性成果：
– E-R图 – 层次方框图或Warnier图
3.1.3 分析和设计系统的功能模型
第3章 需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
为什么需要需求分析？
• 开发人员往往急于求成 • 希望对开发进行指导 • 希望开发人员对用户的要求理解 • 希望用户理解开发人员 • 测试部门有理可依
开发计划
3.1.1 确定系统的综合要求
基本的、 核心的
MTTF
用户、硬件、 软件、通信
系统不应该 做什么
• 功能要求
时间、存储 量、安全性
• 性能要求
• 可靠性和可用性要求 • 出错处理要求
对环境错误 应该如何响
应
• 接口要求 • 约束
限制条件、 精度、语言
• 逆向要求 • 扩展要求
对系统可能 的扩充或修