会员注册 | 登录|微信快捷登录 QQ登录 微博登录 |帮助中心 精品学习网 专业在线学习考试资料文档分享平台

需求开发与需求管理

收 藏 此文档一共:34页 本文档一共被下载: 本文档被收藏:

显示该文档阅读器需要flash player的版本为10.0.124或更高!

关 键 词:
软件需求  
  文库屋所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
文档介绍
需求****与需求管理 —— 消除软件****百病之源 目录 1. 什么是需求 2. 了解客户、最终用户、间接用户 3. 需求工程基本概念 4. 需求****的主要困难与对策 5. 如何开展需求调查 6. 如何进行需求**** 7. 什么是好的需求规格说明书 8. 如何定义产品需求 9. 需求管理:确认、跟踪、变更控制 Page 2 1. 什么是需求 1.1 需求的基本概念 宽泛地讲,需求来源于用户的一些“需要”,这些“需要”被****、确认后形成完整的文档 ,该文档详细地说明了产品“必须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮件,你就以为自己已经掌握了需求,那是自 欺欺人。 1.2 需求的重要性 Frederick Brooks 在他 1987 年经典文章“ No Silver Bullet” 中阐述了需求的重要性: – ****软件系统最困难的部分就是准确说明****什么。最困难的概念性工作是编 写出详细的需求,包括所有面向用户、面向机器和其它软件系统的接口。此工 作一旦做错,将会给系统带来极大的损害,并且以后对它修改也极为困难。 需求是产品的根源,需求工作的优劣对产品影响最大。就像一条河流,如果源头被污 染了,那么整条河流也就被污染了。 国内软件业的痼疾:人们并不清楚究竟该做什么,但却一直忙碌不停地****。 Page 3 1. 什么是需求 1.3 需求****失败的案例 上海贝尔某事业部一群高智商的****人员集体犯需求观念错误的案例。 故事是这样的… 需求问题有时如同爱情问题,真是“当局者迷,旁观者清”啊。 Page 4 2. 了解客户、最终用户、间接用户 2.1 基本概念 “ 用户”( user )是一种泛称,它可细分为“客户”( customer )、“最终用户”( the end user )和 “间接用户”(或称为关系人)。 掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个 人也可能不是同一个人。 2.2 客户是掏钱买软件的人,所以他是“上帝” 某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时,精辟地阐述了客户的地位: – 如果顾客先点鸡,那么就先有鸡;如果顾客先点蛋,那么就先有蛋。 “ 现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的: – 客户永远是本公司的座上客。客户并不依赖我们,而我们却依赖客户。客户不 是我们工作的障碍,而是我们工作的目标。我们并不因为服务于他而对他有恩 ,他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩 和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们 的人,因此我们的工作就是满足这些欲望,从而使客户和我们共同获益。 与客户打交道的主要目的是:一是获取需求,二是签合同。不要把钱仍到水里。 Page 5 2. 了解客户、最终用户、间接用户 2.3 即使最终用户不是上帝,也算是“上帝”的“亲戚”,同样怠慢不得。 如果项目规模比较大,那么****方与最终用户的来往就比较多。如从最终用户那里获 取详细的需求,请最终用户试验软件,对最终用户进行培训等等。 公司新员工上产品培训课,有位小领导匆匆赶来作指示:“隔壁班正在给****局的员 工们进行培训,他们都是上帝派来的,大家要注意形象。由于休息室空间有限,请大 家自觉让位。午休时他们可以躺着睡,我们只能坐在位置上打个盹儿…… . 。” 2.4 重视“间接用户”,千万别“大意失荆州” 间接用户既不掏钱买该软件产品,也不使用该软件,但是它可能对软件产品有很大的 影响。 例如,财务软件****商在把“财务软件”卖给客户之前,这个“财务软件”必须得到国家 财政部的批准。否则即使该软件的功能是完美的,但却被****认为是非法的。所以国 家财政部就是所有财务软件的间接用户,它不仅不付钱给财务软件****商,反而要收 取鉴定费、手续费等。 同理,市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准,否则软 件****商被逮住后戴上“非法经营”的帽子就惨了。 Page 6 3. 需求工程基本概念 3.1 什么是需求工程 把所有与需求直接相关的活动通称为需求工程。 需求工程中的活动可分为两大类,一类属于需求****,另一类属于需求管理。 需求工程的结构图 Page 7 3. 需求工程基本概念 3.2 需求****过程域 需求****的目的是通过调查与****,获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生《用户需求 说明书》。 需求****的目的是对各种需求信息进行****,消除错误,刻画细节等。常见的需求分 析方法有“问答****法”和“建模****法”两类。 需求定义的目的是根据需求调查和需求****的结果,进一步定义准确无误的产品需求 ,产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展 系统设计工作。 3.3 需求管理过程域 需求管理的目的是在客户与****方之间建立对需求的共同理解,维护需求与其它工作 成果的一致性,并控制需求的变更。 需求确认是指****方和客户共同对需求文档进行评审,双方对需求达成共识后作出书 面承诺,使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,建立与维护“需求 跟踪矩阵”,确保产品依据需求文档进行****。 需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更, 防止需求变更失去控制而导致项目发生混乱。 Page 8 3. 需求工程基本概念 3.4 需求工程的一些感悟 不论是合同项目还是自主研发的产品,都必须开展需求****和需求管理活动 。 ****者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种,只有后 两种才有可能****出成功的产品。 – “ 被动型”是指****者被动地对待需求工程中的各项活动,能少干则少干,能偷 懒则偷懒。他们认为需求是用户的事情而不是自己的事情。****过程中经常发 生需求变更,导致产品迷失方向,不是半途而废就是陷入半死不活的状态。 – “ 主动型”是指****者积极地开展需求工程中的各项活动。他们把获取准确的需 求当作自己的职责,会想尽一切办法克服需求****和需求管理过程中的困难, 而不是找借口推卸责任。俗话说“良好的开端是成功的一半”,“主动型”需求工程 是****成功产品的必备条件。 – “ 领先型”是需求工程的最高境界。****者发掘了连用户自己都没有意识到的需 求,导致用户跟着新产品跑而不是新产品围着用户转,这叫引导消费。需求工 程做到这个份上,才能使产品立于不败之地,长盛不衰。 Page 9 4. 需求****的主要困难与对策 4.1 知识技能问题 应用域的知识是无边无际的,任何人都不可能是“万事通”。俗话说“隔行如隔山”,需 求****员可能是某一领域的专家,但当他接手陌生的业务时,他可能是个“无知”者。 一个企业要谋求发展,不能总在做老的业务。人一生中会有许多充满挫折的“第一次” ,不可以逃避。 当需求****员缺乏应用域知识时,他该怎么办? – 首先他要有勇气做事,否则连实践的机会都没有。 – 其次他应当赶紧补习应用域知识,不论是通过自学还是培训的方式,否则他很 难与用户交流。如果可能的话,****方最好请既懂软件又懂应用域知识的行家 来帮忙。 4.2 态度问题 相当多的****人员习惯于被动地对待需求****。每当遇到麻烦、挫折时,他们会发牢 骚,找出一堆用户的毛病。很多****人员错误地以为: – 需求是用户的事情,不是我们的事情。我们为用户****软件,难道用户不该告 诉我们应当****什么吗?如果用户说不清楚需求,或者经常变更需求,这类问 题是用户产生的,应当由他们自己负责。 用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可 以设法解决的。可悲的是****人员把这些问题当成了借口,不愿主动攻克问题,导致 需求问题扩散到整个软件****过程,产生太多的后患。 软件企业的领导应当给具有错误观念的****人员们****:需求****员的天职就是Pa在ge有10 限的时间内获取准确而细致的用户需求,如果做不到就是失职,不要找借口。 4. 需求****的主要困难与对策 4.3 合作关系 如果需求****员不能与用户建立良好的合作关系,那么他们在需求****过程中会很疲 惫。 倘若用户不能很好地配合需求****员,那并不表示他是个坏蛋。因为用户有他自己的 想法: – 我回答了你们的问题,讲了该讲的。我们付钱给你们,难道还要我伺候你们不 成?我还要干自己的事情,别打扰我了。你们自己想办法把活干好吧 ……。 对于一些竞标项目,在合同未签订之前的需求****工作尤为困难。用户未必会买你的 产品,他不会投入很多精力来协助你搞需求****。 需求****员不是销售人员,他们不可能象销售人员那样通过某些手段笼络住用户就能 成功。出色的需求****员不仅要有过硬的专业知识,还要具备较强的交流、沟通能力 。 ****方与用户的合作关系对需求****而言是至关重要的。对于重大的、复杂的项目, 我们不能完全期望双方能够自发地建立起良好地合作关系,这样风险太大。 ****方和用户方在开展需求****之前,双方协商并撰写“用户在需求工程中的权利与 义务”,即以协议的方式确定合作关系。“好话”和“丑话”都说在前头,这样能减少今后 的摩擦。如果条件允许的话,****方最好为用户举办关于需求工程的培训,这样的培 训将使用户明白需求的重要性以及忽视需求的危害性,从而促使他们积极友善地参加 需求工程中的各项活动。 Page 11 4. 需求****的主要困难与对策 用户在需求工程中的“权利” – 1. 有权要求****方派遣资质合格的需求****员和相关人员。 – 2. 有权要求****方采用用户熟悉的语言来描述需求,即****方必须提供用户看 得懂得需求文档。 – 3. 有权审查需求文档,并对有争议的需求作出决策。如果认为需求文档不能准 确地反映用户真实的意愿,可以拒绝在需求文档上签字。 – 4. 如果用户想要变更需求,有权要求****方对该变更将产生的影响作出真实可 信的评估,以便用户决定是否变更需求。 用户在需求工程中的“义务” – 1. 以积极友善的态度与****方人员交流、协作,尽可能地为****方人员提供工 作和生活上的便利。 – 2. 乐意接受需求****员的采访,在不泄漏机密的前提下尽可能地回答需求**** 员的问题。 – 3. 在不泄漏机密的前提下,尽可能地向需求****员提供与需求相关的材料。 – 4. 与需求****员共同评审需求文档,确保需求文档准确地反映用户真实的意愿 。 Page 12 4. 需求****的主要困难与对策 4.4 用户说不清楚需求 用户说不清楚需求是普遍现象,这是让****人员头痛的大问题。 有些用户真的不知道需求是什么,或者对需求只有朦胧的感觉,他当然说不清楚需求 。 – 例如****方的营销人员水平比较高,他能够在用户不清楚自己要什么的情况下 引导用户“消费”。 – 例如前些年全国各地的很多****机构大搞网络建设。这些机构的领导和办公人 员大多数不清楚网络干什么用,就让****人员替他们设想需求吧,反正是花公 家的钱。 有些用户虽然心里明白想要什么,但却说不清楚需求。 – 比如说买鞋子。我们非常了解自已的脚,但很难用语言说清楚脚的大小和形状 。通常拿鞋子去试,试穿时感觉到舒服才会买鞋。 需求****员绝不能以用户说不清楚需求为借口而草率地对待需求****工作,否则会连 累整个****团队的。 无论是什么原因导致用户说不清楚需求,需求****员必须设法搞清楚用户真正的需求 ,这是需求****员的职责,也是职业的挑战。 Page 13 4. 需求****的主要困难与对策 4.5 双方误解需求 人们在交流的时候,经常会发生“问非所求,答非所问”的事情。 有时用户会把****人员的建议或答复给想歪了: – 有一个软件****人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种 种好处,用户听得津津有味。最后,心动的用户对软件****人员说:“好得很 ,就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上, 我立即派人去做。” 而用户表达的需求,不同的****人员可能有不同的理解。如果需求****员误解了需求 ,那会导致后续的不少****人员将错就错、白干活。就像作文写跑题了,写得再好也 白搭。这类错误连高智商的外星人都不能避免: – 有个外星人间谍潜伏到地球刺探情报,它给上司写了一份报告:“主宰地球的 是车。它们喝汽油,靠四个轮子滚动前进。嗓门极大,在夜里双眼能射出强光 。……有趣的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全控制了 车。” 不论是复杂的项目还是简单的项目,需求****员和用户都有可能误解需求。所以需求 确认工作(属于需求管理)必不可少。 Page 14 4. 需求****的主要困难与对策 4.6 ****人员写不好需求文档 需求调查工作不充分,获取的需求信息太少或者太乱,以至于写不成需求文档。 – 古时候,一书生在考试前补习“写文章”,成天愁眉苦脸。其夫人甚为不解,问: “相公,你写文章比我生小孩还难吗?”书生长叹一声:“娘子你哪里知道我的难 处啊!你生小孩时肚子里有东西,可我写文章时肚子里没东西啊。” – 所以要想写出好的需求文档,前提条件是把需求调查工作做好。 ****人员写作能力比较差,虽然在调查过程中已经获得了不少需求信息,却写不出好 的需求文档来。 – 可以毫不夸张地说,国内 90 %以上的软件****人员,他们的写作能力远不及开 发能力。 – 提高****人员写作能力的根本办法就是让他们多练习写文档,熟能生巧。 – 另外,企业应当提供合适的文档模板以及比较好的示例文档,尽可能地降低写 作难度。 Page 15 4. 需求****的主要困难与对策 4.7 用户经常变更需求 需求变更通常会对项目的进度、人力资源、经费产生很大的影响,这是****商非常畏 惧的问题。 如果在项目****的初始阶段,****人员和用户没有搞清楚需求或者搞错了需求,到了 项目****后期才将需求纠正过来,导致产品的部分内容需要重新****。毫无疑问,这 种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的,双方应 当好好反省,认真学习需求****和管理的方法,避免再犯相似的错误。 如果由于市场变化而导致产品需求发生变更,****商大可不必为此烦恼,应当高兴才 对。倘若市场静如死水,那么****商吃了“上一顿”就没有“下一顿”。正因为市场在变 化,才会产生更多商机,聪明的****商才会有活干,有钱赚。 其实需求变更并不可怕,可怕的是需求变更失去控制,导致项目混乱。所以需求变更 控制是需求工程的重要活动。 Page 16 5. 如何开展需求调查 5.1 准备调查 首先,需求****员应当起草需求调查问题表,将调查重点锁定在该问题表内,否则调 查工作将变得漫无边际。 – 问题表可以有多份,随着调查的深入,问题表将不断地被细化。 – 根据经验,用户通常没有耐心回答复杂的论述题,所以问题表应当以“选择题”和“是非题”为 主。 – 制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。 其次,需求****员应当确定需求调查的方式,例如: – 与用户交谈,向用户提问题。向用户群体发调查问卷。 – 参观用户的工作流程,观察用户的操作。 – 与同行、专家交谈,听取他们的意见。 – ****已经存在的同类软件产品,提取需求。 – 从行业标准、规则中提取需求。 – 从 Internet 上搜查相关资料。 最后,需求****员与被调查者建立联系,确定调查的时间、地点、人员等,撰写需求 调查计划。要特别留意的是不要漏掉典型的用户。 Page 17 5. 如何开展需求调查 5.2 执行调查 准备工作完毕后,需求****员按照计划执行调查。在调查过程中随时记录( 或存储)需求信息 。 需求****员与用户面谈时应当注意以下事项: – 如果与用户约好了时间,切勿迟到或早退。要注意礼节,尽可能获得用户的好 感,并为下次打扰他们埋下伏笔。 – 需求****员应事先了解用户的身份、背景,以便随机应变。 IT 人士不可貌相, 有些大企业的领导其外表很土气,象农民。如果你路上碰到他,以为是个勤杂 工,说:“喂,老****,来帮我拎东西。”也许这笔生意就泡汤了。 – 需求调查不象侦探推理那样从蛛丝马迹着手,应该先了解宏观问题,再了解细 节问题。 – 如果双方气氛融洽,可以采用灵活的访谈形式,轻易不要打断用户的谈话。当 双方对某些问题的交流合乎逻辑地结束后,即可继续讨论问题表中的其它问题 。 – 尽可能避免为用户添麻烦,但也不能怕给用户添麻烦而降低需求调查的力度。 – 避免片面地听取某些用户的需求而忽视其它用户的需求。 Page 18 5. 如何开展需求调查 5.3 《用户需求说明书》与《产品需求规格说明书》的主要区别与联系 前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比 较粗略,不够详细。 后者是前者的细化,更多地采用计算机语言和图形符****来刻画需求,产品需求是软件 系统设计的直接依据。 两者之间可能并不存在一一影射关系,因为软件****商会根据产品发展战略、企业当 前状况适当地调整产品需求,例如用户需求可能被分配到软件的数个版本中。软件开 发人员应当依据《产品需求规格说明书》来****当前产品。 5.4 撰写《用户需求说明书》 Page 19 用户需求说明书的参考模板 Page 20 6. 如何进行需求**** 6.1 基本概念 为了得到用户的金钱,企业不得不鼓吹:用户就是上帝,用户永远是正确的。 谁都知道这不是真的。事实上,很多时候用户说不清楚需求、会说错需求或者提出一 些无法实现的需求。 需求****是指在需求****过程中,对所获取的需求信息进行****,及时排除错误和弥 补不足,确保需求文档正确地反映用户的真实意图。 需求****是需求****过程中最费脑子的工作。****方法大体有两类:“问答****法”和“ 建模****法”。后者技术性比较强,写出来有学术味,故大多数软件工程书籍都有论 述。前者就是一些常识而已,虽然写不成文章,但是简单易用(保你一学就会),很 有实用价值。 “ 问答****法”比较适合于用户需求调查阶段 “ 建模****法”比较适合于产品需求定义阶段。 Page 21 6. 如何进行需求**** 6.2 问答****方法 问答****方法很简单:刨根究底地问,如果问题都被解答了,那么需求也就 ****清楚了。一个人可以“自问自答”地****需求,几个人****需求则称为“研 讨”。 问答****最重要的问题是:“是什么”和“为什么”。 – 每个需求都应当用陈述句说明“是什么”,如果“是什么”的内涵不够清晰,则应补 充说明“不是什么”。 – 如果“是什么”和“不是什么”并不是“理所当然”的,那么应当解释“为什么”,以便加 深读者的理解。 – 追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 其它常见的问题有: – 需求存在二义性吗? – 需求文档的上下文有矛盾吗? – 需求完备吗? – 需求是必要的吗? – 需求可实现吗? – 需求可验证吗? – 需求的优先级确定了吗? Page 22 6. 如何进行需求**** 6.3 建模****法 人们都有这样地感受:有些时候用语言描述某个问题特别费劲,而采用图形则使人一 目了然,所谓“一图低千言”就是这个道理。 在需求****过程中,对于某些类型的信息,用图形表示要比文本表示更加有效。所以 将图形与文本结合起来描述需求是很自然的方法。 需求建模就是指用图形符****来表示、刻画需求。 建模****方法主要有两大类:“结构化****法”和“面向对象****法”。 恰当地使用图形符****: – 现代建模工具如 Rose 有非常丰富的图形符****和文字标注,能很好地表达模型 的细节。要注意的是:在建模时使用花样过多的图形符****或文字意味着模型表 示的复杂化,将使****人员更难掌握,而且使图形文档更加杂乱。 – 世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代 文字描述。在需求文档中,文字描述是第一重要的,建模主要是起****、解 释作用。建议将模型存放在需求文档的附录中,便于正文引用。 Page 23 6. 如何进行需求**** 6.4 作出决策 当需求从四面八方收集来后,需求的冲突在所难免。对于那些难以达成共识的需求而 言,经常会发生“公说公有理,婆说婆有理”的现象。那么需求****员究竟应该听谁的 呢? – 如果一群人对需求有争议,并不是谁声音最响就听谁的。根据生活经验,最保 险的办法是:先听官儿大的或者威望高的,如果大家的职位和威望都差不多, 那么采用“少数服从大多数”的原则。 – 如果一个产品可以卖给几类客户,但是各类客户都要求产品按照他们的喜好来 ****。此时对需求的决策应当以商业利益为导向, 即哪一类客户出钱最多就先 满足他们的需求,以后再做那些获利相对较少的需求。 – 当****者想象中的产品与客户所提的需求有冲突时,一般应当尊重客户的观点 。但是不要陷入“客户总是对的”陷阱里,需求****员应当纠正明显不合理的客户 需求。如果产品很复杂,双方都不太明白需求,此时最好请****人员快速构造 软件的原型,双方看着软件原型再****需求。 Page 24 7. 什么是好的需求规格说明书 7.1 正确 需求规格说明书应当正确地反映用户的真实意图,“正确”是《产品需求规格说明书》 最重要的属性。如果“不正确”仅仅是由于错别字造成的,那么多检查几遍文档就能解 决问题。真正的困难是****者和用户自己都不明白用户究竟“想要什么”和“不要什么” 。为确保需求是正确的,****方和用户必须对《需求规格说明书》进行确认。 7.2 清楚 清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方 式来判断需求文档是否清楚: – 文档的结构、段落是否乱七八糟?上下文是否不连贯? – 文档的语句是否含糊其词、罗里罗嗦? – 看了半天是否还不明白需求究竟是什么? 7.3 无二义性 “ 无二义性” 是指每个需求只有唯一的含义。如果一个人说的话,不同的人可能有不同 的理解,那么这句话就有二义性。如果需求存在二义性,将会导致人们误解需求而开 发出偏离需求的产品。 为了使需求无二义性,人们在写《产品需求规格说明书》时措词应当准确,切勿模棱 两可。 Page 25 7. 什么是好的需求规格说明书 7.4 一致 “ 一致”( Consistent )是指《产品需求规格说明书》中各个需求之间不会发生矛盾。 矛盾常常潜伏在需求文档的上下文中。 7.5 必要 《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。 可以把“必要”比喻为“雪中送炭”。“必要”往前一步,要么是“画蛇添足”要么是“锦上添花 ”。 “ 画蛇添足”显然是坏事,会导致****人员多干一些吃力不讨好的工作。所以要尽量剔 除需求规格说明书中“画蛇添足”的那些需求。 “ 锦上添花”是好事,可能会让用户获得比期望更多的喜悦,但是眼前用户不会为此多 付钱。****者应当集中精力先完成必要的需求,如果条件允许则再做“锦上添花”的需 求。为了避免主次颠倒,应当在《产品需求规格说明书》中将那些“锦上添花”的需求 设置为较低的优先级。 7.6 完备 “ 完备”( Complete )是指《产品需求规格说明书》中没有遗漏一些必要的需求。 人们往往倾向于关注系统的特色功能,而忽视了其它一些不起眼的但却是必需的功能 。 不完备的《产品需求规格说明书》将导致产生功能不完整的软件,用户在使用该软件 时可能无法完成预期的任务。 Page 26 7. 什么是好的需求规格说明书 7.7 可实现 《产品需求规格说明书》中的各项需求对****方而言应当都是可实现的 ( Attainable )。 “ 可实现”意味着在技术上是可行的,并且满足时间、费用、质量等约束。 营销人员和用户谈生意时,为了能拿到“单子”,他们往往对用户提出的需求“来者不拒 ”。吹牛皮虽然不犯法,但是《产品需求规格说明书》可是白纸黑字啊。经过双方确 认的《产品需求规格说明书》相当于商业合同,如果****方不能够实现《产品需求规 格说明书》中的内容,那就是违约,可能会被罚款的。 对于合同项目,如果****方不能确信某些需求是否可实现,则应事先与用户协商,达 成一致的处理意见,避免将来发生商业纠纷。 7.8 可验证 《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的 ( Verifiable )。如果需求是不可验证的,那么用户就无法验收软件,可能会发生商 业纠纷。 例如,摩天大楼的一项需求是“抗十二级台风”,这个需求看起来堂而皇之,但是如何 验证呢?当摩天大楼完工后验收时,用户又不是巫师,他怎能造个十二级台风来试验 ?如果双方都认可“采用计算机模拟十二级台风”等效于实际测试,那么这项需求就是“ 可验证”的。 Page 27 7. 什么是好的需求规格说明书 7.9 确定优先级 为什么要确定需求的“优先级”? – 理论上讲,软件的所有需求都应当被实现。但是在现实之中,项目存在“进度、 费用、人力资源”等限制。在项目刚开始的时候,****方和客户比较乐观,什么 都要做,可是做着做着,人们常常会面临“进度延误、费用超支、人员不足”等问 题,这时就乱套了。 – 人们想出了“取舍”办法:先做优先级高的需求,后做(甚至放弃)优先级低的需 求,这样可以将风险降到最低。 需求的优先级其实就是需求“轻重缓急”的分级表述,例如划分为“高、中、低”三级。 一般地,由用户和****方共同确定需求的优先级。 7.10 阐述“做什么”而不是“怎么做” 《产品需求规格说明书》的重点是阐述“做什么”,而不是阐述“怎么做”。“怎么做”是系 统设计和实现阶段的事情。 国内的很多软件公司里,****人员常常身兼数职,可能把需求****、系统设计、编程 等工作从头做到尾。所以他们在调查、****、定义需求时,自然会想到“怎么做”,这 并没有什么过错。如果在调查、定义需求时想好了“怎么做”,当然应该写下来,否则 岂不浪费!关键是不要将“怎么做”写到需求规格说明书里面,记录在其它文档里就行 了。 Page 28 8. 如何定义产品需求 8.1 规程 第一步:细化并****用户需求 – 需求****员首先对《用户需求说明书》进行细化,对比较复杂的用户需求进行 建模****,以帮助软件****人员更好地理解需求。例如采用 Rational 的 Rose 工具进行需求的建模****,建模****产生的文档可以作为《产品需求规格说明 书》的附件。补充说明:建模****的技术难度比较高,需求****员应当根据自 身水平进行取舍。 第二步:撰写产品需求规格说明书 – 需求****员按照指定的文档模板撰写《产品需求规格说明书》。如果待****的 产品分为软件和硬件两部分的话,则应当撰写《软件需求规格说明书》和《硬 件需求规格说明书》。 第三步:进行需求确认 – 项目经理邀请同行专家和用户(包括客户和最终用户)一起评审《产品需求规 格说明书》,尽最大努力使《产品需求规格说明书》能够正确无误地反映用户 的真实意愿。 – 需求评审之后,****方和客户方的责任人对《产品需求规格说明书》作书面承 诺。 8.2 软件需求规格说明书的参考模板 Page 29 软件需求说明书的参考模板 Page 30 9. 需求管理:确认、跟踪、变更控制 9.1 需求确认(评审和承诺) 需求确认是指****方和客户方共同对《产品需求规格说明书》进行评审,双方对需求 达成共识后作出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。 9.2 需求评审面临的困难 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味,也比较费脑子。刚开始评审 时,大家都比较认真,越到后头越马虎。 需求评审涉及的人员可能比较多,有些时候让这么多人聚在一起花费比较长的时间开 会并不容易(例如有些人可能出差在外,有些人可能事务缠身)。没有必要把所有事 情挤在一块做,需求****是循序渐进的过程,需求评审也可以分段进行。这样每次评 审的时间比较短,参加评审的人员也少一些,组织会议就比较容易。 开评审会议时经常会“跑题”,导致评审效率很低。有时话匣子一打开后关不上,大家 越扯越远,结果评审会议变成了聊天会议。主持人应当控制话题,避免大家讨论与主 题无关的东西。 开评审会议时经常会发生争议。适当的争议有利于澄清问题,比什么东西都一致赞成 要好。然而当争议变为争吵时就坏事了,争吵不仅对评审工作没有好处,而且会无 意中伤害同事们的感情。 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥 协都不是好办法。我们应当养成良好的习惯:不要一棍子打死异己的观点,尝试着让 自己站在他人的立场思考问题,这样你会找到比较满意的答案。 Page 31 9. 需求管理:确认、跟踪、变更控制 9.3 需求承诺 需求承诺是指****方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承 诺,该承诺具有商业合同的效果。 需求承诺的“八股文”如下: – 本《产品需求规格说明书》建立在双方对需求的共同理解基础之上,我同意后续的****工 作根据该《产品需求规格说明书》开展。如果需求发生变化,我们将按照“变更控制规程 ”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。 – 甲方签字 乙方签字 人们在作出承诺之前务必要认真阅读文档,一定要明白签字意味着什么。 Page 32 9. 需求管理:确认、跟踪、变更控制 9.4 需求跟踪 需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符 合用户需求。 需求跟踪有两种方式: – 正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对 应点。 – 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书 》中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵 (即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。 Page 33 9. 需求管理:确认、跟踪、变更控制 9.5 需求变更控制 需求发生变更的起因主要有: – 随着项目的进展,人们(包括****方和客户方)对需求的了解越来越深入。原 先的需求文档可能存在这样那样的错误或不足,因此要变更需求。 – 市场发生了变化,原先的需求文档可能跟不上当前的市场需求,因此要变更需 求。 提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。对项目****小组 而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,****小组 要为此付出较重的代价。如果每次需求变更请求都被采纳的话,这个项目也许永远不 能按时完成。 需求变更控制的目的: 如果需求变更带来的好处大于坏处,那么允许变更,但必须按 照已定义的变更规程执行,以免变更失去控制。 如果需求变更带来的坏处大于好处, 那么拒绝变更。 需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情 况下****方是不敢得罪客户的,但是无原则地退让将使****小组陷入困境。解决这个 问题最好的办法是事先建立“游戏规则”: – ****方与客户方达成“事不过三”的约定(符合中国人的习惯),即允许客户 变更三次需求;如果客户第四此变更需求,****方有权拒绝,除非客户愿意补 偿****方的损失。 如果事先没有“游戏规则”的话,****方需要一些社交技巧来减缓矛盾。例如建议在开 发该产品新版本时修改需求。 Page 34
关于本文

当前资源信息

高级会员

爱学习共有文档571 篇

编号:WENKUWU310

类型: IT/计算机

格式: ppt

大小: 0.53 MB

上传时间:2018-02-07

相关搜索

关于我们-联系我们-网站声明-文档下载-网站公告-版权申诉-网站客服

文库屋  www.wenkuwu.com (精品学习网 专业在线学习考试资料文档分享平台)

本站部分文档来自互联网收集和整理和网友分享,如果有侵犯了您的版权,请及时联系我们.
© www.topstudy.com.cn 2016-2012 精品学习网 版权所有 并保留所有权  ICP备案号:  粤ICP备14083021号-8              

收起
展开