软件工程-3软件要求定义.ppt

第三讲 1 软件要求定义 学习内容 u可行性研究 u项目开发计划 u软件需求分析 2 软件要求定义 项目来源 合同：为别人做； 立项：为自己做； 失败：无盈利赔钱声誉影响官司 失败：尽赔钱公司倒闭东山再起难！ 学到的远比失去的多 ！ 3 软件要求定义 可行性研究（ Feasibility Study） 可行性研究的目的就是用最小的代价在 尽可能短的时间内确定该软件项目是否能 够开发，是否值得开发，最后给决策者提 供做与不做的依据。 可行性研究实质上是要进行一次简化、 压缩了的需求分析和设计过程，要在较高 层次上以抽象的方式进行需求分析和设计 过程。 4 软件要求定义 可行性研究的任务 首先需要进行概要的分析研究，初步确定项 目的规模和目标，确定项目的约束和限制。 然后进行简要的需求分析，抽象出该项目的 逻辑结构，建立逻辑模型。 最后从逻辑模型出发，经过压缩的设计，探 索出若干种可供选择的主要解决办法，对每种 解决方法都要从以下三方面研究它的可行性。 u技术可行性 u经济可行性 u社会可行性 5 软件要求定义 技术可行性 u在现有资源条件下，项目能否 实现，风险有多大（技术、资源 是否成熟）。 社会可行性 u是否存在侵权、软件操作方式 是否适合用户所在组织、现有管 理制度、人员素质是否可行？ 6 软件要求定义 经济可行性（成本效益分析） 成本效益分析首先是估算将要开发的系统 的开发成本，然后与可能取得的效益进行比较 和权衡。效益分有形效益和无形效益。有形效 益可以用货币的时间价值、投资回收期和纯收 入等指标进行度量；无形效益主要从性质上、 心理上进行衡量，很难直接进行量的比较。 货币的时间价值：通常用利率表示。 F=P(1+n i) 不计复利 投资回收期：就是使累计的经济效益等于最初 的投资费用所需的时间。 纯收入：就是在整个生存周期之内的累计经济 效益（折合成现在值）与投资之差。 7 软件要求定义 提示 不是解决问题，而是确定是否可解值得解 所以不要花过多精力，占总成本的 5 10 % 例：实践性大作业 3 方面考虑： 技术上- 23 学生, 7 周, 电脑, 开发经验 ， 决心，风险（影响其它课程） 社会上- 产品有没有人用 经济上 - 预算, 盈利, . 8 软件要求定义 可行性研究的具体步骤 1、确定项目规模和目标，明确限制和约束。 我们认为用户要的 用户要的 2、研究老系统 解决老系统问题 老系统 功能 新增 功能 注： 注意 了解与 其它系 统的接 口。 新系统效益 老系统效益 9 软件要求定义 可行性研究的具体步骤 3、导出高层逻辑模型(conceptual design) 抽象 实现 改进 老系统模型 新模型 新系统 应该告诉用户“What”而不是“How”10 软件要求定义 系统流程图（事务图） 高层逻辑模型 11 软件要求定义 可行性研究的具体步骤 3、逻辑模型 4、复查和重新定义 1、复 查定义 注：此时合同未签，应考虑成本， 不宜反复太多次。 5、导出和评价多种解法 进度表经济上合算 技术上可行 操作上可行 技术上不可行 用户 不 可能 操作 不合算 12 软件要求定义 可行性研究的具体步骤 6、推荐行动方针 Yes or No? No Yes Why? Which one is the best? Why? (cost / benefit) 8、审查、存档 7、编写可行性报告（开发计划 ） 任务分解，确定负责人 大致进度规划 财务预算 风险分析及对策 粗略 13 软件要求定义 文档：可行性报告 参考GB856788中的可行性研究报 告，进行适当裁剪。 14 软件要求定义 项目开发计划 是对开发项目的费用、时间、进度、人 员组织、硬件设备的配置、软件开发环境 和运行环境的配置等进行说明和规划。 是项目管理人员对项目进行管理的依据 ，据此对项目的费用、进度和资源进行控 制和管理。 工具：Project 15 16 软件要求定义 注意事项 标书 ：我国对软件成本认识不足 人月不能互换：需求的变更、人员的流动、 环境的变化； 困难：就是缺乏数据估计，导致估计不科学 ； 估算项目复杂度（熟悉程度）、规模 17 软件要求定义 软件需求分析：“做什么？” 需求分析的过程是开发人员与用户共同协 商，明确系统的全部功能、性能以及运行规 格，并且使用软件开发人员和用户都能理解 的语言准确地表达出来，即完成需求规格说 明的过程。 18 软件要求定义 软件需求重要性例子 “喂，是Jack吗？我是人力资源部的Tom,我们在使用 你编写的职员系统时遇到一个问题，一个职员想把她 的名字改成Sparkle Starlight,而系统不允许，你能 帮帮忙吗？” “她嫁给了一个姓Starlight的人吗？”Jack问道。 “不，她没有结婚，而仅仅是要更改她的名字， ”Tom回答，“就是这问题，好象我们只能在婚姻状况 改变时才能更改姓名。” “当然这样，我从没想到谁会莫名其妙地更改姓名 ，我也不记得你曾告诉我系统需要处理这样的事情。 ”Jack说。 Tom说：“我想你当然知道每个人只要愿意都可以随 时合法更改其姓名。但不管怎样，你在本周五之前解 决这问题，否则Sparkle不能支付她的帐单。” “这不是我的错！我现在正忙着做一个新的系统， 还要做一些别的需求变更请求。很抱歉，只能下周才 能修改。” 19 软件要求定义 故事带给我们的启示 u影响：作为客户，很恼火，因为软件系统不 能进行一项基本的操作。哪怕开发者给其解决 了，也不会感谢他。作为开发者，也很烦人， 迫使你增加了当前的工作，又要你优先处理。 u原因：由于收集、编写、协商、修改需求过 程的手续或方法失误带来的。这里是非正式信 息的收集、未确定或不明确的功能、未发现或 未经交流的假设、不完善的需求文档，以及突 发的需求变更过程所造成的。 u解决办法：重视需求分析，派经验丰富的人 员做，最大程度的减少类似情况发生。 20 软件要求定义 定值整定 u原则1：按与相邻接地距离保护配合整定； u原则2：按相邻零序电流保护配合整定； 1 2 3 u1与2配； u1与3配； 方案1： 原则相邻线 方案2： 相邻线原则 21 软件要求定义 需求分析的特点 老问题： 问题的复杂性 交流障碍（讲究技巧和原则） 不完备性和不一致性 需求易变性（动态性） 派经验丰富的 人去干！ 系统分析员 22 软件要求定义 软件需求的任务 理解、分解、表达、评审 whf: 划分系统所有 1.问题识别：双方确定问题的综合需求。 功能需求：系统必须做什么？ 性能需求：做得怎样？ 例：response time , memory , back-up memory , 环境需求：运行环境、软硬件配置等。 用户界面需求 可靠性、安全性、保密性、可移植性和可 维护性等方面的需求。 将来可能提出的要求 共同理解！ 23 软件要求定义 软件需求的任务 2.分析与综合:导出软件的逻辑模型。对 获取的需求进行一致性的分析检查， 在分析、综合中逐步细化软件功能， 划分成各个子功能。也对数据域进行 分解，分配到各个子功能上，并用图 文结合的形式，建立起新系统的逻辑 模型。 24 软件要求定义 软件需求的任务 3.编写文档： 编写需求说明书 编写初步用户使用手册 编写确认测试计划 修改完善项目开发计划 25 软件要求定义 需求文档 用户需求报告需求规格说明书 对外的，验收依 据 对内的，设计依 据 是合同的产物是立项建议书的 产物 由用户需求报告可产生需求规格说明 书 当前系统，目标 系统 目标系统（数据 字典，算法分析） 26 软件要求定义 软件需求的任务 u验证需求的一致性 u验证需求的完整性 u验证需求的现实性 u验证需求的有效性 方法： 人工审查 开发原型系统探索型 使用软件工具 完整性、一致性 基线 4.技术审查和管理复审 27 软件要求定义 需求分析的方法 结构化分析方法：由数据流和数据字典 构成，适于数据处理领域问题。但该方 法的一个难点是确定数据流之间的变换 ，而且数据字典的规模也是一个问题， 对数据结构的强调很少。 功能分解法：系统功能子功能功 能接口。过程抽象观点，很难与软件设 计明确分离。基点放在功能上，不稳定 ，难以适用需求的变化。 28 软件要求定义 需求分析的方法 信息建模方法：从数据角度来对现实世界 建模。基本工具是E-R图，数据不封闭，每 个实体和它的属性的处理需求不是组合在 同一实体中，没有继承性和消息传递机制 来支持模型。是面向对象分析的基础。 面向对象的分析：采用了实体、关系和属 性等信息模型分析中的概念，同时采用了 封闭、类结构和继承性等面向对象程序设 计语言中的概念。 29 软件要求定义 ER模型（Entity-Relationship Approach ） 实体：客观世界中存在且可相互区分的事物 。 用矩形框代表。 联系：事物间是有联系的。(1:1、1:N、M:N) 用连接相关实体的菱形框表示。 属性：实体或联系所具有的性质。 用椭圆形或圆角矩形表示。 教师师学生 课课程 教学 学号 职职称 成绩绩 学分 1 N N M 30 软件要求定义 注意事项 在需求分析时要注意用户对软件开发的了解程度。 避免造成两种极端认识。 需求的变动或新增是一个极为普遍的问题，既然普 遍，所以软件开发人员不仅应该在心理上接受这种变 动，还应该在需求分析时积极的发掘需求。 需求人员与用户广泛交流，从深度和广度挖掘可能的 需求，并应形成规范的需求文档，经用户确认。 如果为写文档而写文档，不进行及时更新，甚至准 备在软件开发完成后再补文档，这是绝对错误的观 点。 31 软件要求定义 可能错误 没有足够用户从参与（类型、数量） 开发方与用户沟通可能处于劣势 不要锦上添花，画蛇添足 不要写的过于简练，过于模糊； 计划需求的时间少了，导致需求不完整 另外，要注意： 需