第3章 需求分析5-6

单击此处编辑母版标题样 式
单击此处编辑母版标题样 思想：软件系统本质上是信息处理系统， 思想：软件系统本质上是信息处理系统，基本功能都是把输 入数据转变成需要的输出信息。 入数据转变成需要的输出信息。由于数据决定了需要的处 式
3.2.2 面向数据流自顶向下求精 理和算法(功能) 因而数据可作为需求分析的出发点。 理和算法(功能)，因而数据可作为需求分析的出发点。 结构化分析方法就是面向数据流自顶向下逐步求精进行需求 分析的方法。从数据流图的输出（结果）数据出发， 分析的方法。从数据流图的输出（结果）数据出发，沿数 据流图逆向而溯源，把每个数据流和数据存储定义到元素 据流图逆向而溯源， 在此过程中，分析系统的数据和处理是否正确。 级。在此过程中，分析系统的数据和处理是否正确。 分析过程：回溯分析——用户复查——分解求精 分析过程：回溯分析——用户复查——分解求精 ——用户复查——
调查表：当需要调查大量人员的意见时， 调查表：当需要调查大量人员的意见时，向被调查人分发调 查表是一个十分有效的做法。 查表是一个十分有效的做法。特点是书面回答可能比口头 回答更准确。分析员阅读收回的调查表，然后访问用户。 回答更准确。分析员阅读收回的调查表，然后访问用户。 情景分析： 情景分析：让用户在身临其境的模拟或演示目标系统解决某 个具体问题的过程中进行分析和交流。情景分析优： 个具体问题的过程中进行分析和交流。情景分析优： 1)身临其境，便于用户理解、联想和分析，进而揭示出一些 1)身临其境，便于用户理解、联想和分析， 身临其境 分析员目前还不知道的需求。 分析员目前还不知道的需求。 2)用户在需求分析过程中始终扮演一个积极主动的角色。 2)用户在需求分析过程中始终扮演一个积极主动的角色。 用户在需求分析过程中始终扮演一个积极主动的角色
单击此处编辑母版标题样 式
图3.1 面向数据流自顶向下求精过程刨根
单击此处编辑母版标题样 式
图2.7 把处理事务的功能进一步分解后的数据流图
表2.1 数据流图数据元素
单击此处编辑母版标题样 式
源点/ 源点/终点 处理 采购员 仓库管理员 产生报表 处理事务 数据流 定货报表 零件编号 零件名称 定货数量 目前单价 供应者 事务 零件编号* 零件编号* 事务类型 数量* 数量* 数据存储 定货信息 与定货报表相同) (与定货报表相同) 库存清单* 库存清单* 零件编号* 零件编号* 库存量 库存临界值
单击此处编辑母版标题样 第3章 需求分析 式 3.3.6 3.7 3.8 与用户沟通获取需求的方法 分析建模与规格说明 实体实体-联系图 数据规范化 状态转换图 其他图形工具 验证软件需求
单击此处编辑母版标题样 需求分析重要性：需求分析是软件定义时期的最后、 需求分析重要性：需求分析是软件定义时期的最后、也是最重要的一个 阶段， 阶段 关系到软件开发工作的成败和全局。 式 ，关系到软件开发工作的成败和全局。 ？”这个问题，即 需求分析的基本任务：准确地回答“系统必须做什么？ 这个问题， 需求分析的基本任务：准确地回答“系统必须做什么
单击此处编辑母版标题样 式
8.将来可能提出的要求 8.将来可能提出的要求
单击此处编辑母版标题样 从发展的眼光考虑， 从发展的眼光考虑，应该明确地列出那些虽然不属于当前 式
系统开发范畴，但是据分析将来很可能会提出来的要求。 系统开发范畴，但是据分析将来很可能会提出来的要求。 这样做的目的是， 这样做的目的是，在设计过程中对系统将来可能的扩充和 修改预做准备，以便一旦确实需要时能比较容易地进行这 修改预做准备， 种扩充和修改。 种扩充和修改。
单击此处编辑母版标题样 数据 重要性：任何一个软件系统本质上都是信息处理系统， 重要性：任何一个软件系统本质上都是信息处理系统， 需求是必然的。 需求是必然的。 式
数据模型：常用“实体—联系图”建立数据模型。 数据模型：常用“实体—联系图”建立数据模型。数据模型 应该清楚地描述系统所需要的数据结构及其相互关系。 应该清楚地描述系统所需要的数据结构及其相互关系。 数据分析工具：数据字典；层次方框图和Warnier图 数据分析工具：数据字典；层次方框图和Warnier图。 Warnier 规范化： 规范化：软件系统使用的数据通常以一定方式组织并存储在 数据库或文件中，为减少数据冗余， 数据库或文件中，为减少数据冗余，避免出现插入异常 或删除异常，简化修改数据的过程， 或删除异常，简化修改数据的过程，通常需要把数据结 构规范化。 构规范化。
3.1.2 分析系统的数据要求
导出系统的逻辑模型 单击此处编辑母版标题样 通常用数据流图（功能模型）、实体-关系图（ ）、实体 通常用数据流图（功能模型）、实体-关系图（数据模 式 状态转换图（行为模型）、 ）、状态转换图 ）、数据字典和主要的处理 型）、状态转换图（行为模型）、数据字典和主要的处理 3.1.3 算法描述系统逻辑模型。 算法描述系统逻辑模型。 3.1.4 修正系统开发计划 需求分析使得需求更准确、更完整、更具体。可以比较准 需求分析使得需求更准确、更完整、更具体。 确地估计系统的成本和进度，修正以前制定的开发计划。 确地估计系统的成本和进度，修正以前制定的开发计划。 上述需求分析的基本任务：综合需求、数据需求、 上述需求分析的基本任务：综合需求、数据需求、导出逻 辑模型、修正开发计划。 辑模型、修正开发计划。
3. 可靠性和可用性需求
单击此处编辑母版标题样 可靠性需求定量地指定系统的可靠程度， 可靠性需求定量地指定系统的可靠程度，它限定了系统在 式 运行时段内出现的故障次数。如某系统在一个月内故障<3 运行时段内出现的故障次数。如某系统在一个月内故障<3
次。 可用性：量化用户可以使用系统的程度。 可用性：量化用户可以使用系统的程度。如系统在某段时 间内必须是可用的，且不可用的时间不能超过总时间的2% 2%。 间内必须是可用的，且不可用的时间不能超过总时间的2%。
单击此处编辑母版标题样 ，数 用户复查：必须请用户对上述分析过程中得出的结果仔细地复查， 用户复查：必须请用户对上述分析过程中得出的结果仔细地复查 据流图是帮助复查的极好工具。从输入端开始，分析员借助数据流图、 据流图是帮助复查的极好工具。从输入端开始，分析员借助数据流图、 式 IPO图向用户解释输入数据是怎样一步一步地转变成输出 数据字典和IPO 数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出
单击此处编辑母版标题样 式 访谈是最早最经典需求分析技术，仍被广泛使用。 访谈是最早最经典需求分析技术，仍被广泛使用。
3.2 与用户沟通获取需求的方法 3.2.1 访谈 访谈方式：交谈、表格调查和情景分析。 访谈方式：交谈、表格调查和情景分析。 访谈：两种基本形式，分别是正式的和非正式的访谈。 访谈：两种基本形式，分别是正式的和非正式的访谈。 正式访谈：系统分析员将提出一些事先准备好的具体问题 正式访谈： 如业务类型和流程等) (如业务类型和流程等)。 非正式访谈： 非正式访谈：提出一些用户可以自由即兴回答的开放性问题 现有系统如何？有何不足之处？希望是什么？ (现有系统如何？有何不足之处？希望是什么？)，鼓励被 访人员说出自己的想法
单击此处编辑母版标题样 式
回溯分析：输出数据是由哪些元素组成的呢？通过调查访问不难搞清这个问题。 回溯分析：输出数据是由哪些元素组成的呢？通过调查访问不难搞清这个问题。 那么，每个输出数据元素又是从哪里来的呢？既然它们是系统的输出， 那么，每个输出数据元素又是从哪里来的呢？既然它们是系统的输出，显然它 们或者是从外面输入到系统中来的，或者是通过计算由系统中产生出来的。 们或者是从外面输入到系统中来的，或者是通过计算由系统中产生出来的。沿 数据流图从输出端往输入端回溯， 数据流图从输出端往输入端回溯，应该能够确定每个数据元素的来源与处理数 据的有关算法。但是，可行性研究阶段产生的是高层数据流图， 据的有关算法。但是，可行性研究阶段产生的是高层数据流图，许多具体的细 节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题： 节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题：为了得到某个 数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素 数据元素需要用到数据流图中目前还没有的数据元素， 需要用的算法尚不完全清楚。 为了解决这些问题， 需要用的算法尚不完全清楚。 为了解决这些问题，往往需要向用户和其他有 关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了， 关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了，系统中 更多的数据元素被划分出来了，更多的算法被搞清楚了。 更多的数据元素被划分出来了，更多的算法被搞清楚了。通常把分析过程中得 到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO 到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO 图中。通过分析而补充的数据流、数据存储和处理， 图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适 当位置上。上述过程为回溯分析。（类似数学中所用的分析法） 。（类似数学中所用的分析法 当位置上。上述过程为回溯分析。（类似数学中所用的分析法）
4. 出错处理需求 这类需求说明系统的容错能力需求， 这类需求说明系统的容错能力需求，即系统对环境错误或 自身错误如何检测和处理的需求。 自身错误如何检测和处理的需求。
5.接口需求 5.接口需求 接口需求描述应用系统与它的环境通信的格式。 接口需求描述应用系统与它的环境通信的格式。如用户接 口需求；硬件接口需求；软件接口需求；通信接口需求。 口需求；硬件接口需求；软件接口需求；通信接口需求。 6.约束 6.约束 约束是指在设计或实现目标系统时应遵守的限制条件。 约束是指在设计或实现目标系统时应遵守的限制条件。常 见约束有：数据精度，工具和语言，使用标准， 见约束有：数据精度，工具和语言，使用标准，软硬件平 台等约束。 台等约束。 7.逆向需求 7.逆向需求 逆向需求说明软件系统不应该做什么。 逆向需求说明软件系统不应该做什么。仅选取能澄清真实 需求且可消除可能发生的误解的那些逆向需求。例如： 需求且可消除可能发生的误解的那些逆向需求。例如：银 行安全程序不应模拟不安全问题发生的事件。 行安全程序不应模拟不安全问题发生的事件。