[工学]软件工程 第3章.ppt

软件工程导论 Lecturer: 郭名静 (Tracy Guo) QQ: 799749353 Email: Tracyguo117@ Outline 课程框架 第 1 章 软件工程学概述 第 2 章 可行性研究 第 3 章 需求分析 第 4 章 形式化说明技术 第 5 章 总体设计 第 6 章 详细设计 第 7 章 实现 第 8 章 维护 第3章 需求分析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 Problem 技术与需求之间的矛盾 用户的问题： 知道自己需要什么，但不知道怎样用软件实现自己的需求； 无法正确的表达自己的需求。 系统分析员的问题： 知道怎样用软件实现需求，但是在项目开始时对用户需求并不十分清楚； 盲目的自信，认为自己理解客户。 Problem 技术与需求之间的矛盾 程序员的问题： 编程趣味性太大； 认为有了软件，一切都可以清楚了。 需求本身的问题： 需求变更对软件研发的控制； 需求信息记录混乱，没有办法作为检验依据。 Overview 需求分析 准确地回答“系统必须做什么?” 确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求; 提供完整准确的系统逻辑模型。 Kick off 项目启动阶段 需求调研：尽可能详细的收集需求，建议从组织结构图着手； 确定项目组织架构：“团队建设问题” 项目组织结构：功能，项目，矩阵 项目团队结构：主程序员，无边团队 确定项目：实施范围、预算、时间、资源等； 确定沟通计划：形式，时间，相关人，沟通方式。 Project Team 项目团队建设 核心团队和扩展团队 项目配备人员的分析： 需求 能力匹配 可能性问题 团队稳定性的重要，尽量禁止随意进出 虚拟团队的建设问题 Organization 项目组织结构类型 Project Team 项目团队结构类型 Investigation 需求调研 调研准备阶段： 背景资料，准备文档 形式 心态，能力 调研收尾阶段： 调研报告 需求规格说明书 需求分析准则 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 必须定义软件应完成的功能，这条准则要求建立功能结构模型。 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 3.1 需求分析的任务 确定用户方对系统的综合要求： 功能需求：系统要实现的功能； 性能需求：系统必须满足约束等； 可靠性和可用性需求； 出错处理需求：对环境错误如何响应； 接口需求：用户、硬件、软件、通信； 逆向需求：系统不该做什么； 将来可能提出的要求：可能的扩充预备。 3.1 需求分析的任务 cont 分析系统的数据要求： 任何一个软件系统本质上都是信息处理系统，分析系统的数据要求，这是软件需求分析的一个重要任务。 导出系统的逻辑模型： 数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述等。 修正系统开发计划 3.2 与用户沟通获取需求的方法 访谈方式：是最早开始使用的获取用户需求的技术。 访谈有两种基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 与用户沟通获取需求的方法 调查表: 经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户。 情景分析技术: 对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。 3.2.3 简易的应用规格说明技术 背景问题： 用户处于被动地位； 用户往往有意无意地与开发者区分“彼此”，不像同一个团队。 规格说明技术—面向团队的需求收集法。 优点： 开发者与用户不分彼此，齐心合作； 即时讨论并求精； 有能导出规格说明的具体步骤。 应用规格说明技术的典型过程 进行初步的访谈，初步确定待解决的问题的范围和解决方案。 开发者和用户分别写出“产品需求”。 以会议形式，邀请开发者和用户双方组织的代表讨论。 大家共同创建一张组合列表。 针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。 应用规格说明技术的典型过程cont 把与会者分成更小的小组，为每张列表中的项目制定小型规格说明。 全体与会者讨论各个小组的小型规格说明。 根据会议成果起草完整的软件需求规格说明书。 3.2.4 快速建立软件原型 快速建立软件原型是最准确