信息化建设项目需求管理课件.pptx

信息化建设项目需求管理1、软件行业的常见病q开始客户：“希望你们开发这样一个系统”。研发经理：“这很简单，我们使用Jquery、Ajax等新技术。”客户：“你们要多长时间？”研发经理：“三个月。”q结局：项目拖期交付二个月用户反应产品很难用，甚至不能用项目预算超支项目组成员精疲力竭没完没了的救火和维护2、我们经常见到的需求分析过程3、案例分析：要求：查看软件界面的1张图片，找出界面设计上存在的问题。软件界面上存在哪些问题14、原因分析p问题调查：什么是项目出麻烦的的最主要原因?需求规格50%需求管理45%软件测试 32%项目管理30%程序编码7%p统计数字需求缺陷修改成本占返工成本总额的70%需求缺陷可轻易消耗25%-40%项目预算q 需求不断增加 q 需求频繁变更 q 不完善的需求说明 q 模棱两可的需求 q 不必要的特性 q 需求说明过于精简 q 进度要求不合理q 局部变更引发连锁反应q 人员变动，搞不清为什么这么做5、软件需求的重要性q 最困难的部分:准确说明开发什么。q 最困难的工作:编写出详细的需求，包括所有面向用户、面向设备和其它软件系统的接口。需求一旦做错，将会给系统带来极大的损害，并且以后的修改也极为困难！需求是产品的根源：需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。6、双方误解需求q人们在交流时，常发生“问非所求，答非所问”的事情。q用户表达的需求有可能不清楚，不同需求分析师理解也不同，如果误解需求，导致开发人员将错就错、白干活。7、需求工程的基本概念q所有与需求直接相关的活动通称为需求工程。q需求工程中的活动可分为需求开发和需求管理两大类。需求工程需求工程需求开发需求开发需求管理需求管理版版本本控控制制需需求求确确认认需需求求跟跟踪踪变变更更控控制制需需求求获获取取需需求求分分析析编编写写规规格格说说明明验验证证业业务务需需求求用用户户需需求求功功能能需需求求非非功功能能需需求求8、软件需求的层次软件需求业务需求业务需求用户需求用户需求非功能需求非功能需求功能需求功能需求性能需求性能需求安全需求安全需求运行需求运行需求。9、软件需求的层次-业务需求q 业务需求：业务需求：反映了组织或客户对系统、产品的概括目标要求，对企业目前的业务流程进行评估，得出将来的业务前景。需求举例：明确业务运营支撑系统的体系结构、软件架构、系统边界、外部接口、系统功能及系统指标等基本定位与要求，从而为业务组织、管理及市场经营、客户服务等工作提供持续、有效地运营支撑。9、软件需求的层次-用户需求q 用户需求用户需求：描述了用户使用系统完成的任务集合，采取用例图（user case）的形式描述。9、软件需求的层次-功能需求q 功能需求功能需求：定义了系统必须完成的所有功能，源于用户需求。需求举例：查询是否有新的数据文件生成，当发现有新的数据文件时，立即把新生成的数据文件分发到指定服务器。校验接收分发文件的大小是否与数据源文件一致。9、软件需求的层次-非功能需求（性能需求）q 性能需求：描述了对系统各项性能指标的要求，例如联机系统的响应时间等。需求举例：联机数据采集设备的采集周期15分钟。10、案例分析：要求：某省共有11个地市，平均每月产生的语音话单量省会城市为6亿条/月，其他每个地市为1.8亿条/月。融合计费系统的IBM小型机上运行批价进程处理计费话单，请计算批价进程每秒处理的话单数平均达到多少条/秒时，才不会产生话单积压的现象。答案：批价进程每秒钟处理的话单数 条/秒记录处理性能指标计算11、需求分析方法-结构化分析建模I.IPO图II.数据流图III.E-R图IV.流程图V.。12、需求分析方法-结构化分析建模案例：IPO图采集预处理计费预处理原始记录标准记录预处理清单数据存储参数数据转换1转换2输入数据中间数据结果数据数据存储附加数据标准信息流图预处理信息流图12、需求分析方法-结构化分析建模采集系统原始话单文件文件序号校验文件大小校验文件名索引文件连续话单文件完整话单文件文件名校验文件命名规则文件校验正确话单记录记录级处理模块校验错误文件校验错误话单记录1.11.21.3+头文件信息文件名信息文件序号文件命名规则案例：文件级校验的数据流图12、需求分析方法-结构化分析建模案例：商品追溯实体关系图 13、需求分析方法-面向对象的分析建模案例：话费查询的用例图网上营业厅网上营业厅计费系统计费系统13、需求分析方法-面向对象的分析建模案例：订票模块的活动图14、需求分析方法-敏捷建模 需求分析与用户需求常常产生偏差，可以采用工具实现“交互”设计。比如使用Axure RP Pro或Fireworks工具软件设计软件界面原型，给用户以直观认识，进行迭代修正，以快速明确用户需求。15、案例分析-界面原型方法15、案例分析-界面原型方法案例分析：界面设计确认书16、当心需求变更q平均占用项目40%的成本q对80%软件系统造成风险q造成开发效率降低q带来新的缺陷q给项目估算带来困难q使项目超期、超支目标和范围不停变化、工作计划大幅度摆动、项目收益没有保障良好良好良好良好 警告警告警告警告预算工时预算工时预算工时预算工时变更工时变更工时变更工时变更工时优秀优秀优秀优秀危险危险危险危险利润空间利润空间利润空间利润空间总预算总预算17、CCB-唯一的变更通道q成立变更评审组（CCB）来批准变更这些人足够代表各方利益这些人有较大责任这些人有足够的权威这些人有足够的技术能力批准变更p工作职责决定是否引入项目相关的变更变更必须有“官方”批准！需求变更不可避免，有效控制需求变化对于项目成功至关重要！18、需求变更评估关键要素“我们不喜欢这样的界面，你们改一下吧。”“我们的用户数量大大超出预计，你们改一下吧。”“加一个向Excel的输出功能，你们改一下吧。”需要什么样的前提条件？系统运行产生哪些关联影响？是否具备合理性？是否属于合同范围？需求变更时限是否可行？对项目整体进度有没有影响？有没有指定责任人与验证人？感 谢 聆 听