内容
?需求的基本概念 ?需求获取 ?需求分析 ?需求描述 ?需求验证 ?需求管理
讨论
?你在需求的工程实践中，困扰你的问题是什么？ 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 a b i l i t y）。
–（2）系统或系统部件要满足合同、标准、规范或其它正式规 定文档所需具有的条件或能力。
–（3）一种反映上面（1）或（2）所描述的条件或能力的文档 说明。
用户的类型
客户 ?掏钱买软件的用户
最终用户?真正操作软件的用户叫最终用户。客户与最终用户可能是