实用需求工程实践精要

1需求工程实践精要麦哲思科技（北京）有限公司2内容•需求的基本概念•需求获取•需求分析•需求描述•需求验证•需求管理3讨论•你在需求的工程实践中，困扰你的问题是什么？1.需求不明细，很多不确定的地方2.需求始终在变化3.需求不断扩大范围，不好界定范围，每月增加1-3%-多个系统的架构边界不清楚：做什么，不做什么-不同厂商，不同业务部门-客户内部职责不清楚，业务重组-需求潜在变化，业务建模，流程梳理、重组4.开发人员理解的需求不是客户真正需求5.合同签订时需求模糊，后边再细化，超出成本，工期无法保证6.需求细化到什么程度7.甲方强势，乙方弱势，没有办法引导8.用例图，每个人的理解不一样，用例描述不完整9.客户需求理想化，期望值太高-要从市场人员做起10.用户不清楚应该做什么，思想混乱4常见问题•甲方：–客户需求本身不明确–开始提不出需求，软件做完后才提出需求–合同没有约束力，超出合同范围–客户之间互相扯皮，没有人拍板需求–客户方的需求负责人变更后，需求也变更•甲乙双方;–随着时间的推移，客户的业务发生变化，导致需求变化–双方沟通有失误，对需求存在误解•乙方：–不知道如何引导客户提出详细的需求–遗漏了客户的一些需求，比如操作习惯等–编写的需求客户看不懂，客户不看到实际系统无法确认需求–需求分析人员故意隐瞒了一些隐含的需求，得过且过–开发人员对需求的理解比较差5需求的基本概念6需求的重要性•需求错误导致的成本是修复程序错误成本的100倍。(Boehm1981;Grady1999)•更正需求阶段发现的错误平均仅需要花30分钟，纠正系统测试期间发现的缺陷则需要花5-17个小时。(Kelly、Sherif、Hops1992)•需求缺陷约占软件系统全部缺陷的1/3，是系统开发中最常见的缺陷(CapersJones(1994)•需求缺陷可能消耗整个项目费用预算的25%－40%•预防缺陷所花费的1美元可以为修正缺陷节约3-10美元的费用。(CapersJones(1994)7需求—导致项目失败的罪魁祸首•根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。•而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。•也就是说，有近45%的项目最终因为需求的问题最终导致失败。对不知道航行目的地的人来说，没有顺风！8我们在哪里重重摔了一跤•在StandishGroup的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：•不完整的需求(13.1%)；•缺乏用户的介入(12.4%)；•不实际的客户期望(9.9%)；•需求和规范的变更(8.7%)；•提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)9项目成功的因素•用户的参与：15.9%•管理层支持：13.9%•清晰的需求描述(13.0%)；•合适的规划(9.6%)；•现实的客户期望(8.2%)；•较小的里程碑(7.7%)；•有才能的员工(7.2%)10需求的重要性•需求错误导致的成本是修复程序错误成本的100倍11软件需求曾经让我们如此狼狈12什么是软件需求？•IEEE软件工程标准词汇表（1997年）中定义需求为：–（1）用户解决问题或达到目标所需的条件或能力（Capability）。–（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。–（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。13用户的类型•掏钱买软件的用户客户•真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人最终用户•既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响间接用户14需求获取需求获取的困难需求获取的原则与步骤需求获取的内容需求获取的常用技术15需求分析人员的沟通技巧I’llneedtoknowyourrequirementsbeforeIstarttodesignthesoftware.女程序员：我需要在我开始设计软件之前知道你的需求Firstofallwhatareyoutryingtoaccomplish?女程序员：首先您想完成什么或是达到什么目的？I’mtryingtomakeyoudesignmysoftware.客户：我想让你设计我的软件Imeanwhatareyoutryingtoaccomplishwiththesoftware?女程序员：我的意思是您想让软件完成什么或达到什么目的？Iwon’tknowwhatIcanaccomplishuntilyoutellmewhatthesoftwarecando.客户：在你告诉我软件能干什么之前我不知道我能完成什么Trytogetthisconceptthroughyourthickskull:thesoftwarecandowhateverIdesignittodo!女程序员：尝试获取通过您迟钝的头脑的思想或是概念：无论软件要实现什么我都能设计得出Canyoudesignittotellyoumyrequirements?客户：那你能够设计出告诉你我需求的软件吗？16需求获取的困难•客户不真正知道自己需要什么•难以清晰明白的表达自己的需求•不知道实现需求的成本,提出不切实际的需求•用自己的术语表达需求,需求分析人员没有领域经验•不同的需求提供者提供的需求互相矛盾17需求获取的3个原则•深入浅出–全面、深入的了解需求–简单、概括的抽象需求•以流程为主线,采用IPO的思想获取需求–从用户的角度理解需求•要从系统的全生命周期过程来考虑需求18以业务流程为主线获取需求•站在使用者的角度获取需求–业务是如何流转的？–是如何使用系统的？•采用输入、处理、输出的思想获取需求–视同整个系统为一个盒子–视同整个业务单位为一个盒子–视同某个人为一个盒子19获取系统全生命周期的需求•从系统的全生命周期的角度识别系统的功能–如何使用？–如何生产？–如何安装？–如何培训？–如何维护？–如何报废？•在每个生命周期的阶段涉及到了哪些人、设备或系统？他们会有哪些需求？20需求获取的方式•与用户个别交流•需求讨论会•查阅相关文档(文件)•分发问卷调查表•现场访问客户•业务流程分析•同类产品分析•根据现有系统推导出需求•回顾以往项目•观察用户对原有系统的使用需求获取五步法收集资料，了解概况，初步划定范围识别所有可能的需求提供者准备需要了解调研的问题调查或访谈总结归纳,准备新的问题,多次迭代2122收集资料，了解概况•通过各种方式收集客户的资料，了解系统的背景•进行总体情况的调研•初步确定系统的目标与范围23识别所有可能的需求提供者•谁使用该系统?•谁维护该系统?•谁需要从系统中获取数据?•系统的运行会影响到谁?•谁推广该系统?•谁测试该系统?•谁生产该系统?•谁购买该系统?案例：某公司用户代表的构成2425制定详细的需求调研计划•确定需求调查的方式，例如：•与用户交谈，向用户提问题。向用户群体发调查问卷。•参观用户的工作流程，观察用户的操作。•与同行、专家交谈，听取他们的意见。•分析已经存在的同类软件产品，提取需求。•从行业标准、规则中提取需求。•从Internet上搜查相关资料。•策划需求调研的活动、时间、地点、参与的人员•一次访谈不宜客户太多•需求分析员应事先了解用户的身份、背景26准备调研•通用问题列表–现有系统是如何运作的？–现有系统存在什么问题？–希望新系统解决什么问题？–客户希望如何解决问题？–希望交付哪些工作产品？–最终用户的背景如何？–对系统的速度、可靠性、安全性、数据容量的要求？–系统的运行环境是什么？–业务流程的启动条件、终止条件、正常事件流、异常事件流、输入数据、处理规则、输出数据–数据的名称、来源、计算方法、类型、计量单位、精度、取值范围、去向、生成时间、产生的频度、高峰期的频度、存储方式、保密要求–最重要的3项需求是什么？–将来有何变化?•可以采用表格的方式列举上述问题，并记录在表格中27需求获取的常用技术-需求访谈•在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题。•3人访谈小组：1人提问，1人记录，1人辅助•衣着得体，体现专业精神•准时到达，限制面谈时间•先了解宏观，再了解细节。•以IPO思想作为主线贯穿始终•在用户讲解时,不要中断用户,使对方有充分的演说机会。•注意寻找异常和错误情况•注意交谈的技巧，并尽可能多的记住用户的姓名、职务、爱好等。28需求获取的常用技术-需求访谈•详细记录–时间、地点、被访谈的人员、角色、持续的时间、参与的人员–记录需求的来源•通过需求源的信息可以知道在变更时需要咨询哪些人和哪些文档•需求源信息有利于理解需求存在的原因•常见的5个来源–需求的项目相关人员–组织的标准–技术文档–事件报告–其他需求•指出和记录下未回答条目和未解决问题•同样的需求要从不同的渠道（多于2人）进行验证29面谈之后•复查笔记的准确性、完整性和可理解性•把所收集的信息转化成适当的模型和文档•确定需要进一步澄清的问题•绘制组织结构图、业务流程图30需求发生冲突时谁决策？•由客户决策而不是由开发方决策•可以引导客户或用户进行决策，但不是替他们决策•最终用户通常比客户更有发言权31需求获取的常用技术-用例•使用用例来抽取需求–用例指与最终用户和系统之间某个交互类型有关的交互会话.最终用户使用用例来模拟他们的交互–用例可以看作是解释如何使用系统的经历.–用例描述中包含的信息:•在进入用例之前系统状态的描述•用例中正常的事件流•正常事件流的异常•可以同时运行的其他活动的信息•用例完成后系统状态的描述32UseCase编号:001UseCase名:ATM取款UseCase描述:储户使用信用卡，在ATM机上取款actor：储户前置条件：ATM机器处于正常准备状态后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。基本路径1,储户插卡；2.ATM机提示输入用户口令；3.储户输入口令；4.ATM机口令验证通过，提示输入钱数；5.储户输入钱数；6.ATM机进行钱数有效性检查，提示操作成功，吐出卡和钱；ATM取款UseCase描述337.储户取走卡和钱；8.ATM机屏幕恢复为初始状态。扩展点4a.ATM机验证用户口令不通过4a1.ATM机给出提示信息，并吐出信用卡；4a2.储户取出卡；4a3.ATM机屏幕恢复为初始状态.6a.ATM验证用户输入钱数超过30006a1.ATM机给出提示信息，并吐出信用卡；6a2.储户取出卡；6a3.ATM机屏幕恢复为初始状态.。。。。补充说明34需求获取的常用技术-原型法•原型法的目的–需求原型：获取需求–设计原型：验证技术路线–产品原型：构造产品•原型构建方法–纸上原型–界面原型–可执行的原型•原型的分类–抛弃型原型–演化型原型：必须易于升级和优化35界面原型36原型法工作流程1、用户提出系统要求2、识别、归纳上述要求3、开发一个模型／原型4、评价模型5、模型不可行处理6、模型不满意处理7、修改模型8、确定模型后的处理N、实际系统开发、运行、维护等12346758N不可行不满意满意37原型法的特点•优点：–1、开发效率高；–2、开发工具先进，与用户交流直观；–3、符合人们认识事物的规律；–4、能及早暴露系统实施后潜在的一些问题；–5、能调动用户参与的积极性。•缺点：–1、不适合大型系统的开发；–2、不适合大量运算及逻辑性强的模块；–3、对原企业基础管理工作要求较高；否则容易走上机械模拟原手工系统的轨道。–4、不适合批处理系统。38关于原型系统的原则•区分两种原型系统–抛弃型原型–演化型原型：必须易于升级和优化•原型化难以理解的需求•尽快将抛弃型原型交付给客户,不必考虑质量•必须注意精选正要开发的原型系统所包含的特性,使其能真正达到预期的目的•决不把抛弃型原型系统发展成为最终系统•利用原型减少软件开发的风险39与原型有关的度