《软件项目需求调研方法及需求规格说明书的编写ppt课件.ppt》由会员分享，可在线阅读，更多相关《软件项目需求调研方法及需求规格说明书的编写ppt课件.ppt（48页珍藏版）》请在三一办公上搜索。
1、湖南科创信息技术股份有限公司,北京科创鑫源信息技术有限公司,2014-11-6,唐玉林,1,需求开发与需求管理,消除软件开发百病之源,1,需求概述,1,需求分析,3,需求定义,4,2,需求管理,5,需求获取,2,汇报内容,_,需求概述,2,了解客户、最终用户、间接用户,客户,掏钱买软件的用户称为客户。,客户永远是本公司的座上客，是上帝。客户并不依赖我们，而,我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标,。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他,的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。,从未,有人曾在与客户的争辩中获胜。,客户是把他的欲望带给我们的人
2、，,因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。,最终用户,真正操作软件的用户。即使最终用户不是上帝，也算,是“上帝”的“亲戚”，同样怠慢不得。,间接用户,既不掏钱买该软件产品，也不使用该软件，但是它,可能对软件产品有很大的影响。,3,需求的层次,需求的层次,业务需求,反映了组织机构,或客户对系统、,产品高层次的目,标要求。,用户需求,功能需求,(,非功能需求,),描述用户使用产,品必须要完成的,任务。,定义开发人员必,须实现的,软件,功,能，使得用户能,完成他们的任务，,从而满足了业务,需求。,4,IEEE,对需求的定义为：,（,1,）用户解决问题或达到目标所需的条件或能力。,
3、-,针对用户,（,2,）系统或系统部件要满足合同、标准、规范或其他正式规定文,件文档所需具有的条件或能力。,-,针对开发者,需求的基本概念,?,需求是产品的,根源,，需求工作的优劣对产品影响最大。就像一条河,流，如果源头被污染了，那么整条河流也就被污染了。,?,国内软件业的,通病,：人们并不真正清楚究竟该做什么，但却一直忙,碌不停地开发。,需求的重要性,什么是需求,5,被动型,被动地对待需求工程中的各项活动，能少干则少干，,能偷懒则偷懒。他们认为需求是用户的事情而不是自,己的事情。开发过程中经常发生需求变更，导致产品,迷失方向，不是半途而废就是陷入半死不活的状态。,主动型,积极地开展需求工程中
4、的各项活动。他们把获取准确,的需求当作自己的职责，会想尽一切办法克服需求开,发和需求管理过程中的困难，而不是找借口推卸责任,。俗话说“良好的开端是成功的一半”，“主动型”,需求工程是开发成功产品的必备条件。,领先型,是需求工程的最高境界。开发者发掘了连用户自己都,没有意识到的需求，导致用户跟着新产品跑而不是新,产品围着用户转，这叫引导消费。需求工程做到这个,份上，才能使产品立于不败之地，长盛不衰。,对待需求工程的三种态度,6,花时间了解用户需求是确保项目成功的必要投入,1,5,20,50,100,需求,设计,编码,测试,维护,7,需求分析员需要的技能,1,、倾听的技巧,2,、交谈和提问的技巧,
5、3,、分析能力,4,、协调能力,5,、观察能力,6,、写作能力,7,、组织能力,8,、建模能力,9,、人际交往能力,10,、创造力,需求分析员必备的技能,1,、定义业务需求,2,、确定项目涉众,3,、获取需求,4,、分析需求,6,、编写需求规格说明书,7,、为需求建模,8,、需求验证,9,、优先级划分,10,、管理需求,需求分析员的工作,8,需求获取,2,需求分析,3,需求定义,4,9,需求管理,5,需求概述,1,汇报内容,_,需求获取,9,需求调研的内容,?,客户想要什么,?,?,要这干什么,?,?,为什么这么想,?,?,会不会有别的想法,?,ThemeGallery,is a,Design
6、 Digital Content&,Contents mall developed,by Guild Design Inc.,需求获取,需求调研的目的,?,搞清客户的要求,?,找出要求的逻辑,?,客户想要的结果,?,排除开发风险，挖,掘控制潜在的需求,需求调研的内容和目的,10,关于需求的漫画,客户的描述与实际,需求不一致,需求人员的理解与,客户描述的不一致,程序员实现的与需,求表达的不一致。,项目文档严重缺失,市场人员忽悠得天,花乱坠。,项目双方投入巨大,11,冰山理论,客户心里想的,100%,客户嘴里说的,80%,你听到的,60%,你听懂的,40%,开发实现的,20%,需要多次从多个角度与
7、客户、开发人员沟通、复述、确认,12,需求获取,聆听需求,13,1.,首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问,题表内，否则调查工作将变得漫无边际。,2.,其次，需求分析员应当确定需求调查的方式，例如：,?,与用户交谈，向用户提问题。向用户群体发调查问卷。,?,参观用户的工作流程，观察用户的操作。,?,与同行、专家交谈，听取他们的意见。,?,分析已经存在的同类软件产品，提取需求。,?,从行业标准、规则中提取需求。,?,从,Internet,上搜查相关资料。,3.,最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人,员等，撰写需求调查计划。要特别留意的是不要漏掉典型
8、的用户。,准备调查,建议：,养成收集日常问题的习惯，比如整理日常问题归集文档,14,执行调查,建议：,每次调研后编写会议纪要或用户需求调查单,1.,准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时,记录（或存储）需求信息,。,2.,需求分析员与用户面谈时应当注意以下事项：,?,如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，,并为下次打扰他们埋下伏笔。,?,需求分析员应事先了解用户的身份、背景，以便随机应变。,?,需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问,题。,?,如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈
9、话。当双方,对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。,?,尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。,?,避免片面地听取某些用户的需求而忽视其它用户的需求。,15,需求分析,3,需求获取,2,需求定义,4,16,需求管理,5,需求概述,1,汇报内容,_,需求分析,16,为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。,谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者,提出一些无法实现的需求。,需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分,析法”和“建模分析法”。后者技术性比较强，
10、写出来有学术味，故大多数软,件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易,用，很有实用价值。,需求分析的基本概念,需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及,时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。,17,问题分析方法,1.,问答分析方法：刨根究底地问，如果问题都被解答了，那么需求也就,分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求,则称为“研讨”。,2.,问答分析最重要的问题：,“是什么”、“为什么”、“不是什么”,。,3.,其它常见的问题有：,?,需求存在二义性吗？,?,需求文档的上下文有矛盾吗？,?,需求完备吗？
11、,?,需求是必要的吗？,?,需求可实现吗？,?,需求可验证吗？,?,需求的优先级确定了吗？,18,建模分析法,1.,大家都有这样地感受：有些时候用语言描述某个问题特别费劲，而采,用图形则使人一目了然，可谓“,一图顶千言,”。,2.,需求建模就是指用图形符号来表示、刻画需求。,3.,建模分析方法有两大类：“结构化分析法”和“面向对象分析法”。,4.,恰当地使用图形符号：,?,现代建模工具很多，都有非常丰富的图形符号和文字标注，能很好地表达,模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味,着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱,。,?,世上不存在一个包罗
12、万象的图它能完整地描述需求。需求建模不可能,取代文字描述。在需求文档中，,文字描述是第一重要的，建模主要是,起分析、解释作用。,建议将模型与文字有机结合，相辅相成。,19,需求分析常用元素,总体功能框图,流程图,用例图,状态转换图,原型界面图,需求分析常用工具,WORD,EXCEL,VISIO,Axure,RP Pro,Rationl,Rose,PowerDesigner,需求分析常用元素和工具,数据模型图,20,总统功能框图,21,总统功能框图,工程项目管理总体图,工程变更,其他,甲方验收,设计文件,会审,/,批复,设计文件出版,设计文件审核,工程立项,事先指导书管理,方案评审,设计分册,任
13、务管理,工程立项申请,工程立项管理,审批,事先指导书审,批申请,事先指导书管,理,审批,单个设计阶段,方案评审申请,方案评审管理,审批,单个设计阶段,设计分册,施设,设计阶段,设计文件审核,申请,单个设计阶段,一个或多个单项,单个,分册,设计文件审核,管理,审批,设计文件出版,申请,审核通过的,单个分册,设计文件出版,管理,审批,修改,设计文件,设计文件归档,委托受理,设计文件,会审,/,批复,甲方初验,甲方终验,单项负责人变更,负责人变,更,单项审核人变更,总负责人变更,项目负责人变更,处主管变更,院主管变更,工程要求变更,工程单项变更,参加人员变更,审核委托,工程中止,工程信息台账,设计分
14、册台账,分册审核台账,分册出版台账,项目安排,任务下达,设计阶段新增,设计阶段修改,主体处变更,参与处变更,综合管理,质量管理,查询监控,统计报表,22,功能框图,23,审批流程图,24,业务流程图,25,用例图,26,状态转换图,文件提交状态,0.,未提交,公文管理,从公文中归档,2,：已提交,1,：退回,3,、已接收,退回,从公文待归档模块提交,从公文待归档模块提交,接收,或,文件入卷,文件管理,新建文件,采购方式状态,27,原型界面（一）,28,工程项目,收入合同,N,：,N,子收入合同,1,：,N,收入确认,1,：,N,开票,分割,子开票,汇总,1,：,1,到款信息,子到款信息,1,：
15、,1,拆分,1,：,N,合同计划,收入计划,1,：,N,回款计划,1,：,N,1,：,1,1,：,1,1,：,1,1,：,1,年度合同计划,年度收入计划,1,：,N,（,0,）,年度回款计划,1,：,N,（,0,）,工程项目,立项记录,设计阶段,事先指导书,设计分册,单项,设计方案,设计文件审核,设计文件出版,设计会审,/,批复,1:N,N:N,1:N,1,：,N,1,：,N,1,：,N,1,：,1,1,：,1,N,：,1,N:N,29,需求定义,4,需求获取,2,需求分析,3,30,需求管理,5,需求概述,1,汇报内容,_,需求定义,30,内容不完,整,格式不统,一,书写不严,谨,照搬照抄,
16、需求太简,单,描述不清,晰,Title in,here,需求规格说明书常见问题,31,需求阶段的文档种类,真实的记录与用户的交流情况，包括交流的时间、地点、与会人,员、交流的主题等，以及每个人员的想法、建议、要求，逻辑上不,需要严谨，重点是真实。,采用自然语言（和应用域术语）来表达用户需求，其内容相对于,规格说明书而言比较粗略，不够详细。但具有较完整的逻辑。,是用户需求说明书的细化，更多地采用计算机语言和图形符号来,刻画需求，是软件系统设计的直接依据。,会议纪要或用户需求调查单,用户需求说明书,软件需求规格说明书,32,需求规格说明书的格式,1.,引言,1.1,目标,1.2,项目范围,1.3,
17、术语和缩略语,2.,系统概述,2.1,产品描述,2.2,产品功能,2.3,一般约束,3.,功能性需求分类,3.1,功能性需求分类方法,3.2,功能描述,1,3.3,功能描述,2,3.3.1,业务需求描述,3.3.2,用例图（角色描述）,3.3.3,功能需求,1,）流程图（,审批或业务）,2,）功能描述,3,）主要数据元素,4,）原型界面,4.,外部接口,1.1,用户接口,1.2,软件接口,5.,产品非功能性需求,33,对象,目的,客户、用户、市场人员,了解他们期望得到什么样的产品,项目经理,根据产品描述来估计项目的进度,工作量和所需资,源,开发团队,根据需求规格说明来了解需要开发什么样的产品,
18、测试人员,使用需求规格说明来开发测试计划,测试用例和测,试过程,文档编写人员,根据需求规格说明和用户界面设计来编写用户手册,和帮助屏幕,系统维护和支持人员,根据需求规格说明了解产品的每一部分的功能是什,么,培训人员,根据需求规格说明和用户文档来编写培训材料,软件需求要达到的目的,34,什么是好的需求规格说明书,1,正确,需求规格说明书应当正确地反映用户的真实意图，“正确”是产品需求规格说明书最重要的,属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困,难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，,开发方和用户必须对需求规
19、格说明书进行确认。,2,清楚,清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判,断需求文档是否清楚：,文档的结构、段落是否乱七八糟？上下文是否不连贯？,文档的语句是否含糊其词、罗里罗嗦？,看了半天是否还不明白需求究竟是什么？,3,无二义性,“无二义性”,是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解,，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产,品。,为了使需求无二义性，人们在写产品需求规格说明书时措词应当准确，切勿模棱两可。,35,4,一致,“一致”（,Consistent,）是指产品需求规格
20、说明书中各个需求之间不会发生矛盾。矛盾常常,潜伏在需求文档的上下文中。,5,必要,产品需求规格说明书中的各项需求对用户而言应当都是必要的。,可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添,花”。,“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规,格说明书中“画蛇添足”的那些需求。,“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开,发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次,颠倒，应当在产品需求规格说明书中将那些“锦上添花”的需求设置为较低的优先
21、级。,6,完备,“完备”（,Complete,）是指产品需求规格说明书中没有遗漏一些必要的需求。,人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。,不完备的产品需求规格说明书将导致产生功能不完整的软件，用户在使用该软件时可能无法,完成预期的任务。,什么是好的需求规格说明书,36,7,7,可实现,产品需求规格说明书中的各项需求对,开发方,而言应当都是可实现的（,Attainable,）。,“,可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。,营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹,牛皮虽然不犯法，但是产品需
22、求规格说明书可是白纸黑字啊。经过双方确认的产品需求规,格说明书相当于商业合同，如果开发方不能够实现产品需求规格说明书中的内容，那就是,违约，可能会被罚款的。,对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处,理意见，避免将来发生商业纠纷。,8,可验证,产品需求规格说明书中的各项需求对,用户方,而言应当都是可验证的（,Verifiable,）。如果需,求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。,例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？,当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试
23、验？如果双方都认可“,采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。,什么是好的需求规格说明书,37,什么是好的需求规格说明书,9,确定优先级,为什么要确定需求的“优先级”？,理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人,力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着,做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。,人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这,样可以将风险降到最低。,需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为
24、“高、中、低”三级。一般地,，由用户和开发方共同确定需求的优先级。,10,阐述“做什么”而不是“怎么做”,产品需求规格说明书的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统,设计和实现阶段的事情。,国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头,做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如,果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎,么做”写到需求规格说明书里面，记录在其它文档里就行了。,38,需,求,规,格,书,缺,陷,检,查,清,单,39,怎样看到签字,不可
25、能在项目初期就能明确所有的需求,需求肯定要随时,间的推移而发生变化,.,签字不仅仅是仪式,更重要的是建立需求的基线,.,即当时,的需求最佳理解瞬间图,.,需求基线定义好了以后,要将需求置于变更控制之下,.,用明确的协议来结束前期的需求开发活动,能帮助客户和,开发团队形成合作伙伴关系,携手走上项目成功之路,.,40,需求管理,4,需求获取,2,需求分析,3,41,需求定义,5,需求概述,1,汇报内容,_,需求管理,41,1,需求确认（评审和承诺）,需求确认是指开发方和客户方共同对产品需求规格说明书进行评审，双方对需求达成共识后,作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。,2
26、,需求评审面临的困难,需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家,都比较认真，越到后头越马虎。,需求评审涉及的人员可能比较多，有些时,候让这么多人聚在一起花费比较长的时间开会并不容易,（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开,发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员,也少一些，组织会议就比较容易。,开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远,，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。,开
27、评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而,当争议变为争吵时就坏事了，,争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。,人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都,不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的,立场思考问题，这样你会找到比较满意的答案。,需求确认与评审,42,3,需求承诺,需求承诺是指开发方和客户方的责任人对通过了正式技术评审的产品需求规格说明书作出承,诺，该承诺具有商业合同的效果。,需求承诺的“八股文”如下：,本产品需求规格说明书建立在双方对需
28、求的共同理解基础之上，我同意后续的开发工,作根据该产品需求规格说明书开展。如果需求发生变化，我们将按照“变更控制规程,”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。,甲方签字,乙方签字,人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。,需求承诺,43,4,需求变更控制,需求发生变更的起因主要有：,随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文,档可能存在这样那样的错误或不足，因此要变更需求。,市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。,提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目
29、开发小组而言，,变更,需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价,。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。,需求变更控制的目的：,如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的,变更规程执行，以免变更失去控制。,如果需求变更带来的坏处大于好处，那么拒绝变更。,需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发,方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事,先建立“游戏规则”,。,如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓
30、矛盾。例如建议在开发该产品,新版本时修改需求。,需求变更控制,44,需求变更单的内容,变更来源,变更内容及其理由,变更的影响,客户意见,需求变更评审,需求,变更单,45,5,需求跟踪,需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所有的工作成果,符合用户需求。,需求跟踪有两种方式：,正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对,应点。,逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书,中找到出处。,正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩,阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。,需求跟踪,46,让我们为项目成功,努力，享受成功带,来的幸福！,47,湖南科创信息技术股份有限公司,欢迎各位领导、专家提出宝贵建议,感谢您的关注,48,北京科创鑫源信息技术有限公司,唐玉林,48,
