软件需求分析建模.ppt_第1页
软件需求分析建模.ppt_第2页
软件需求分析建模.ppt_第3页
软件需求分析建模.ppt_第4页
软件需求分析建模.ppt_第5页
已阅读5页,还剩37页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

学习任务3软件需求分析建模 主讲 陈荣保 需求分析 需求分析是指理解用户需求 就软件功能和性能与客户达成一致 估计软件风险和评估项目代价 最终形成开发计划的一个复杂过程 在这个过程中 用户处在主导地位 需求分析工程师和项目经理要负责整理用户需求 为之后的软件设计打下基础 需求分析阶段结束后 要求得到 用户需求说明书 和 需求规格说明书 两份文档 广义上 需求分析包括需求的获取 分析 规格说明 变更 验证 管理的一系列需求工程 狭义上 需求分析是指需求的获取 分析及定义的过程 需求分析的任务就是软件系统解决 做什么 的问题 就是要全面地理解用户的各项要求 并准确地表达所接受的用户需求的过程 需求分析 如果投入大量的人力 物力 财力和时间 而开发出的软件却没人要 那么所有的投入都是徒劳 如果费了很大的精力开发一个软件 最后却不能满足用户的要求 而要重新开发 那么这种返工是让人痛心疾首的 例如 用户需要一个响应时间快的软件 而在软件开发前期忽略了软件的性能要求 忘了向用户询问这个问题 想当然地认为是开发无响应时间这一性能要求的软件 如果当你千辛万苦地开发完成向用户提交时才发现出了问题 是要付出很大的代价的 所以 需求分析在软件开发过程中具有举足轻重的地位 具有决策性 方向性 策略性的作用 我们应对需求分析具有足够的重视 在一个大型软件系统的开发中 需求分析的作用要远远大于程序设计 需求分析建模 1 需求获取 3 需求分析 4 需求文档的编写 2 需求捕获技术 需求获取 开发软件项目关键的第一步工作是什么 软件的需求分析理解用户对软件提出的要求 需求获取 需求获取可能是软件开发中最困难 最关键 最易出错及最需要沟通交流的活动 对需求的获取往往有错误的认识 用户知道需求是什么 我们所要做的就是和他们交谈 从他们那里得到需求 只要问用户系统的目标特征 什么是要完成的 什么样的系统能适合商业需要就可以了 但是实际上需求获取并不是想象的这样简单 这条沟通之路布满了荆棘 需求获取 首先 需求获取要定义问题范围 而系统的边界往往是很难明确的 用户不了解技术实现的细节 这样将造成系统目标的混淆 其次 是对问题的理解 任何一个系统都会有很多的用户或者不同类型的用户 每个用户只知道自己需要的系统 而不知道系统的整体情况 他们不知道系统作为一个整体怎么样工作效率更好 也不太清楚哪些工作可以交给软件完成 他们不清楚需求是什么 或者说如何以一种精确的方式来描述需求 他们需要开发人员的协助和指导 但是用户与开发人员之间的交流很容易出现障碍 往往忽略了那些被认为是 很明显 的信息 最后 是需求的确认 需求的不稳定性往往随着时间的推移产生变动 使之难以确认 为了克服以上的问题 必须有组织地执行需求的获取活动 需求获取 1 确定需求开发过程 确定需求开发过程确定如何组织需求的收集 分析 细化并核实的步骤 并将它编写成文档 对重要的步骤要给予一定指导 这将有助于分析人员的工作 而且也使收集需求活动的安排和进度计划更容易进行 2 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标 所有的使用实例和功能需求都必须遵从能达到的业务需求 项目视图说明使所有项目参与者对项目的目标能达成共识 需求获取 3 用户群分类 产品的用户在很多方面存在着差异 例如 用户使用产品的频度 他们的应用领域和计算机系统知识 他们所使用的产品特性 他们所进行的业务过程 他们在地理上的布局以及他们的访问优先级 根据这些差异 你可以把这些不同的用户分成小组 用户类不一定都指人 你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员 以这种方式来看待应用程序接口 可以帮助你确定产品中那些与外部应用程序或组件有关的需求 将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况 要将可能使都有所差异 详细描述出它们的个性特点及任务状况 将有助于产品设计 需求获取 4 选择产品代表 择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策 这对于内部信息系统的开发是最易实现的 因为此时 用户就是身边的职员 而对于商业开发 就得在主要的客户或测试者中建立起良好的合作关系 并确定合适的产品代表 他们必须一直参与项目的开发而且有权作出决策 每一个产品代表者代表了一个特定的用户类 并在那个用户类和开发者之间充当主要的接口 需求获取 5 建立核心队伍 建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来 从他们那里收集目前产品的功能需求和非功能需求 这样的核心队伍对于商业开发尤为有用 因为你拥有一个庞大且多样的客户基础 与产品代表的区别在于 核心队伍成员通常没有决定权 6 确定使用实例 让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述 使用实例 讨论用户与系统间的交互方式和对话要求 在编写使用实例的文档时可采用标准模版 在使用实例基础上可得到功能需求 需求获取 7 召开应用程序开发联系会议 召开应用程序开发联系会议应用程序开发联系会议是范围广的 简便的专题讨论会 也是分析人员与客户代表之间一种很好的合作办法 并能由此拟出需求文档的底稿 该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践 8 分析用户工作流程 分析用户工作流程观察用户执行业务任务的过程 画一张简单的示意图 最好用数据流图 来描绘出用户什么时候获得什么数据 并怎样使用这些数据 编制业务过程流程文档将有助于明确产品的使用实例和功能需求 你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标 需求获取 需求人员 谁参加需求 需求获取 功能 功能性需求软件必须实现的软件功能非功能性需求系统的易用性 反应速度 容错性 健壮性等等质量属性 需求获取 非功能 需求获取 功能实例 需求获取 参与者 角色及其职责描述角色获取职责描述 谁使用了系统的主要功能 谁来维护和管理系统使系统正常工作 哪些人对系统产生的结果感兴趣 角色要求系统提供哪些功能 角色在系统中的工作是什么 角色的某些功能是否必须被系统自动实现 需求获取 角色职责分析实例 需求获取 业务数据 流程 业务流程描述业务处理过程业务数据及关系找出元数据 数据的数据找出中间数据 描述统计数据的数据找出元数据和中间数据的关系 需求获取 报表 学生成绩统计表 需求捕获技术 用户访谈收集资料问卷表小组会议 需求捕获技术 用户访谈 准备访谈计划访谈日程访谈开始和结束引导访谈 需求捕获技术 用户访谈 准备访谈在进行访谈前 需求分析者应该很好的理解行业的组织结构 行业定位 项目范围和项目目标 访谈会涉及下面内容 组织结构报告年度报告长期发展计划部门目标的陈述已有程序手册已有系统的演示已有系统文档需求分析者应该理解一般的行业术语 术语表 并且还要熟悉行业上的业务问题 需求捕获技术 用户访谈 计划访谈日程准备列表 列出主要话题或问题 这些问题可以找出未意识到的重点 还能有逻辑的引导访谈进行 安排访谈应遵循自上而下的进行 首先访谈部门或地区的领导 然后才是他们下属的雇员 在邀请对方进行会谈时 要解释这次会谈的目的 一般会涉及哪些领域 以及大致需要的时间等 需求捕获技术 用户访谈 访谈开始和结束陈述访谈的目的 谈谈被访谈者关心的事 讨论他们所熟悉的日常工作的过程 怎样的变化将使你的工作更简单或更有效 暗示被访谈者提出改进意见 当列表中的所有领域都讨论过后 提出下面问题 还有什么问题我们没有讨论吗 或是 我们还需要讨论些别的内容吗 结束会谈时 简短的总结讨论过的问题 重点指出会谈的要点 并说出你的理解 最后 你必须感谢被访谈者参加这次访谈 需求捕获技术 用户访谈 引导访谈避免提封闭性的问题询问开放性的问题使用适当的表达重述被访谈者的回答有效的使用沉默 需求捕获技术 收集资料 收集用户的书面需求文档收集用户现在的业务操作流程及其改进意见文档收集用户现在使用的数据表和文件及其格式 并确定数据的来源 需求捕获技术 问卷表 需访谈的个体太多需要回答容易确定的细节问题当你希望有个详细的结果时使问卷表尽可能的简短 用多个短小的问卷表替代一个长的问卷表 如果在回答了前15 20个问题后 长的问卷表会使用户感觉厌烦 他们就不会对其余的问题做出正确的判断 通常 一个问卷表包含的问题不超过10 15 需求捕获技术 小组会议 小组会议一般在下列情况中使用 信息平均的分布一小部分人中 无法个别的会见所有的涉众 一系列的访谈已经结束 团队需要在同一平台下得到所有的回答者 需求分析 用例分析建立用例模型编写用例描述数据流程分析数据流程图实体 关系分析 1 数据对象 属性与关系 2 实体 关系图 获取角色获取用例创建用例图 需求分析 用例图实例 需求分析 用例描述实例 需求分析 用例描述实例 需求分析 数据流程图的基本图例符号数据流程图画法 工具MicrosoftOfficeVisioPowerDesigner 需求分析 实例 0层数据流图 需求分析 实例 1层选课数据流图 需求分析 实例 1层成绩数据流图 需求分析 实体 关系图 需求文档的编写 编写用户需求报告系统概述 目标 名词解释 产品应当遵循的标准或规范 功能需求非功能需求功能需求描述 业务流程分析 数据需求 用户权限 报表需求 编写需求规格说明书概述 产品范围 产品中的角色 目标系统的功能需求目标系统的非功能性需求目标系统的界面与接口需求目标系统的约束条件需求建模与分析报告实例 小结 在需求获取和分析过程中 要对问题进行评估 对方案进行综合 在整个过程中 分析师关注的焦点是 做什么 而不是 怎么做 系统必须完成什么功能 会产生什么数据 将定义什么界面 会遇到什么约束等 总之 在这一阶段主要经历集中在获取和分析系统的逻辑功能上 不要把 用计算机如何实现 这样的物理因素牵扯进来 影响逻辑功能的分析 练习 1 完善选课系统的功能性需求 获取学生工作管理系统的功能性需求 2 获取学生工作管理系统完善选课系统的非功能性需求 3 完善选课系统的角色 获取学生工作管理系统的

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论