软件需求分析.ppt

事件名(参数表)/动作表达式 活动表的语法 entry: 指定进入该状态的动作； exit: 指定退出该状态的动作； do: 指定该状态下的动作。 事件表达式的语法 事件名(参数表)[守卫条件]/动作表达式 事件说明 布尔表达式 and 动作表达式是一个过程表达式，当状态转换开始时执行该表达式。 三.层次方框图 用树型结构和一系列的矩形框自顶向下描述数据结构的多层次结构； 四. Warnier 图 表示数据层次结构：组成结构； 表示数据的逻辑组织：元素的重复、有条件出现； 信息/数据元素 出现的条件 重复次数 五. IPO 图 Input-Process-Output Diagram (输入 / 处理 / 输出图) 描述输入数据、输出数据和数据处理之间的关系。 排列顺序暗示执行的顺序 数据通信情况 IPO 表 用PDL进行处理流程描述 3.5 验证软件需求 一致性：不能相互矛盾； 完整性：规格说明书应包括用户需要的每一个要求； 现实性：技术上可以实现； 有效性：需求确实能解决用户面对的问题 ； 一. 验证内容 二. 验证需求的方法 一致性：形式化的描述软件需求； 现实性：仿真、性能模拟技术； 完整性、有效性：快速原型法。 3.6 小结 全面理解需求分析阶段(方法 过程 工具) 理解获取需求的方法和原则 掌握分析建模与结构化分析方法 综合使用多种工具描述逻辑模型 第 3 章 需求分析 知识点 需求分析概述 需求分析的步骤 获取需求的方法 分析建模与工具 验证软件需求 3.1 需求分析概述 可行性研究从概念上定义软件的总体目标，粗略地了解了用户的需求。需求分析进一步精化软件的作用范围，明确系统必须完成的功能，对目标系统提出完整、准确、清晰、具体的要求。 需求获取面临的挑战 客户说不清楚需求； 需求易变性； 问题的复杂性； 对问题空间理解的不完备性与不一致性。 需求分析由软件分析人员与用户共同完成。 优秀需求具有的特性 正确性：需求描述必须与用户对系统的期望相符； 无歧义性 ：对用户、软件工程师而言，任何术语只能有惟一的语义解释； 完整性 ：不能遗漏任何用户要求； 一致性 ：需求的各个部分不能相互矛盾； 可理解性：需求描述不应该使用太多专业化词汇； 可修改性：应该保证能够比较容易接纳修改； 可追踪性：将分析后的需求与原始需求联系起来。 需求分析的任务 通过对目标问题、用户要求和目标环境的研究、分析和综合，建立抽象级的分析模型 (Analysis Model)； 准确地、完整地体现用户需要的功能、性能及其他要求，规范地通过“软件需求规格说明书” (SRS, Software Requirement Specification) 表达出来。 3.2 需求分析的步骤 确定系统的综合要求 分析系统的数据要求 建立系统的逻辑模型 修正系统开发计划 复审、验证需求分析 编写软件需求规格说明书 一.确定系统的综合要求 1、功能需求 系统必须完成的所有功能 ( 输入、输出、加工 )； 2、性能需求 系统必须满足的时间、空间约束，通常包括响应时间、信息量速率、容量、安全性等； 1）强制的需求； 2）希望的需求； 3）可选的需求。 系统与环境通信的格式：用户接口、硬件接口、软件接口、通信接口等； 4、出错处理需求 系统对环境错误如何处理，这类错误并不是由系统本身造成的。仅限于关键部分，尽可能少； 5、接口需求 3、可靠性需求 定量指出系统的故障率和使用程度，一个衡量可靠性的参数是平均失效前时间 (MTTF, Mean Time To Failure)，定义为随机变量、出错时间等的期望值。 明确列出当前不属于系统开发范畴，将来很可能会提出的要求。 7、逆向需求 系统不应该做什么，选取澄清真实需求且可消除误解的逆向需求，且不需定量分析； 8、将来可能出现的要求 6、约束 在设计或实现系统时应遵守的条件：精度、工具和语言约束、设计约束、标准、硬件平台； 二.分析系统的数据要求 数据字典：不够直观； 层次方框图； Warnier 图； 任何软件系统的本质都是信息处理系统。信息很大程度上决定了系统概貌。 描绘数据结构： 数据结构规范化：范式(Normal Forms) 消除数据冗余的程度。 三.导出系统的逻辑模型 数据流图 数据字典 实体-联系图 状态转换图 主要的处理算法 导出详细的系统逻辑模型。 四.修正系统的开发计划 修正在可行性分析阶段制定的初步的开发计划。 3.3 获取需求的方法 正式的访谈：具体问题的问答形式； 非正式的访谈：开放式、交互性的问答。 一.访谈 书面调查：调查大量人员意见； 情景分析技术：对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。 1）能在某种程度上演示目标系统的行为，便于理解； 2）用户在需求分析过程中始