需求管理和需求分析专题培训课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
需求开发的目的是通过调查与分析,获取用户需求并定义 产品需求。 需求调查的目的是通过各种途径获取用户的需求信息(原 始材料),产生《用户需求说明书》。 需求分析的目的是对各种需求信息进行分析,消除错误, 刻画细节等。常见的需求分析方法有“问答分析法”和“建 模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果,进一 步定义准确无误的产品需求,产生《产品需求规格说明书》。 系统设计人员将依据《产品需求规格说明书》开展系统设计 工作。
我们缺乏应用域知识,该怎么办? 首先要有勇气做事,否则连实践的机会都没有。 其次他应当赶紧补习应用域知识,不论是通过自学还是培训的方式,否则他很难与 用户交流。如果可能的话,最好请既懂软件又懂应用域知识的行家来帮忙。
2 态度问题
我们习惯于被动地对待需求开发。每当遇到麻烦、挫折时,我们会发牢骚并错误地以为: 需求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我 们应当开发什么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户 产生的,应当由他们自己负责。
用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可以设 法解决的。我们要主动攻克问题,导致需求问题扩散到整个软件开发过程,产生太多的后 患。
需求工程简介
需求开发的主要困难与对策
1 知识技能问题
应用域的知识是无边无际的,任何人都不可能是“万事通”。俗话说“隔行如隔山”,需 求分析员可能是某一领域的专家,但当他接手陌生的业务时,他可能是个“无知”者。一 个企业要谋求发展,不能总在做老的业务。人一生中会有许多充满挫折的“第一次”,不 可以逃避。
约束条件
业务需求
前言
业务说明 常规需求:客户明确提出
期望需求:并未明确提出的潜在需求,
用户需求
不 言而喻的需求
使用实例 兴奋需求:客户未想到,若实现客户
感到意外
功能需求
非功能需求
软件需求规格说明
软件需求的层次
前言
软件需求与系统需求分析
系统工程组
客户
系统需求
分配
最终用户
软件工程组
软件
硬件
其它成分
前言
⑴ 定义(IEEE-STD-610) 用户为解决某个问题、或为实现某一目标, 要求软件必须满足的条件或能力。
⑵ 软件需求的三个层次 • 业务需求 • 用户需求 • 功能需求和非功能需求
前言
非功能需求
过程需求:交付需求,实现需求, 遵循的标准
性能需求:速度,容量,可靠性
外部需求:互操作性,伦理性, 机密性,安全性, 使用要求
需求工程简介
把所有与需求直接相关的活动通称为需求工程。需求工程中的活 动可分为两大类,一类属于需求开发,另一类属于需求管理。 需求工程的结构图
需求工程简介
市场
用户/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格说明
需求开发
变更的需求
控制需求 变更
项目 环境
需求管理
需求工程简介
需求开发过程
需求工程简介
需求管理过程
需求管理的目的是在客户与开发方之间建立对需求的共同理解, 维护需求与其它工作成果的一致性,并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审,双方对 需求达成共识后作出书面承诺,使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关 系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进 行开发。 需求变更控制是指依据“变更申请-审批-更改-重新确认” 的流程处理需求的变更,防止需求变更失去控制而导致项目发 生混乱。
需求管理和需求分 析
需求管理和需求分析
内容
前言 需求工程简介 需求开发的主要困难与对策 如何开展需求调查 如何进行需求分析 什么是好的需求规格说明书 形成需求规格说明书 需求管理:确认、跟踪、变更控制 CMM2级KPA需求管理(RM)介绍
前言
泛泛地讲,需求来源于客户的一些“需要”,这些“需要”被 分析、确认后形成完整的文档,该文档详细地说明了产品“必 须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮 件,并没有真正掌握需求 Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述 了需求的重要性:开发软件系统最困难的部分就是准确说明开 发什么。最困难的概念性工作是编写出详细的需求,包括所有 面向用户、面向机器和其它软件系统的接口。此工作一旦做错, 将会给系统带来极大的损害,并且以后对它修改也极为困难。 需求是产品的根源,需求工作的优劣对产品影响最大。就像一 条河流,如果源头被污染了,那么整条河流也就被污染了。
需wk.baidu.com工程简介
不论是合同项目还是自主研发的产品,都必须开展需求开发和需 求管理活动。开发者对待需求工程的态度可分“被动型”、“主动 型”和“领先型”三种。 “被动型”是指开发者被动地对待需求工程中的各项活动。他们 认为需求是用户的事情。开发过程中经常发生需求变更,导致产品 迷失方向,不是半途而废就是陷入半死不活的状态。 “主动型”是指开发者积极地开展需求工程中的各项活动。他们 把获取准确的需求当作自己的职责,会想尽一切办法克服需求开发 和需求管理过程中的困难,而不是找借口推卸责任。俗话说“良好 的开端是成功的一半”。 “领先型”是需求工程的最高境界。开发者发掘了连用户自己都 没有意识到的需求,导致用户跟着新产品跑而不是新产品围着用户 转,这叫引导消费。需求工程做到这个份上,才能使产品立于不败 之地,长盛不衰。
系统需求(1) 系统需求(2) 系统需求(n)
软件需求
前言
“用户”(user)是一种泛称,它可细分为“客户” (customer)、“最终用户”(the end user)和“间接用户” (或称为关系人)。掏钱买软件的用户称为客户,而真正操作软 件的用户叫最终用户。客户与最终用户可能是同一个人也可能不 是同一个人。 客户是掏钱买软件的人,所以他是“上帝” 。某饭店经理在解 释“先有鸡还是先有蛋”这个哲学问题时,精辟地阐述了客户的 地位:如果顾客先点鸡,那么就先有鸡;如果顾客先点蛋,那么 就先有蛋。 客户的需要才是最准确需求之源
我们缺乏应用域知识,该怎么办? 首先要有勇气做事,否则连实践的机会都没有。 其次他应当赶紧补习应用域知识,不论是通过自学还是培训的方式,否则他很难与 用户交流。如果可能的话,最好请既懂软件又懂应用域知识的行家来帮忙。
2 态度问题
我们习惯于被动地对待需求开发。每当遇到麻烦、挫折时,我们会发牢骚并错误地以为: 需求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我 们应当开发什么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户 产生的,应当由他们自己负责。
用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可以设 法解决的。我们要主动攻克问题,导致需求问题扩散到整个软件开发过程,产生太多的后 患。
需求工程简介
需求开发的主要困难与对策
1 知识技能问题
应用域的知识是无边无际的,任何人都不可能是“万事通”。俗话说“隔行如隔山”,需 求分析员可能是某一领域的专家,但当他接手陌生的业务时,他可能是个“无知”者。一 个企业要谋求发展,不能总在做老的业务。人一生中会有许多充满挫折的“第一次”,不 可以逃避。
约束条件
业务需求
前言
业务说明 常规需求:客户明确提出
期望需求:并未明确提出的潜在需求,
用户需求
不 言而喻的需求
使用实例 兴奋需求:客户未想到,若实现客户
感到意外
功能需求
非功能需求
软件需求规格说明
软件需求的层次
前言
软件需求与系统需求分析
系统工程组
客户
系统需求
分配
最终用户
软件工程组
软件
硬件
其它成分
前言
⑴ 定义(IEEE-STD-610) 用户为解决某个问题、或为实现某一目标, 要求软件必须满足的条件或能力。
⑵ 软件需求的三个层次 • 业务需求 • 用户需求 • 功能需求和非功能需求
前言
非功能需求
过程需求:交付需求,实现需求, 遵循的标准
性能需求:速度,容量,可靠性
外部需求:互操作性,伦理性, 机密性,安全性, 使用要求
需求工程简介
把所有与需求直接相关的活动通称为需求工程。需求工程中的活 动可分为两大类,一类属于需求开发,另一类属于需求管理。 需求工程的结构图
需求工程简介
市场
用户/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格说明
需求开发
变更的需求
控制需求 变更
项目 环境
需求管理
需求工程简介
需求开发过程
需求工程简介
需求管理过程
需求管理的目的是在客户与开发方之间建立对需求的共同理解, 维护需求与其它工作成果的一致性,并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审,双方对 需求达成共识后作出书面承诺,使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关 系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进 行开发。 需求变更控制是指依据“变更申请-审批-更改-重新确认” 的流程处理需求的变更,防止需求变更失去控制而导致项目发 生混乱。
需求管理和需求分 析
需求管理和需求分析
内容
前言 需求工程简介 需求开发的主要困难与对策 如何开展需求调查 如何进行需求分析 什么是好的需求规格说明书 形成需求规格说明书 需求管理:确认、跟踪、变更控制 CMM2级KPA需求管理(RM)介绍
前言
泛泛地讲,需求来源于客户的一些“需要”,这些“需要”被 分析、确认后形成完整的文档,该文档详细地说明了产品“必 须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮 件,并没有真正掌握需求 Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述 了需求的重要性:开发软件系统最困难的部分就是准确说明开 发什么。最困难的概念性工作是编写出详细的需求,包括所有 面向用户、面向机器和其它软件系统的接口。此工作一旦做错, 将会给系统带来极大的损害,并且以后对它修改也极为困难。 需求是产品的根源,需求工作的优劣对产品影响最大。就像一 条河流,如果源头被污染了,那么整条河流也就被污染了。
需wk.baidu.com工程简介
不论是合同项目还是自主研发的产品,都必须开展需求开发和需 求管理活动。开发者对待需求工程的态度可分“被动型”、“主动 型”和“领先型”三种。 “被动型”是指开发者被动地对待需求工程中的各项活动。他们 认为需求是用户的事情。开发过程中经常发生需求变更,导致产品 迷失方向,不是半途而废就是陷入半死不活的状态。 “主动型”是指开发者积极地开展需求工程中的各项活动。他们 把获取准确的需求当作自己的职责,会想尽一切办法克服需求开发 和需求管理过程中的困难,而不是找借口推卸责任。俗话说“良好 的开端是成功的一半”。 “领先型”是需求工程的最高境界。开发者发掘了连用户自己都 没有意识到的需求,导致用户跟着新产品跑而不是新产品围着用户 转,这叫引导消费。需求工程做到这个份上,才能使产品立于不败 之地,长盛不衰。
系统需求(1) 系统需求(2) 系统需求(n)
软件需求
前言
“用户”(user)是一种泛称,它可细分为“客户” (customer)、“最终用户”(the end user)和“间接用户” (或称为关系人)。掏钱买软件的用户称为客户,而真正操作软 件的用户叫最终用户。客户与最终用户可能是同一个人也可能不 是同一个人。 客户是掏钱买软件的人,所以他是“上帝” 。某饭店经理在解 释“先有鸡还是先有蛋”这个哲学问题时,精辟地阐述了客户的 地位:如果顾客先点鸡,那么就先有鸡;如果顾客先点蛋,那么 就先有蛋。 客户的需要才是最准确需求之源