[工学]软件需求分析过程.ppt

需求工程基本任务 需求分析的基本任务 需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。 需求分析模型 逻辑模型 物理模型 (本质模型、概念模型) (实施模型、技术模型) 软件需求曾经让我们如此狼狈 需求变化 合理范围内的变化： 用户不了解自己的需求 需求本身易变，市场、技术、竞争因素 不合理的变化： 需求文档质量不高 需求分析技能、技术和管理上的缺陷 需求变化的原因： 未受控制的需求变更 遗漏需求 用户交流不够 需求规约质量差 低效的需求分析 需求分析的重要性 需求的重要性： 需求是产品的根源，需求工作的优劣对产品影响最大。 是系统开发的基础，质量和成败的关键 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 需求分析是通过问题识别、分析与综合、制订规格说明和评审等阶段，达到为系统设计提供依据的目标。因此，需求分析过程包括： 　确定对系统的综合要求 　分析系统的数据要求 　抽象出并确立目标系统的逻辑模型 　编写需求规格说明书 可行性研究的任务 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解决。 一般来说，至少应该从下述四个方面去研究每种解法的可行性： 技术可行性：使用现有的技术能实现这个系统吗？ 经济可行性：这个系统的经济效益能超过它的开发成本吗？ 操作可行性：系统的操作方式在这个用户组织内行得通吗？ 时间可行性：能在预定时间内完成吗？ 可行性研究最根本的任务是对以后的行动方针提出建议。 软件需求各组成部分之间的关系 软件需求规格说明的原则 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的规格说明语言 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充 需求分析通信途径 系统分析（详细业务调查） 某出版社系统调查表 组织结构与功能分析 组织结构图 是一张反映组织内部之间隶属关系的树状结构图。 组织／业务关系图 业务流程分析 需求：组织的某些部分不能完整地反映该部分所包含的所有业务，所以要改变 随着生产的发展，生产规模的扩大和管理水平的提高，组织的某些部分业务范围越来越大，功能也越来越细，由原来单一的业务派生出许多业务。 这些业务在同一组织中由不同的业务人员分管，其工作性质已经逐步有了变化。 这些变化将引起组织本身的变化，裂变出一个新的、专业化的组织，由它来完成某一类特定的业务功能。 以功能为准绳来设计和考虑系统，系统将会对组织结构的变化有一定的独立性。 以业务功能分析为基础，获得一张业务功能表 所以：系统必须以业务为中心，业务功能与组织结构保持相对的独立性——从组织结构直接转变为系统功能结构是初级系统分析师的第二个常犯的错误 业务功能图 需求分析过程举例 (1) 通过对现实环境的调查，获当前系统的具体模型(物理模型) 需求分析过程举例 (2) 去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型 需求分析过程示意 (3) 分析当前系统与目标系统的差别，建立目标系统的逻辑模型 6.4.1 数据流图(DFD) 任何软件系统（或计算机系统）从根本上说，都是对数据进行加工或变换的工具。 数据流图Data Flow Diagram ：一种结构化分析描述模型，用来对系统的功能需求进行建模，它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况 指明数据在系统中移动时如何被变换 描述对数据流进行变换的功能 DFD中每个功能的描述包含在加工规约中 数据流程图的另一种基本符号 数据流图的构成－数据流 数据流（Data Flow）由一个或一组确定的数据组成。 ①数据流名应能直观地反映数据流的含义。 ②数据流的流向 ③数据流可以同名，也可以有相同的数据结构，但必须有不同的数据或具有不同的含义。 ④两个符号(加工、外部项、数据存储)之间可以有多个数据流存在，DFD并不表明它们之间的任何关系，诸如次序、主次等。 ⑤避免错误的数据流命名方法 数据流图的构成－加工 加工又称处理亦称变换，它表示对数据流的操作。 加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。 标识部分用于标注加工编号，加工编号应具有唯一性，以标识加工，可以用“P