软件工程(张海藩)第3章.ppt

2 第3章 需求分析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 基本概念 开发过程的两大阶段 （1）正确地确定问题 （2）为问题寻找合适的解答 目的 澄清用户的各种需求 基本任务 用户和软件人员双方一起来充分理解用户的要求，并把双方共同的理解明确地表达成一份书面文档——软件需求规格说明书。 在软件生命期的每个阶段中，分析阶段是面向“问题”的，它主要是对用户的业务活动进行分析，明确在用户的业务环境中，软件系统应该“做什么”。 分析系统的数据要求 建立数据模型（层次方框图、Warnier图） 导出系统的逻辑模型 数据流图 实体— 联系图 状态转换图 数据字典 主要的处理算法 修正系统开发计划 需求分析的过程 需求分析阶段可分为四个过程：调查研究、分析与综合、书写需求分析的文档和评审。 （1）调查研究 目的：通过各种途径获取用户需求信息产生《用户需求说明书 》 角色与职责：需求分析员调查、分析用户的需求，客户与最终用户提供必要需求信息 （2）分析与综合 从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求。 （3）书写需求分析文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 （4）需求分析的评审 系统定义的目标是否与用户的要求一致 系统需求分析阶段提供的文档资料是否齐全 文档中的所有描述是否完整、清晰、准确反应用户要求 与所有其它系统成分的重要接口是否都已经描述 需求获取的方法 系统分析员建立需求的过程中所遇到的困难 ⑴ 分析员与领域专家交流的过程中，容易产生误解 ⑵ 大型系统有时会有不同的用户群体，他们往往会提出相互矛盾的要求，分析员要寻求令所有用户满意的答案很难 ⑶ 需求永远不会稳定。系统工程环境一旦改变，用户对软件的需求也会改变，而且这种需求往往无法预测。 访谈 访谈有正式访谈和非正式访谈两种形式。 非正式访谈以一种较自由的形式，交换对问题的看法，主要是了解问题的性质、需要解决的方案、所需的人数和能力，关注客户的目标和收益。 正式访谈将根据一些事先准备好的议题全面展开讨论，得出结论性的意见。 情景（场景）分析是从软件系统的一个交互情景示例中得到需求分析信息，然后将其以形式化方式表示出来。 情景分析是用户在某种程度上演示产品的应用“样本”，通过交互实例片断细节（情景）的描述，实现对某个目标产品的表述。每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息。 情景开始于一个框架，在导出过程中，细节被逐渐增加，直到产生交互的一个完整的描述。 场景（情景）内容 通常，一个场景（情景）可能包括： ① 在场/情景开始部分有一个系统状态描述； ② 一个关于标准事件流的描述； ③ 一个关于哪儿会出错，以及如何处理错误的描述； ④ 有关其他可能在同一时间进行的活动的信息； ⑤ 在场/情景完成后系统状态的描述。 面向数据流自顶向下求精 结构化分析方法（SA）就是面向数据流自顶向下逐步求精进行需求分析的方法。 “ 结构化分析”（“ Structured Analysis”）是一个简单实用，使用广泛的方法。 它适用于分析大型的数据处理系统，尤其是企事业管理方面的系统，这个方法通常与设计阶段的结构化设计方法（SD）衔接起来。 软件工程技术中，控制复杂性的两个基本手段是“分解”和“抽象”。 分解：把大问题分割成若干个小问题，然后分别解决。 对于一个复杂的系统（比如银行管理系统）如何理解和表达它的功能呢？ SA方法使用了“自顶向下逐层分解”的方法。 “逐层分解”体现了分解和抽象的原则，它使我们不至于一下子