软件工程第四讲--需求分析【荐】.ppt

第3章 需求分析 3.1 需求分析的任务 3.2 信息收集技术 3.3 数据模型 3.4 功能模型 3.5 行为模型 3.6 其他图形工具 3.7 验证软件需求 目标 列举信息收集技术技巧 设计项目的E-R图 设计项目的状态转换图 了解其他图形工具 第三章 需求分析(I) 需求分析的基本任务是准确地回答“系统必须做什么?” 。 确定系统必须完成哪些工作，对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书（Software Requirement Specification ），以书面形式准确地描述软件需求。 第三章 需求分析(II) 所有这些分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 3.1 需求分析的任务 3.1.1 需求内容 3.1.2 逻辑模型 3.1.3 修正系统开发计划 需求包括的内容 (1) 功能 (2) 性能 (3) 环境 (4) 接口 (5) 用户或人的因素 (6) 文档 (7) 数据 (8) 资源 (9) 安全保密 (10) 软件成本消耗与开发进度 (11) 质量保证 3.1.2 逻辑模型 数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图） 3.1.3 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.2 信息收集技术 3.2.1 主要问题 3.2.2 复查现有报表、表格和过程描述 3.2.3 访谈 3.2.4 观察并记录商业过程 3.2.5 建立原型 3.2.6 分发收集调查表 3.2.7 主持联合应用程序设计会议 3.2.8 面向数据流分析 3.2.9 简易规格说明书 3.2.1 主要问题 3.2.2 复查报表、表格和过程描述 商业文档和过程描述是了解过程的一个好方法。 表格和报表可以为面谈提供可视化的帮助、也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不会提及的商业规则。 有助于发现商业过程中的不一致和冗余。 3.2.3 面谈 需求调研例—学生选课系统-1 第一阶段：了解基本情况 请教务处老师介绍背景，如学生总数、课程数量、选课相关的基本制度等 第二阶段：制订访谈计划，深入讨论相关需求 除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户对系统的期望：准确、访问速度快… …… 需求调研例—学生选课系统-2 第三阶段：基本了解需求后就一些关键细节通过问卷进行明确 在已经了解总体选课人数之后，需要进一步了解通常情况下的选课持续时间、是否按院系逐步开放选科、选课人数的一般分布等—与性能设计密切相关 推荐关键管理人员使用USB Key设备，经济上是否可以接受 …… 原型：如该企业有类似成熟系统可结合系统演示进行需求调研 3.2.4 观察并记录商业过程(I) 观察 使用活动图来进行记录 3.2.4 观察并记录商业过程(II) 3.2.5 建立原型 3.2.6 分发和收集调查表 举例：某出版社系统需求调查表 举例：某出版社系统需求调查表 3.2.7 主持联合应用程序设计会议 JAD的目的是把所有这些活动压缩为用户和项目小组成员一起参加得更短的JAD会议。 参加人员： JAD会议领导者 用户 技术人员 项目组成员 3.2.8 面向数据流自顶向下求精 数据流图是帮助复查的极好工具。 从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。 这些认识正确吗?有没有遗漏?用户应该注意倾听分析员的报告，并及时纠正和补充分析员的认识。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。 3.2.9 简易的应用规格说明技术(I) 在展示了每个人针对某个议题的列表之后，大家共同创建一张组合列表。 组合列表将被缩短、加长或重新措辞，以便更准确地描述将被开发的产品。讨论的目标是，针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。进行分组讨论 最后，由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。 突出优点：开发者与用户不分彼此，齐心协力，密切合作；即时讨论并求精；有能导出规格说明的具体步骤。 分组讨论 为《社交故事管理系统》设计信息收集方案 时间：20分钟 3.3 ERD(I) 分析建模方法： 数据模型：ERD(实体联系图)