需求开发和管理

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

需求的困难
软件需求是整个软件开发项目的最关键的一 个输入,和传统的生产企业相比较,软件的 需求具有模糊性、不确定性、变化性和主观 性的特点,他不像生产汽车、电脑等硬件的 需求,是有形的、客观的、可描述的、可检 测的,软件需求是软件项目中最难把握的问 题。
需求的困难
需求的困难
知识技能问题 态度问题 合作关系 用户说不清需求 双方误解需求 写不好需求文档 用户经常变更需求
验收过程
验收测试 试运行 安装部署 项目验收
结项过程
项目总结 用户调查
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
什么叫需求
IEEE中需求的定义
1. 用户解决问题或达到目标所需的条件或权能 (Capability)。 2. 系统或系统部件要满足合同、标准、规范或其 它正式规定文档所需具有的条件或权能。 3. 一种反映上面1或2所描述的条件或权能的文档 说明。
什么叫需求
IEEE公布的需求定义包括从用户角度以及 开发者角度来阐述需求。 需求的一个关键问题是:一定要编写文档。 如果只有一些零碎的对话、资料或邮件,就 认为自己已经掌握了需求,那是自欺欺人。
需求的重要性
需求是产品的根源,需求工作的优劣对产品 影响最大。就像一条河流,如果源头被污染 了,那么整条河流也就被污染了。 国内软件业的痼疾: 人们并不清楚究竟
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求分析
怎么做?
(项目名称) 系统需求规格说明书
需求分析人员
文件版本 编写人 编写时间 V0.00 XXX XXXX 年 XX 月 XX 日
XXXX 公司
需求文档
需求文档应避免事项
凌乱(应保持语句和段落的简短) 使用的术语与词汇表中所定义的不一致 含糊、主观的术语,如:用户友好、容易、简 单、迅速、有效、许多、健壮的… 多项需求,如:和、或、但是、然而… 使用比较性的词汇,如:提高、最大化… 理想化的想法,如:100%可靠,在所有平台 运行…
XXXX 公司
需求获取
需求调研指导原则
建立顾客的主动参与意识。 在进行任何调研之前,必须对顾客方做相应的 培训。主要是培训需求调研方法、需求调研过 程等内容。 在进行需求调研之前,一定要明确顾客方人员 对于需求的决定权,即哪些人能够决定那些需 求。 在每个阶段开始之前,首先评估此阶段的风险, 根据风险来做相应的调整
需求获取
需求调研
获取顾客组织结构图和人员结构图。 根据需求调研计划进行调研工作。
编写《用户需求规格说明书》
需求获取
《用户需求规格说明书》与《系统需求规格 说明书》的区别
前者主要采用自然语言来表达用户需求,主要 用于与用户沟通,使用户可以更清楚的看到需 求是否正确、完整。 后者是前者的细化,更多地采用计算机语言和 图形符号来刻画需求,产品需求是软件系统设 计的直接依据。 前者主要描述业务、后者主要描述系统功能。
该做什么, 该做什么, 但却一直忙碌不停地 开发。 开发。
需求的重要性
一个需求错误所引致的后期成本倍增 (摘自Boehm研究结果) 发现错误的阶段 需求阶段 设计阶段 实现阶段 开发测试阶段 应用测试阶段 实际运行阶段 改进错误的成本倍数 1 3-6 10 15 - 40 30 - 70 40 - 1000
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求工程
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求获取
做什么
(XX 项目) 用户需求规格说明书
需求调研人员
用户
文件版本 编写人 编写时间 V0.00 xxxx xxxx 年 xx 月 xx 日
需求开发和管理
KittyZhang jlzhang.chn@gmail.com Kittyzhang.chn@hotmail.com 2006.3
需求在生命周期中地位
需求过程
需 求 管 理 提出需求
供方选择与评定过程
选择供方 签定合同 监督控制
需求分析
项目策划
采购
开发过程
配 置 管 理 质 量 保 证 概要设计 详细设计 编码 单元测试 集成测试 系统测试 评 审 过 程
需求跟踪
项目经理负责组织在项目的整个工程过程中 对需求状态进行跟踪,以便及时了解各需求 的进展情况。 建立与维护“需求-设计-编程-测试”之 间的关系,保证系统的完整性。
需求跟踪
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求变更
推荐资料
《Software Requirements》 ----Karl E.Wiegers 《掌握需求过程》 ----Suzanne Robertson James Roberston
Thanks
Kitty Zhang 2006.3
《系统需求规格说明书》评审人员要求
用户、项目经理、需求调研人员、需求分析人 员、设计人员、系统测试负责人、质量保证人 员。
需求评审
《用户需求规格说明书》评审内容
需求评审
需求评审
《系统需求规格说明书》评审内容
需求评审
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求获取
首次会议
到达现场后与用户、高层领导一起召开首次会 议。 确定项目的存在。 顾客的高层领导说明业务现状、建立该系统的 动机以及大致的业务介绍。 项目组介绍需求调研计划、需求调研使用的过 程、技术等与当前需求调研相关的内容。
需求获取
首次会议
到达现场后与用户、高层领导一起召开首次会 议。 确定项目的存在。 顾客的高层领导说明业务现状、建立该系统的 动机以及大致的业务介绍。 项目组介绍需求调研计划、需求调研使用的过 程、技术等与当前需求调研相关的内容。
需求获取
准备调研
首先,需求分析员制定需求调研问题表,将调查重点锁定 在该问题表内,否则调查工作将变得漫无边际。 其次,需求分析员应当确定需求调研的方式,例如: 与用户交谈,向用户提问题。向用户群体发调研问卷。 参观用户的工作流程,观察用户的操作。 分析已经存在的同类软件产品,提取需求。 从行业标准、规则中提取需求。 从Internet上搜查相关资料。 最后,需求分析员与被调研者建立联系,确定调研的时间、 地点、人员等,撰写需求调研计划。要特别留意的是不要 漏掉典型的用户。
需求获取
需求调研指导原则
如果需要顾客提供文档,必须要给顾客方讲解 清楚,特别是涉及到技术细节的时候。这样可 以避免因为双方理解不一致而导致的差错。 要严格按照计划实施调研过程。计划一般提前3 天到7天制订,并提前分发给所有的相关人员以 作好准备。 对调研过程使用的文档需标识其版本,版本号 要保证简单明了。
需求获取
需求调研指导原则
对于项目组和顾客方来说,双方需要建立接口, 定义清楚接口关系。所有双方的交流都通过接 口进行。 每次和顾客开会前,最好提前制订出提问表或 者用活动图表示出大致的业务流程。如果是业 务用例的调研,最好使用图表、原型演示等直 观形象的方式。
需求获取
需求调研指导原则
每次和顾客开会前,需提前和顾客沟通,明确 会议目的、时间安排、参加人、会议内容。并 提前将会议内容进行分发。会议结束后,整理 会议记录,分发给会议参加人员,对于未参加 的高层负责人,项目组必须抄送。 所有需要提供给顾客的文档,一定要使用符合 顾客语言习惯的表达方式,尽量不要使用软件 中的术语。
需求文档
优秀需求文档的特征
完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性
Leabharlann Baidu
提纲
需求重要性及困难 需求工程 需求开发
需求获取 需求分析
需求管理
需求确认 需求跟踪 需求变更
需求评审
《用户需求规格说明书》评审人员要求
用户、项目经理、需求调研人员、需求分析人 员、确认测试人员、质量保证人员。
需求获取
需求调研指导原则
项目组内部规定各个流程的活动、各个流程的 参与人员。比如,对于更改的流程的活动及人 员等都应提前做出规定。 顾客方也要规定各个流程的活动、各个流程的 参与人员。 项目组内部需要作好分工。一种是按业务划分, 即哪些人负责哪些模块;一种是按职能划分, 即哪些人负责那些工件。 顾客方也要作好分工,要明确顾客方哪些人负 责哪些业务。
相关文档
最新文档