实用需求工程实践.docxVIP

内容?需求的基本概念?需求获取?需求分析?需求描述?需求验证?需求管理讨论?你在需求的工程实践中，困扰你的问题是什么？1.需求不明细，很多不确定的地方2.需求始终在变化3.需求不断扩大范围，不好界定范围，每月增加1-3%-多个系统的架构边界不清楚：做什么，不做什么-不同厂商，不同业务部门-客户内部职责不清楚，业务重组-需求潜在变化，业务建模，流程梳理、重组4.开发人员理解的需求不是客户真正需求5.合同签订时需求模糊，后边再细化，超出成本，工期无法保证6.需求细化到什么程度7.甲方强势，乙方弱势，没有办法引导8.用例图，每个人的理解不一样，用例描述不完整9.客户需求理想化，期望值太高-要从市场人员做起10.用户不清楚应该做什么，思想混乱常见问题?甲方：–客户需求本身不明确–开始提不出需求，软件做完后才提出需求–合同没有约束力，超出合同范围–客户之间互相扯皮，没有人拍板需求–客户方的需求负责人变更后，需求也变更?甲乙双方;–随着时间的推移，客户的业务发生变化，导致需求变化–双方沟通有失误，对需求存在误解?乙方：–不知道如何引导客户提出详细的需求–遗漏了客户的一些需求，比如操作习惯等–编写的需求客户看不懂，客户不看到实际系统无法确认需求–需求分析人员故意隐瞒了一些隐含的需求，得过且过–开发人员对需求的理解比较差需求的重要性?需求错误导致的成本是修复程序错误成本的100倍。(Boehm1981;Grady 1999)?更正需求阶段发现的错误平均仅需要花30分钟，纠正系统测试期间发现的缺陷则需要花5-17个小时。(Kelly、Sherif、Hops 1992)?需求缺陷约占软件系统全部缺陷的1/3，是系统开发中最常见的缺陷( Capers Jones(1994)?需求缺陷可能消耗整个项目费用预算的25%－40%?预防缺陷所花费的1美元可以为修正缺陷节约3-10美元的费用。 ( Capers Jones(1994)需求—导致项目失败的罪魁祸首?根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。?而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。?也就是说，有??45%的项目最终因为需求的问题最终导致失败。我们在哪里重重摔了一跤?在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：?不完整的需求(13.1%)；?缺乏用户的介入(12.4%)；?不实际的客户期望(9.9%)；?需求和规范的变更(8.7%)；?提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)项目成功的因素?用户的参与：15.9%?管理层支持：13.9%?清晰的需求描述(13.0%)；?合适的规划(9.6%)；?现实的客户期望(8.2%)；?较小的里程碑(7.7%)；?有才能的员工(7.2%)需求的重要性?需求错误导致的成本是修复程序错误成本的100倍什么是软件需求？?I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为：–（1）用户解决问题或达到目标所需的条件或能力（ C a p ab i l i t y）。–（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。–（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。用户的类型客户 ?掏钱买软件的用户最终用户?真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。最终用户间接用户 ?既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响需求获取需求获取的困难需求获取的原则与步骤需求获取的内容需求获取的常用技术需求获取的困难?客户不真正知道自己需要什么?难以清晰明白的表达自己的需求?不知道实现需求的成本,提出不切实际的需求?用自己的术语表达需求,需求分析人员没有领域经验?不同的需求提供者提供的需求互相矛盾需求获取的3个原则?深入浅出–全面、深入的了解需求–简单、概括的抽象需求?以流程为主线,采用IPO的思想获取需求–从用户的角度理解需求?要从系统的全生命周期过程来考虑需求以业务流程为主线获取需求?站在使用者的角度获取需求–业务是如何流转的？–是如何使用系统的？?采用输入、处理、输出的思想获取需求–视同整个系统为一个盒子–视同整个业务单位为一个盒子–视同某个人为一个盒子获取系统全生命周期的需求?从系统的全生命周期的角度识别系统的功能–如何使用？–如何生产？–如何安装？–如何培训？–如何维护？–如何报废？?在每个生命周期的阶段涉及到了哪些人、设备或系统？他们会有哪些需求？需求获取的方式?与用户个别交流?需求讨论会?查阅相关文档