ch03 需求分析.pdf

渠道部第二季度经营分析渠道部第二季度经营分析 第3讲 需求分析 3.1 需求分析的任务 3.2 需求分析的重要性 3.3 需求分析的困难 3.4 获取用户需求的方法 3.5 需求分析与建模 3.6 结构化分析方法 Page 3 3.1 需求分析的任务需求分析的任务 可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案。因此许多细节被忽略。在系统开发前，还需要进一步确定系统必须完成哪些工作。不是“how”，而是“what”。Page 4 3.1 需求分析的任务需求分析的任务 目的 准确回答“系统做什么?”这个问题 任务：获取需求；深入实际，在充分理解用户需求的基础上，获取系统需求。需求分析与建模；进行需求建模型、对模型或原型进行分析。确认需求；确保需求说明准确、完整地表达系统的主要特性。进化需求。客户的需要总是不断（连续）增长的，进化需求是必要的。Page 5 软件需求 用户需求 系统需求 功能需求 非功能需求 领域需求 由客户管理员、用户等提出 软件需求的内容软件需求的内容 软件需求内容软件需求内容 Page 6 非功能需求非功能需求 产品需求产品需求 机构需求机构需求 外部需求外部需求 互操作互操作 需求需求 道德道德 需求需求 立法立法 需求需求 性能性能 需求需求 空间空间 需求需求 交付交付 需求需求 实现实现 需求需求 标准标准 需求需求 隐私隐私 需求需求 安全安全 性需求性需求 可用性可用性 需求需求 效率效率 需求需求 可靠性可靠性 需求需求 可移植可移植 性需求性需求 软件需求内容软件需求内容 Page 7 需求分析真的很重要吗？需求分析真的很重要吗？一个很好的例子：用在欧洲航天局太空火箭Ariane-5上的嵌入式软件。1996年6月4日，该火箭第一次飞行投入使用，刚工作约40秒，飞行便开始偏离其轨道。沿着Ariane地面控制器的方向飞行，火箭最终被摧毁。火箭摧毁，损失的不仅是火箭本身，还有它携带的四个人造卫星。总损失达到500 million美元。最后查明原因：在Ariane-5飞行轨道的需求文档中，没有分析其飞行路线，认为和Ariane-4一样。Page 8 3.2 需求分析的重要性需求分析的重要性 软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。完成并实施完成并实施完成未实施完成未实施未完成未完成未完成未完成 完成未实施完成未实施 完成完成 Page 9 3.2 需求分析的重要性需求分析的重要性 5点事实：1、需求错误代价高昂。（软件生命周期中，一个错误发现得越晚，修复错误的费用越高。）Page 10 3.2 需求分析的重要性需求分析的重要性 5点事实：2、需求错误是最常见的错误。DeMarco在一份研究报告中指出，被检查出来的错误的56产生的根源可以追溯到需求阶段。一个美国空军项目中的错误来源一个美国空军项目中的错误来源 Page 11 3.2 需求分析的重要性需求分析的重要性 5点事实：3、许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来。在需求阶段，代表性的错误为疏忽、不一致和二义性。美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A7E机上的操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A7E项目中77的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是：49不正确的事实，31疏忽，13不一致，5二义性 需求错误是可以被检查出来的。Page 12 3.3 需求分析的困难需求分析的困难 软件需求是软件工程中最复杂的过程之一：应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。沟通上的困难，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。Page 13 软件需求软件需求比喻比喻 Page 14 项目开发前项目开发前 分析员的理分析员的理 解、设想解、设想 软件需求的困难软件需求的困难 Page 15 分析员分析员 的描述的描述 软件需求的困难软件需求的困难 Page 16 完成的设计完成的设计 软件需求的困难软件需求的困难 Page 17 程序员做出的产品程序员做出的产品 软件需求的困难软件需求的困难 Page 18 现场的安装现场的安装 软件需求的困难软件需求的困难 Page 19 用户原来的设想用户原来的设想 软件需求的困难软件需求的困难 Page 20 Page 21 3.4 获取用户需求的方法获取用户需求的方法 需求抽取的方法一般有：1.面谈法。重要而直接，简单的需求获取技术。2.问卷法调查法。是对面谈法的补充。3.需求专题讨论会。最有力的需求获取技术。有利 于 培养高效团队。4.观察用户的工作流程。适用于用户无法准确表达需求的情况。5.原型化方法 6.基于用例的方法 Page 22 3.4 获取用户需求的方法获取用户需求的方法 需求抽取的方法一般有：1.面谈法。重要而直接，简单的需求获取技术。2.问卷法调查法。是对面谈法的补充。3.需求专题讨论会。最有力的需求获取技术。有利 于 培养高效团队。4.观察用户的工作流程。适用于用户无法准确表达需求的情况。5.原型化方法 6.基于用例的方法 面谈的对象主要有用户和领域专家：面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；面谈前的准备要充分；2）面谈后注意认真分析总结；面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。注意掌握面谈的人际交流技能。Page 23 3.4 获取用户需求的方法获取用户需求的方法 需求抽取的方法一般有：1.面谈法。重要而直接，简单的需求获取技术。2.问卷法调查法。是对面谈法的补充。3.需求专题讨论会。最有力的需求获取技术。有利 于 培养高效团队。4.观察用户的工作流程。适用于用户无法准确表达需求的情况。5.原型化方法 6.基于用例的方法 是从多个用户中收集需求信息的有效方是从多个用户中收集需求信息的有效方式式，一般问卷设计形式：，一般问卷设计形式：1）多项选择问题）多项选择问题；2）评分问题）评分问题；3）排序问题）排序问题。Page 24 3.4 获取用户需求的方法获取用户需求的方法 需求抽取的方法一般有：1.面谈法。重要而直接，简单的需求获取技术。2.问卷法调查法。是对面谈法的补充。3.需求专题讨论会。最有力的需求获取技术。有利 于 培养高效团队。4.观察用户的工作流程。适用于用户无法准确表达需求的情况。5.原型化方法 6.基于用例的方法 由开发方和用户方共同召开，操作步骤：由开发方和用户方共同召开，操作步骤：开发方根据双方制定的开发方根据双方制定的需求调研计划需求调研计划召开相关需求主题沟通会；召开相关需求主题沟通会；会后开发方整理出会后开发方整理出需求调研记录需求调研记录提交给用户方确认；提交给用户方确认；如果此主题还有未明确的问题则再次沟通如果此主题还有未明确的问题则再次沟通,否则开始下一主题；否则开始下一主题；所有需求都沟通清楚后，开发方根据历次所有需求都沟通清楚后，开发方根据历次需求调研记录需求调研记录整理出整理出用户需求说明书用户需求说明书，提交给用户方确认签字。，提交给用户方确认签字。Page 25 3.4 获取用户需求的方法获取用户需求的方法 需求抽取的方法一般有：1.面谈法。重要而直接，简单的需求获取技术。2.问卷法调查法。是对面谈法的补充。3.需求专题讨论会。最有力的需求获取技术。有利 于 培养高效团队。4.观察用户的工作流程。适用于用户无法准确表达需求的情况。5.原型化方法 6.基于用例的方法 最准确、最有效、最强大的需求分析技术最准确、最有效、最强大的需求分析技术 1、快速、快速 尽快提供给用户一个可运行的目标系统的原型，以便使用户和开发者尽快提供给用户一个可运行的目标系统的原型，以便使用户和开发者就系统“做什么”达成共识。就系统“做什么”达成共识。2、容易修改、容易修改 原型功能不能满足用户，则根据用户意见迅速修改，以更好地满足用原型功能不能满足用户，则根据用户意见迅速修改，以更好地满足用户需求。户需求。重复“修改重复“修改试用试用反馈”过程。反馈”过程。Page 26 3.5 需求分析与建模需求分析与建模 功能分解方法 将系统看作若干功能模块的集合，每个功能又可以分解为子功能,子功能还可继续分解,分解的结果即是系统的雏形。问题空间问题空间 功能功能 子功能子功能 映射映射 问问 题题 1 1.需要人工完成需要人工完成 2 2.无法对描述的准确度进行验证无法对描述的准确度进行验证。3 3.难以适应需求的变化难以适应需求的变化。Page 27 3.5 需求分析与建模需求分析与建模 结构化分析方法 结构化分析方法（Structured Analysis，简称SA方法）是70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。结构化分析方法适用于分析大型的数据处理系统，特别适用于企事业管理系统。结构化分析方法通常与设计阶段的结构化设计方法（Structured Designed，简称SD方法）衔接起来使用。Page 28 3.5 需求分析与建模需求分析与建模 面向对象的分析方法 面向对象的分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型（对象模型、动态模型、功能模型）。1992年由Jacobson提出了Use case 的概念及可视化的表示方法Use case图，并加入由他提出的面向对象的软件工程(OOSE)。Use case 的概念受到了IT界的欢迎，被广泛应用到了面向对象的系统分析中。基于用例的需求方法，已成为面向对象的分析方法的主流。用例模型被推荐为获取和识别需求的首选工具!Page 29 3.6 结构化分析方法结构化分析方法 SA法的基本思想 “分解”和“抽象”。分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决（如右图）。抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。1.1 1.2 1.3 x 2 1 3 2.1 2.2 2.3 1.1 1.3 Page 30 3.6 结构化分析方法结构化分析方法 模型的核心是DD（Data Dictionary，数据字典），它是系统所涉及的各种数据对象的总和。从DD出发可构建3种图：E-R图（Entity Relation Diagram，实体-关系图）用于描述数据对象间的关系，它代表软件的数据模型；DFD（Data Flow Diagram，数据流图），其主要作用是指明系统中数据是如何流动和变换的，以及描述使数据流进行变换的功能，在DFD图中出现的每个功能的描述则写在加工说明（PSPEC）中，它们一起构成软件的功能模型；STD（Status Transfer Diagram，状态-变迁图），用于指明系统在外部事件的作用下将会如何动作，表明了系统的各种状态以及各种状态间的变迁，从而构成为行为模型的基础。结构化分析模型结构化分析模型 Page 31 当前系统当前系统 具体模型具体模型 建立建立 当前系统当前系统 逻辑模型逻辑模型 抽象抽象 目标系统目标系统 逻辑模型逻辑模型 建立建立 完善的系统完善的系统逻辑模型逻辑模型 改进改进 深入调查深入调查 研究研究 分析用户需求分析用户需求,用用DFD图描述图描述 分析系统需求分析系统需求,用用DFD图描述图描述 修改完善修改完善DFD图图,增添功能增添功能 SA法的步骤法的步骤 3.6 结构化分析方法结构化分析方法 Page 32 3.6.1 数据流图数据流图DFD Data Flow Diagram 数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。数据流图的基本图形元素 数据流 加工（处理）文件（数据存储）数据池（数据源或终点）Page 33 顾客顾客 出版社出版社 验证验证 订单订单 汇总汇总 订单订单 订单订单 出版社出版社 订单订单 图书目录文件图书目录文件 顾客档案顾客档案 待处理订单文件待处理订单文件 正确正确 订单订单 一批一批 订单订单 出版社档案文件出版社档案文件 订货存根文件订货存根文件 画图步骤画图步骤 ：1 1、确定外部实体及输入、输出数据流。、确定外部实体及输入、输出数据流。2 2、确定分解顶层的加工。、确定分解顶层的加工。3 3、确定使用的文件。、确定使用的文件。4 4、用数据流将各部分连接起来，形成数据封闭。、用数据流将各部分连接起来，形成数据封闭。注意：标注各加工框及数据流名称。注意：标注各加工框及数据流名称。例例:图书预定系统（顶层图书预定系统（顶层DFD图）图）Page 34 3.6.1 数据流图数据流图DFD 数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它描述了将系统的逻辑输入转换为逻辑输出所需的加工处理过程。数据存储数据存储 数据源点数据源点 或终点或终点 加加 工工 加工名加工名 数据流数据流 数据流名数据流名 文件名文件名 实体名实体名 箭箭 头头 圆、椭圆或圆、椭圆或圆角矩形圆角矩形 单或双杠单或双杠 矩形框矩形框 还有一些辅助的图例还有一些辅助的图例:数据流图的图符基本图形符号：数据流图的图符基本图形符号：T A B*C T A B*C T A B+C T A B+C T A B C+T A B C+*与与 +或或 互斥+Page 35 X 1 3 2 1.1 1.2 1.4 1.3 2.1 2.2 1.1.1 1.1.2 2.1.3 2.1.2 2.1.1 2.2.2 2.2.3 2.2.1 顶顶层层 中中 间间 层层 底底 层层 先全局后局部先全局后局部,先整体后细节先整体后细节,先抽象后具体先抽象后具体.0图 1图 2图 1.1图 2.1图 2.2图 分层分层DFD 图图 Page 36 画分层画分层DFD图的基本原则图的基本原则 数据守恒与数据封闭原则 数据守恒是指加工的输入输出数据流是否匹配，即每一个加工既有输入数据流又有输出数据流。数据封闭是对整个系统而言。加工分解的原则 自然性：概念上合理、清晰；均匀性：理想的分解是将一个问题分解成大小均匀的几个部分；分解度：一般每一个加工每次分解最多不要超过个子加工,分解应分解到基本加工为止。Page 37 画分层画分层DFD图的基本原则图的基本原则 子图与父图的“平衡”父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(相对应），分层数据流图的这种特点称为子图与父图“平衡”。合理使用文件 当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件作为数据流图中的一个独立成份画出来了，那么他同其他成份之间的联系也应同时表达出来。DFDDFD图不是流程图图不是流程图,不表示软件的控制流程。不表示软件的控制流程。Page 38 3.6.2 实体实体 联系图联系图 Entity-Relationship Diagram 使用ER来建立数据模型 数据模型中包含3种相互关联的信息：实体（数据对象）属性 关系 Page 39 3.6.2 实体实体 联系图联系图 某校教学管理某校教学管理ERER图图 Page 40 3.6.3 状态迁移图状态迁移图 状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示。状态：状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。事件 是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。Page 41 3.6.3 状态迁移图状态迁移图 例如，在操作系统中，进程 3 种基本状态的变化如图 所示。进程的状态迁移图进程的状态迁移图 Page 42 3.6.4 数据词典数据词典 分层数据流图只是表达了系统的“分解”，为了完整地描述这个系统，还需借助“数据词典”和“小说明”对图中的每个数据和加工给出解释。对数据流图中包含的所有元素的定义的集合构成了数据词典。词典中可有以下四种类型的条目：数据流数据流 文件文件 数据项数据项 加工加工 Page 43 A、数据流条目数据流条目 给出某个数据流的定义，通常是列出该给出某个数据流的定义，通常是列出该 数据流的各组成数据项。数据流的各组成数据项。例如：例如：报名单姓名单位名年龄性别课程名报名单姓名单位名年龄性别课程名 常用符号：、（）、常用符号：、（）、C、数据项条目数据项条目 数据项条目给出某个数据单项的定义数据项条目给出某个数据单项的定义，通常是数据项的值类型通常是数据项的值类型，允许允许的取值范围的取值范围。B、文件条目、文件条目 给出某个文件的定义，同数据流一样，文件的定义通常是列给出某个文件的定义，同数据流一样，文件的定义通常是列出文件记录的组成数据流出文件记录的组成数据流 例如某销售系统的订单文件：例如某销售系统的订单文件：订单文件订单编号顾客名称产品名称订货数量交货日期订单文件订单编号顾客名称产品名称订货数量交货日期 D.加工条目加工条目 加工类条目就是加工类条目就是“加工小说明加工小说明”。一般应该单独列出。一般应该单独列出。nm.3.6.4 数据词典数据词典 Page 44 3.6.4 数据词典数据词典 在数据词典的定义中出现的符号含义 Page 45 小结小结 了解需求分析的目的、任务和方法 掌握需求分析工具的使用：数据流图 数据字典 实体联系图 状态转换图 Page 46 Excise 习题3（P73）3