三结构化需求分析获取PPT课件

1 第三章结构化需求分析 问题1软件需求分析的定义 问题2什么是需求 问题3需求获取的目的是什么 问题4需求获取面临的问题是什么 困难性 问题5需求获取的东西是什么 问题6需求获取应该遵循的原则 问题7好的需求获取技术的基本特征问题9什么是用况 usecase 2 是指从用户给出的需求陈述出发 经过用户与软件开发人员的合作 由非形式的 不精确的 不完整的陈述逐步转化为完整的 很可能采用一些半形式以及形式的表示方法表述的软件需求定义的过程 需求分析是软件定义时期的最后一个阶段 是回答 系统必须做什么 的问题 软件需求分析位于软件开发的前期 它的基本任务是准确的定义未来系统的目标 确定为了满足用户的需要系统必须做什么 问题1软件需求分析的定义 3 喂 是Phil吗 我是人力资源部的Maria 我们在使用你编写的职员系统时遇到一个问题 一个职员想把她的名字改成SparkleStarlight 而系统不允许 你能帮帮忙吗 她嫁给了一个姓Starlight的人吗 Phil问道 不 她没有结婚 而仅仅是要更改她的名字 Maria回答 就是这问题 好像我们只能在婚姻状况改变时才能更改姓名 当然是这样 我从没想过谁会莫名其妙地更改自己的姓名 我不记得你曾告诉我系统需要处理这样的事情 这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框 Phil说 4 Maria说 我想你当然知道每个人只要愿意都可以随时合法更改他 她 们的姓名 但不管怎样 我们希望在下周五之前解决这个问题 否则 Sparkle将不能支付她的账单 你能在此前修改好这个错误吗 这并不是我的错 我从来不知道你需要处理这种情况 我现在正忙着做一个新的性能检测系统 并且还要处理职员系统的一些需求变更请求 传来翻阅稿纸的声音 我还有别的事 我只可能在月底前修改好 一周内不行 很抱歉 下次若有类似情况 请早一些告诉我并把它们写下来 那我怎么跟Sparkle说呢 Maria追问道 如果她不能支付账单 那她只能挂帐了 Maria 你要明白 这不是我的过错 Phil坚持道 如果你一开始就告诉我 你要能随时改变某个人的名字 那这些都不会发生 因此你不能因我未猜出你的想法 需求 就责备我 Maria不得不愤怒地屈从 好吧 好吧 这种烦人的事使我恨死计算机系统了 等你修改好了 马上打电话告诉我 行吧 5 如果作为客户有过类似的经验 你一定知道 一个不能进行一项基本操作的软件产品是多么令人烦恼 尽管开发者最终会满足你的要求 你也不会感谢他 但从开发者角度来看 在整个系统已经完成后 用户再提出对功能的进一步要求是多么烦人的事 同时 修改系统的请求迫使你放下当前的项目 而且往往修改请求还要求你优先处理 也是令人很不愉快的 其实 在软件开发中遇到的许多问题 都是由于收集 编写 协商 修改产品需求过程中的手续和作法 方法 失误带来的 例如上面的Phil和Maria 出现的问题涉及到非正式信息的收集 未确定的或不明确的功能 未发现或未经交流的假设 不完善的需求文档 以及突发的需求变更过程 6 问题2什么是需求 需求 就是对系统特征以及为了完成用户任务 系统必须能够做什么的一个描述 它关心的是系统的目标而不是系统的实现 对软件进行需求分析实际上分为两个阶段 需求获取与需求规约 需求验证 7 问题3为什么说需求分析是重要的 系统开发团队之所以进行需求分析 是因为他们想让项目获得成功 满足项目需求即为成功打下了基础 若无法进行需求分析 达到目标的几率就会降低 StandishGroup从1994年到1997年的CHAOSReports证实 导致项目失败的最重要的原因与需求有关 1997年12月 ComputerIndustryDaily报导了SequentComputerSystems公司的一项研究 该公司对美国和英国500名IT经理作调查后发现 百分之七十六的受访者在他们的事业中经历过完全的项目失败 其中提到最多的导致项目失败的原因就是 变更用户需求 为什么要进行需求分析 避免失败就是一个很充分的理由 提高项目的成功率和进行需求分析带来的其他好处同样也是理由 StandishGroup的CHAOS报告进一步证实了与成功项目关系最大的因素是良好的需求分析 8 开发复杂的软件系统 业绩总不令人满意在美国 每年花费超过 2500亿开发175 000个IT项目 只有16 的项目能够按时 按预算 满足要求地交付 大约31 的项目在完成之前被取消 52 7 的项目成本是原来预算成本的189 项目失败的主要原因缺乏用户参与 占所有项目的13 不完整的需求和规格说明 占所有项目的12 不断改变的需求和规格说明 占所有项目的12 9 1 软件生命周期中 一个错误发现得越晚 修复错误的费用越高 生命周期中修复软件的相对费用 关于软件需求分析是重要的有4个事实 10 2 许多错误是潜伏的 并且在错误产生后很长一段时间才被检查出来 3 在需求过程中会产生很多错误DeMarco在一份研究报告中指出 被检查出来的错误的56 产生的根源可以追溯到需求阶段 AIRMICS所进行的一项调查发现 在一份美国军方大型管理信息系统的需求现格说明书 SRS 中存在着500多个错误 当然这仅仅是一个软件项目中的一次调查 11 4 在需求阶段 代表性的错误为疏忽 不一致和二义性美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究 他们对海军A 7E 它机上的 宅行操作程序进行实地测试 以验证许多新设想的可行性 得出的研究数据表明 A 7E项目中77 的需求错误特点是不明确 疏忽 不一致和二义性 按错误类型对这些错误分布进行分析的结果是 49 不正确的事实 31 疏忽 l3 不一致 5 二义性 12 需求错误是可以被检查出来的 发现错误的比例 13 需求获取的目的清楚的理解所要解决的问题 完整的获取用户需求 主要包括以下几个活动 学习请教领域专家向用户提问考察现场市场调研等 问题4需求获取的目的是什么 14 问题空间理解 人与人之间的通信 需求的不断变化 问题5需求获取面临的问题是什么 困难性 15 16 17 18 19 功能需求定义了系统做什么 包括系统的所有功能 性能需求包括系统对效率 可靠性 安全性 可维护性 可移植性 吞吐量以及符合某种标准等的要求 问题6需求获取的东西是什么 20 分析问题和需求的能力取决于分析人员的思维和经验 其中 好的思维包括 划分 捕获问题空间的 整体 部分 关系是降低问题复杂性的基本途径之一 抽象 捕获问题空间的 一般 特殊 关系是认识 构造问题的一般途径 投影 捕获问题空间的多维 视图 是描述问题的基本手段之一 问题7 需求获取应该遵循的原则 21 好的思维来源于 严谨 逻辑和 活跃 的思考习惯 严谨要求思考的对象应该是不放过任何一个 小 问题 逻辑要求思考的过程应该是一种符合规则的推导过程 活跃思维要求思考的方式应该是并行的 即不是仅一个角度 而是多个角度来思考问题经验来源于 开发了一些软件并善于总结 创新与教训 跟踪最新技术 22 方便通讯 使用易于理解的语言 提供定义系统边界的方法提供划分 抽象 投影等方法允许采用多种可供选择的设计方法适应需求的变化支持使用问题空间的术语 思考问题和编制文档 问题8好的需求获取技术的基本特征 23 需求获取的技术 象系统相关者进行问卷调查主持与用户的面谈和讨论需求专题讨论会复查现有的报表 表格和过程描述观察商业过程和工作流程应用用例建立原型 24 当软件的使用者考查一个软件产品的功能时 其考虑的内容通常包括 软件的功能的设置的合理性软件的运行效率软件功能使用的方便程度这些内容是软件产品的外部特性 是软件系统通过其边界呈现给用户的特性 外部特性通常是动态的 通过外部特性 软件系统的使用价值得到了体现 呈现在软件系统的边界上的外部特征 是由软件系统的内部实现决定的 但是 对于软件系统的使用者而言 软件功能的内部实现不是他们关心的问题 他们所关心的只是其所需要的功能是否以令其满意的方式得到了实现 问题9什么是用况 usecase 25 分析软件系统的功能设置时 应该把重点放在描述软件系统的外部边界上 即重点考虑用户对软件系统的功能设置的合理性 方便性和运行效率的要求 而不应该在需求分析阶段就过多地考虑软件系统的结构和内部实现机制 这是在对软件系统进行需求分析时 应该遵循的一个重要原则 26 软件系统不是孤立存在的 它的使用价值是通过和它所存在的环境发生交互实现的 因此在描述软件系统的边界 分析软件系统应具备的功能时 应首先分析软件产品与外界环境的联系 发现外界环境中哪些对象将和软件系统产生交互 不但需要分析共有哪些用户将要使用软件系统 而且还需要分析软件系统的运行结果将要对哪些对象产生影响 这包括 指定运行结果的输出和存储的媒介指定被软件系统运行结果控制的硬件设备如显示器 打印机 工业机器人 数控机床等 27 当提取出了软件系统运行的外部环境中与之交互的对象之后 需要为这些对象与软件系统进行的交互指定具体内容 这包括 1 对交互中包含的动态行为进行详细描述 2 还包括对这些动态行为进行合理的分类和组织以使得这些动态行为所代表的软件系统的功能的设置能为用户提供其所需的价值 并具备令用户满意的易用性和效率对软件产品的需求分析就是定义软件系统的边界 包括两个方面的内容 一 分析软件产品与外界的联系二 确定软件产品与外界的联系时包含动态行为及其相互关系 28 UseCase主要用于促进和用户的交流 沟通 为此使用了一种用户和开发人员都能理解方式描述系统功能和行为 UseCase可以划分系统与外部参与者的界限 是系统开发的起点 而最终应该落实到类和实现代码上 UseCase既然是对系统行为的动态描述 因此它是类 对象 操作的来源 是系统分析和设计阶段的输入之一 是分析和设计 制定开发计划 测试计划 设计测试用例的依据之一 UseCaseModel是系统需求分析阶段的成果之一 UseCase不但有助于帮助分析员理清思路 验证用户需求 而且 也是开发人员之间进行交流的重要手段 29 一个USECASE表示了一个系统或其它语义实体 例如子系统或一个类 所提供的一块高内聚的功能 这个功能是通过该系统与一个或多个外部的交互者 称为参与者 之间所交换的消息序列 以及该语义实体所执行的一些动作给予表现的 可见 一个USECASE捕获了参与交互的各方关于其行为的一个约定 通过这一约定 描述了该语义实体在不同条件下