第3讲-需求分析.ppt

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