系统开发中的需求分析与管理(一) PPT课件VIP

第九章系统开发中的需求分析与管理 一 需求工程概述二 需求开发三 需求管理四 需求工程方法与工具 一 需求工程概述 一 需求工程概述 1 什么是需求基本概念 宽泛地讲 需求来源于用户的一些 需要 这些 需要 被分析 确认后形成完整的文档 该文档详细地说明了产品 必须或应当 做什么 需求可能来自以下几个方面 用户 客户 接口 环境 硬件 组织文化 政策等 需求的重要性 开发软件系统最困难的部分就是准确说明开发什么 最困难的概念性工作是编写出详细的需求 包括所有面向用户 面向机器和其它软件系统的接口 此工作一旦做错 将会给系统带来极大的损害 并且以后对它修改也极为困难 Brooks 没有银弹 案例 凭空想象的需求一家大型电信设备企业有多个分支机构 A与B是研发机构 B是核心平台的研发机制 A做增值业务的研发 C是整个公司的项目管理机构 负责立项 结项与经费管理 D是销售机构 B研制出一种数据接入服务器的原型 找到A 说该产品市场前景看好 请你们开发网管软件 一起做好产品 D对A B说 你们把软硬件都做好 我负责销售 挣到钱大家分 于是A决定参与合作 向C提出立项 立项后 A把该项目外包给一家专业的网管软件开发公司E 预期半年完成 由于网管软件要运行于B的产品上 A与E派出开发人员到B处进行需求分析 而B的产品还是原型并不成熟 不断在变化 最终用了1年时间才完成软件开发 开发完成后 E将软件交付给A后 A付清开发费用 再把软件交付到D D又卖给某电信局F 结果F对软件的功能不满意 要求按自己的要求修改后才能付钱 D不得不要求A修改软件 而A已经将开发费用付给了E 只能自己吞苦果 结果是A想办法把软件转让给B 希望拿出成本并且以后再也不与B合作 这在很多大企业中都是普遍发生的事实 产品是闭门造车出来的 根本没有弄清楚要开发的系统应该是什么样的 一 需求工程概述 2 系统需求的来源1 客户 购买系统的人 2 用户 实际使用系统进行日常业务活动的人 3 技术人员 维护系统运行的人 4 其他系统相关者 一 需求工程概述 3 需求工程1 基本概念 在软件开发的生命周期中 与需求直接相关的活动 主要包括 需求开发和需求管理两部分内容 一 需求工程概述 3 需求工程 需求开发过程 通过调查与分析 获取用户需求并定义产品需求 需求调查的目的是通过各种途径获取用户的需求信息 原始材料 产生 用户需求说明书 需求分析的目的是对各种需求信息进行分析 消除错误 刻画细节等 常见的需求分析方法有 问答分析法 和 建模分析法 两类 需求定义的目的是根据需求调查和需求分析的结果 进一步定义准确无误的产品需求 产生 产品需求规格说明书 系统设计人员将依据 产品需求规格说明书 开展系统设计工作 一 需求工程概述 3 需求工程 需求管理过程 在客户与开发方之间建立对需求的共同理解 维护需求与其它工作成果的一致性 并控制需求的变更 需求确认是指开发方和客户共同对需求文档进行评审 双方对需求达成共识后作出书面承诺 使需求文档具有商业合同效果 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系 建立与维护 需求跟踪矩阵 确保产品依据需求文档进行开发 需求变更控制是指依据 变更申请 审批 更改 重新确认 的流程处理需求的变更 防止需求变更失去控制而导致项目发生混乱 一 需求工程概述 3 需求工程2 需求工程的主要内容 需求开发产生的主要文档为 用户需求说明书 与 软件需求规格说明书 需求管理产生的主要文档为 需求评审报告 需求跟踪报告 和 需求变更控制报告 一 需求工程概述 4 需求工程中的主要问题知识技能问题态度问题合作关系用户说不清楚需求双方误解需求开发人员写不好需求文档用户经常变更需求 知识技能问题 应用域的知识是无边无际的 任何人都不可能是 万事通 俗话说 隔行如隔山 需求分析员可能是某一领域的专家 但当他接手陌生的业务时 他可能是个 无知 者 一个企业要谋求发展 不能总在做老的业务 人一生中会有许多充满挫折的 第一次 不可以逃避 当需求分析员缺乏应用域知识时 他该怎么办 首先要有勇气做事 否则连实践的机会都没有 其次应当赶紧补习应用域知识 不论是通过自学还是培训的方式 否则他很难与用户交流 如果可能的话 开发方最好请既懂软件又懂应用域知识的行家来帮忙 态度问题 相当多的开发人员习惯于被动地对待需求开发 每当遇到麻烦 挫折时 他们会发牢骚 找出一堆用户的毛病 很多开发人员错误地以为 需求是用户的事情 不是我们的事情 我们为用户开发软件 难道用户不该告诉我们应当开发什么吗 如果用户说不清楚需求 或者经常变更需求 这类问题是用户产生的 应当由他们自己负责 用户说不清楚需求或者需求发生变更 这些都是常见的问题 并不是绝症 是人们可以设法解决的 可悲的是开发人员把这些问题当成了借口 不愿主动攻克问题 导致需求问题扩散到整个软件开发过程 产生太多的后患 软件企业的领导应当给具有错误观念的开发人员们洗脑 需求分析员的天职就是在有限的时间内获取准确而细致的用户需求 如果做不到就是失职 不要找借口 合作关系 如果需求分析员不能与用户建立良好的合作关系 那么他们在需求开发过程中会很疲惫 倘若用户不能很好地配合需求分析员 那并不表示他是个坏蛋 因为用户有他自己的想法 我回答了你们的问题 讲了该讲的 我们付钱给你们 难道还要我伺候你们不成 我还要干自己的事情 别打扰我了 你们自己想办法把活干好吧 对于一些竞标项目 在合同未签订之前的需求开发工作尤为困难 用户未必会买你的产品 他不会投入很多精力来协助你搞需求开发 需求分析员不是销售人员 他们不可能象销售人员那样通过某些手段笼络住用户就能成功 出色的需求分析员不仅要有过硬的专业知识 还要具备较强的交流 沟通能力 开发方与用户的合作关系对需求开发而言是至关重要的 对于重大的 复杂的项目 我们不能完全期望双方能够自发地建立起良好地合作关系 这样风险太大 开发方和用户方在开展需求开发之前 双方协商并撰写 用户在需求工程中的权利与义务 即以协议的方式确定合作关系 好话 和 丑话 都说在前头 这样能减少今后的摩擦 如果条件允许的话 开发方最好为用户举办关于需求工程的培训 合作关系 用户在需求工程中的 权利 1 有权要求开发方派遣资质合格的需求分析员和相关人员 2 有权要求开发方采用用户熟悉的语言来描述需求 即开发方必须提供用户看得懂得需求文档 3 有权审查需求文档 并对有争议的需求作出决策 如果认为需求文档不能准确地反映用户真实的意愿 可以拒绝在需求文档上签字 4 如果用户想要变更需求 有权要求开发方对该变更将产生的影响作出真实可信的评估 以便用户决定是否变更需求 用户在需求工程中的 义务 1 以积极友善的态度与开发方人员交流 协作 尽可能地为开发方人员提供工作和生活上的便利 2 乐意接受需求分析员的采访 在不泄漏机密的前提下尽可能地回答需求分析员的问题 3 在不泄漏机密的前提下 尽可能地向需求分析员提供与需求相关的材料 4 与需求分析员共同评审需求文档 确保需求文档准确地反映用户真实的意愿 用户说不清楚需求 用户说不清楚需求是普遍现象 这是让开发人员头痛的大问题 有些用户真的不知道需求是什么 或者对需求只有朦胧的感觉 他当然说不清楚需求 有些用户虽然心里明白想要什么 但却说不清楚需求 系统分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作 否则会连累整个开发团队的 无论是什么原因导致用户说不清楚需求 系统分析员必须设法搞清楚用户真正的需求 这是系统分析员的职责 也是职业的挑战 双方误解需求 了解需求的过程中会发生 问非所求 答非所问 的事情 开发人员写不好需求文档 需求调查工作不充分 获取的需求信息太少或者太乱 以至于写不成需求文档 要想写出好的需求文档 前提条件是把需求调查工作做好 企业应当提供合适的文档模板以及比较好的示例文档 尽可能地降低写作难度 用户经常变更需求 需求变更通常会对项目的进度 人力资源 经费产生很大的影响 如果在项目开发的初始阶段 开发人员和用户没有搞清楚需求或者搞错了需求 到了项目开发后期才将需求纠正过来 导致产品的部分内容需要重新开发 毫无疑问 这种需求变更将使项目付出额外的代价 需求变更并不可怕 可怕的是需求变更失去控制 导致项目混乱 所以需求变更控制是需求工程的重要活动 用户经常变更需求 需求变更通常会对项目的进度 人力资源 经费产生很大的影响 如果在项目开发的初始阶段 开发人员和用户没有搞清楚需求或者搞错了需求 到了项目开发后期才将需求纠正过来 导致产品的部分内容需要重新开发 毫无疑问 这种需求变更将使项目付出额外的代价 需求变更并不可怕 可怕的是需求变更失去控制 导致项目混乱 所以需求变更控制是需求工程的重要活动 一 需求工程概述 5 需求工程的层次开发者对待需求工程的态度可分 被动型 主动型 和 领先型 三种 只有后两种才有可能开发出成功的产品 被动型 是指开发者被动地对待需求工程中的各项活动 能少干则少干 能偷懒则偷懒 他们认为需求是用户的事情而不是自己的事情 开发过程中经常发生需求变更 导致产品迷失方向 不是半途而废就是陷入半死不活的状态 主动型 是指开发者积极地开展需求工程中的各项活动 他们把获取准确的需求当作自己的职责 会想尽一切办法克服需求开发和需求管理过程中的困难 而不是找借口推卸责任 俗话说 良好的开端是成功的一半 主动型 需求工程是开发成功产品的必备条件 领先型 是需求工程的最高境界 开发者发掘了连用户自己都没有意识到的需求 导致用户跟着新产品跑而不是新产品围着用户转 这叫引导消费 需求工程做到这个份上 才能使产品立于不败之地 长盛不衰 二 需求开发 1 需求的获取一般地 分析员首先要通过与用户面谈 问卷调查等方式获取需求 通过对这些需求进行记录与定义并进行讨论与修正 将未解决的问题放在一个条目中 等下一次调查解决 通过多次迭代最终得到完整的系统需求 1 需求获取规程现代软件系统分析与开发一般都遵循一定的范式和规程 在需求调查阶段 一般按以下规程进行 二 需求开发 1 需求的获取2 调查准备 1 需求分析员应当起草需求调查问题表 将调查重点锁定在该问题表内 否则调查工作将变得漫无边际 问题表可以有多份 随着调查的深入 问题表将不断地被细化 根据经验 用户通常没有耐心回答复杂的论述题 所以问题表应当以 选择题 和 是非题 为主 制定问题表最简便的方法就是从 用户需求说明书 的模板中提取需求问题 二 需求开发 1 需求的获取2 调查准备 2 确定调查方式 调查的方法有 问卷调查复查现有报表和业务过程的描述与用户面谈与讨论观察与记录业务过程与同行或专家交谈 听取意见与建议分析已经存在的软件系统 提取需求从行业标准和规则中提取需求到Internet上查找相关信息 二 需求开发 1 需求的获取2 调查准备 2 确定调查方式 辅助调查的方法有 可通过原型的方法获取需求 这对于 说不出需求 的用户尤其适用 JAD 联合应用开发会议 是加快调查的重要方法 即将相关人员全部召集在一起参加单一会议直接解决需求分析问题 二 需求开发 1 需求的获取2 调查准备 3 需求分析员与被调查者建立联系 确定调查的时间 地点 人员等 撰写需求调查计划 要特别留意的是不要漏掉典型的用户 二 需求开发 1 需求的获取3 调查与记录准备工作完毕后 需求分析员按照计划执行调查 在调查过程中随时记录 或存储 需求信息 通过完成计划的调查任务 系统分析员获取用户需求并将其正确的记录 记录形式一般为表格 二 需求开发 1 需求的获取3 调查与记录面谈中要注意的问题 注重时间与礼节 建立与用户的良好关系事先了解用户的身份 背景从宏观入手 然后细化 而不是象侦探那样从蛛丝马迹着手轻松的气氛 不轻意打断用户的谈话不为用户添加必要的麻烦 但也不要因怕麻烦而降低调查力度 二 需求开发 1 需求的获取3 调查与记录调查的技术 问答分析法 通过提问与回答了解系统需求 最主要的问题是 是什么 和 为什么 每个需求都用陈述句说明 是什么 如果表达不清 则加上 不是什么 如果 是 与 不是 不是理所当然的 就必须加上解释 为什么 目标 获得正确 清晰的需求 其他常见问题 需求存在二义性吗 需求文档的上下文有矛盾吗 需求完备吗 需求是必要的吗 需求可实现吗 需求可验证吗 需求的优先级确定了吗 二 需求开发 2 需求冲突的解决需求从获取渠道收集到以后 可能产生不一致的地方 解决原则主要有 当客户需求与开发方预计需求冲突时 以客户需求为主 用户间需求冲突则以级别大的用户需求为准 同级则少数服从多数 多个客户以出钱多的客户需求为准 二 需求开发 3 用户需求说明书对收集到的用户需求进行分析 归纳与总结 然后根据一定的格式撰写 用户需求说明书 调查过程中的中间资料可作为附件 用户需求说明书完成后 应邀请专家与用户对其进行评审 使其最大限度地符合用户的真实意愿 之后才能进行进一步的需求分析与定义 产生 软件需求规格说明书 模板 二 需求开发 4 需求分析与定义1 概述需求分析的结果是通过建立系统的逻辑模型来定义需求 逻辑模型 详细展示系统要完成的功能 而不依赖具体技术的模型 物理模型 表明系统是如何真正实现的模型 二 需求开发 4 需求分析与定义1 概述结构化分析方法兴盛的时期 软件系统的开发过程是从物理模型到逻辑模型 再从逻辑模型到新的物理模型的过程 这种方法可以保证系统分析能按步就班的完成 但缺点是a 系统分析时间较长 要花费更多时间与资金去分析 了解和记录旧系统的运行 提炼出运行逻辑 b 新系统往往是旧系统的简单自动化 不论原系统的效率有多低 是否合理 都原样地进入新系统 并不能通过信息化改造原来的业务管理流程 提高管理水平 不适合于全新系统的开发 特别是一些WEB项目 如电子商务方面的项目开发 这些项目没有可参考的旧系统 二 需求开发 4 需求分析与定义1 概述现代的需求分析过程 往往是直接在对用户需求进行收集地过程中直接产生新系统的逻辑模型 直接通过对比要解决的商业问题和软件需要实现的功能 系统分析员只有在需要理解商业业务流程时才去检查现有系统 系统分析员的焦点是 以新系统为中心 提出创新的问题解决之道是系统分析员的素质要求之一 此外 新系统的引入还可能对组织原来的业务流程进行改造 BPR 两种思维方式 还没有坏 就不需要修理总有一种更好的解决方法 案例 Ford的业务流程重组 20世纪80年代 福特北美分部的帐目支付部门雇佣了500多名员工 为了提高效率 公司决定引入信息系统 最初的目标是提高20 的效率 在项目小组进行系统分析时发现 马自达公司的帐目支付部门只有5名员工 虽然福特比马自达大得多 但相对于而言也达不到100倍的业务量 在借鉴了马自达的业务过程的同时 项目组设计了全新的自动化系统 将帐目支付功能包含在更大的购买功能中 实现了从购买到支付全程跟踪的自动化 项目结束时 只需求100人即可完成原来500多人才能完成的帐目支付功能 大大超出了预计 二 需求开发 4 需求分析与定义2 系统分析规程 二 需求开发 4 需求分析与定义2 系统分析规程第一步 细化并分析用户需求 需求分析员首先对 用户需求说明书 进行细化 对比较复杂的用户需求进行建模分析 以帮助软件开发人员更好地理解需求 建模分析产生的文档可以作为 产品需求规格说明书 的附件 补充说明 建模分析的技术难度比较高 分析员应当根据自身水平进行取舍 第二步 撰写产品需求规格说明书 需求分析员按照指定的文档模板撰写 产品需求规格说明书 如果待开发的产品分为软件和硬件两部分的话 则应当撰写 软件需求规格说明书 和 硬件需求规格说明书 第三步 进行需求确认 项目经理邀请同行专家和用户 包括客户和最终用户 一起评审 产品需求规格说明书 尽最大努力使 产品需求规格说明书 能够正确无误地反映用户的真实意愿 需求评审之后 开发方和客户方的责任人对 产品需求规格说明书 作书面承诺 二 需求开发 4 需求分析与定义3 需求分析方法文字描述 可从问答法直接获得 模型描述有些时候用语言描述某个问题特别费劲 而采用图形则使人一目了然 所谓 一图低千言 就是这个道理 在需求开发过程中 对于某些类型的信息 用图形表示要比文本表示更加有效 所以将图形与文本结合起来描述需求是很自然的方法 因此在需求分析中常使用建模的方法来定义需求 二 需求开发 4 需求分析与定义3 需求分析方法模型描述 1 需求建模 就是指用图形符号来表示 刻画需求 建模分析方法主要有两大类 结构化分析法 和 面向对象分析法 二 需求开发 4 需求分析与定义3 需求分析方法模型描述 2 结构化分析法结构化分析方法并不是明确地由涉及这个主题的一篇文章或者一本著作引入的 它也不是被所有使用者一致采用的单一方法 相反地 它是几乎发展了20多年的一个混合物 结构化分析方法在70年代和80年代非常流行 相关论著很多 Pressmen对结构化分析方法作了高度概括 一个中心三种图 二 需求开发 4 需求分析与定义3 需求分析方法模型描述 3 面向对象分析法面向对象分析设计 OOAD 方法兴起于20世纪80年代 从90年代起至今它已经在分析设计领域占据了无可争议的主流地位 面向对象分析设计领域有一些比较著名的学派 如 lCoad和Yourdon学派 lBooch学派 lJocobson学派 lRumbaugh学派 UML RationalRose 二 需求开发 4 需求分析与定义3 需求分析方法模型描述 4 建模原则 恰当地使用图形符号现代建模工具如Rose有非常丰富的图形符号和文字标注 能很好地表达模型的细节 要注意的是 在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化 将使开发人员更难掌握 而且使图形文档更加杂乱 世上不存在一个包罗万象的图 它能完整地描述需求 需求建模不可能取代文字描述 在需求文档中 文字描述是第一重要的 建模主要是起分析 解释作用 建议将模型存放在需求文档的附录中 便于正文引用 二 需求开发 5 产品需求规格说明书1 用户需求说明书 与 产品需求规格说明书 的主要区别与联系前者主要采用自然语言 和应用域术语 来表达用户需求 其内容相对于后者而言比较粗略 不够详细 后者是前者的细化 更多地采用计算机语言和图形符号来刻画需求 产品需求是软件系统设计的直接依据 两者之间可能并不存在一一影射关系 因为软件开发商会根据产品发展战略 企业当前状况适当地调整产品需求 例如用户需求可能被分配到软件的数个版本中 软件开发人员应当依据 产品需求规格说明书 来开发当前产品 二 需求开发 5 产品需求规格说明书2 应按一定规范书写 模板 二 需求开发 5 产品需求规格说明书3 书写原则 1 正确 2 清楚 3 无二义性 4 一致 5 必要 6 完备 7 可实现 8 可验证 9 确定优先级 10 阐述 做什么 而不是 怎么做 三 需求管理 1 需求验证系统分析员往往认为他们了解与掌握了用户的需求 然而却没有真正把握商业过程的最精妙之处 在项目早期发现和解决这方面的问题 比到了开发与实现阶段解决的代价要小百倍 发现和解决需求分析问题的手段是需求验证 类似于房屋建造 需求分析相当于设计蓝图 在进行设计时可能会存在问题 如果在正式建造前不加以解决可能导致完全的失败 在建造之前首先要验证图纸的正确性 三 需求管理 1 需求验证1 需求验证过程需求确认是指开发方和客户方共同对 产品需求规格说明书 进行评审 双方对需求达成共识后作出承诺 需求确认包含两个重要工作 需求评审 和 需求承诺 三 需求管理 1 需求验证2 需求评审要注意的问题 l需求评审的一个通病是 虎头蛇尾 需求评审的确乏味 也比较费脑子 刚开始评审时 大家都比较认真 越到后头越马虎 主持人应当控制节奏 将重要内容放在前面 l需求评审涉及的人员可能比较多 有些时候让这么多人聚在一起花费比较长的时间开会并不容易 例如有些人可能出差在外 有些人可能事务缠身 没有必要把所有事情挤在一块做 需求开发是循序渐进的过程 需求评审也可以分段进行 这样每次评审的时间比较短 参加评审的人员也少一些 组织会议就比较容易 l开评审会议时经常会 跑题 导致评审效率很低 有时话匣子一打开后关不上 大家越扯越远 结果评审会议变成了聊天会议 主持人应当控制话题 避免大家讨论与主题无关的东西 l开评审会议时经常会发生争议 适当的争议有利于澄清问题 比什么东西都一致赞成要好 控制争议不变为争吵 争吵不仅对评审工作没有好处 而且会无意中伤害同事间及与客户的关系 影响项目组下一步的工作 人们在很多时候分不清楚自己究竟是 坚持真理 还是 固执己见 毫不妥协或者轻易妥协都不是好办法 我们应当养成良好的习惯 不要一棍子打死异己的观点 尝试着让自己站在他人的立场思考问题 这样你会找到比较满意的答案 三 需求管理 1 需求验证3 需求承诺需求承诺是指开发方和客户方的责任人对通过了正式技术评审的 产品需求规格说明书 作出承诺 该承诺具有商业合同的效果 本 产品需求规格说明