需求分析-信息系统分析与设计-课程研讨-自主汇报-研究生-专业课 PPT课件

1 需求分析一二事 PowerPoint CompanyLogo 2 Contents CompanyLogo 3 forewords Livingwithoutanaimislikesailingwithoutacompass JohnRuskin 4 需求工程 需求工程 需求管理 需求开发 需求获取 Elicitation 需求验证 Validation 包括软件产品品中的需求收集 评价 编写文档等所有活动 建立并维护在软件工程中同客户达成的契约 需求分析 Analysis 规格说明 Specification 变更管理 5 Concepts什么是 交钥匙工程 交钥匙工程指跨国公司为东道国建造工厂或其他工程项目 一旦设计与建造工程完成 包括设备安装 试车及初步操作顺利运转后 即将该工厂或项目所有权和管理权的 钥匙 依合同完整地 交 给对方 由对方开始经营 交钥匙工程是在发达国家的跨国公司向不够开放的发展中国家投资受阻后发展起来的一种非股权投资方式 如在实行改革开放前的社会主义国家 除了前南斯拉夫 罗马尼亚等少数国家外 大多数国家不准许外来企业进行投资 因此外国企业只能依赖其他方式从事投资或经营 交钥匙工程就是其中行之有效的一种 6 另外 当自己拥有某种市场所需的尖端技术 在希望能快速地大面积覆盖市场 所能使用的资本等要素又不足的情况下 就可以考虑采用交钥匙工程方式 EPC是英文Engineering 工程设计 Procurement 设备采购 Construction 主持建设 的缩写 设计采购施工 EPC 交钥匙工程总承包 即工程总承包企业按照合同约定 承担工程项目的设计 采购 施工 试运行服务等工作 并对承包工程的质量 安全 工期 造价全面负责 7 Turnkey EPC 一个走向技术研究的极点 开发工艺包技术 一个走向工程实践的极点 搞交钥匙工程 将装置设计建设开车交钥匙 但是两者又密不可分 因为后者的工程实践中出现的问题需要前者去研究寻找理论上解决的方法或者说目标 前者的研究又需要后者提供实践验证的机会 CompanyLogo 8 为神马要做好需求 9 用案例说话 案例角色和人物 小王 软件项目负责人 老王 公司技术老总 开发小组 小朱 老曹 张哥 妹妹 10 要对软件需求进行管理 1 2 按照初步的项目计划 老赵带领项目组的部分成员 需求分析小组 开始进驻用户场地 开展需求调查工作 但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题 影响软件项目的实施整个项目规模比较庞大 需求分析小组不知如何开展工作 从何处下手 对需求分析的复杂性和难度估计不足 需求分析小组不能有效工作 不知哪些属于用户需求 哪些不是 不知怎样才能获取用户需求 如何把它分析清楚 不知应该按照怎样的规范书写软件需求规格说明书 得到的软件需求质量不高 说不清 遗漏 矛度 罗嗦 需求评审不严格 导致遗漏了许多需求 获取的用户需求不一致 描述的不清晰和准确 11 要对软件需求进行管理 2 2 更为糟糕的是 由于用户没有参加需求评审 使得许多软件需求没有得到用户的认可 最终所开发出的软件不能满足用户的要求 用户拒绝接收软件 并拒绝付款由于软件需求的不准确性 不一致性和二义性 在软件开发阶段 软件设计人员不得不通过用户再次确认需求在开发过程中 用户的需求仍然在改变 需求分析小组负责获取改变了的用户需求 然而这些改变了的需求没有得到有效的管理和控制 没能将变化的需求及时反馈给软件开发小组 导致这些需求未能在待开发的软件中得到体现由于需求未能得到有效管理 在最终项目验收过程中出现了令人不愉快的情况 实际开发的软件没能完全反映用户的需求 导致用户不满意 项目延期 12 软件需求讓我們如此狼狽 13 案例提示我们 需求分析是极为重要的需求分析是困难和复杂的用户需求经常性的变更是正常的为了保证软件需求的质量 必须对需求分析的人 过程和产品进行有效管理需求管理的不善将会导致严重后果 14 需求过程的恶性循环 15 你瞧需求多么重要 美国软件工程研究所 SEI WattsHumphrey的研究表明 对于软件中的缺陷 最佳的处理办法是及时发现及时改正 发现时间越晚 改正的难度和代价越高 下表是软件缺陷在开发期不同阶段发现和改正所需的工时的数据 16 没有 银弹 为了及时发现和改正缺点 最好办法是在注入阶段尽量将缺陷彻底清除 缺陷围堵战略 defectcontainmentStrategy 但是实现这个目标仍然缺乏有效的目标 具有很大困难 通行做法 由开发团队定期 通常是每月 编制缺陷检测报告 提交管理层 使他们了解项目进展和项目开发质量现状 17 18 关于这个表格矩阵 对角线方格的数据 就是发生在本阶段而且已经得到改正的缺陷数 其比例的高低 是围堵战略是否成功地标志 本表格 1515 1555 2421 37 1 10 0 11292 0 49软件缺陷围堵数据矩阵的另一种形式是用百分比来表示 19 需求说明的特征 完整性正确性可行性必要性划分优先等级无二义性可验证性 20 需求规格说明的特点之完整性 不能遗漏任何必要的需求信息 遗漏需求将很难查出 注重用户的任务而不是系统的功能将有助于你避免不完整性 如果知道缺少某项信息 用TBD 待确定 作为标准标识来标明这项缺漏 在开始开发之前 必须解决需求中所有的TBD项 21 需求规格说明的特点之一致性 一致性是指与其它软件需求或高层 系统 业务 需求不相矛盾 在开发前必须解决所有需求间的不一致部分 只有进行一番调查研究 才能知道某一项需求是否确实正确 22 需求规格说明的特点之可修改改性 在必要时或为维护每一需求变更历史记录时 应该修订SRS 这就要求每项需求要独立标出 并与别的需求区别开来 从而无二义性 每项需求只应在SRS中出现一次 这样更改时易于保持一致性 另外 使用目录表 索引和相互参照列表方法将使软件需求规格说明更容易修改 23 需求规格说明的特点之可跟踪性 应能在每项软件需求与它的根源和设计元素 源代码 测试用例之间建立起链接链 这种可跟踪性要求每项需求以一种结构化的 粒度好 fine grained 的方式编写并单独标明 而不是大段大段的叙述 24 需求调查研究总体思想 和用户进行充分的沟通 了解 包括项目背景 业务流程 系统用户 业务需求点等 根据用户提供的各种信息 分析具体业务需求的价值 所涉及的数据要求及需求与实际业务的关系等 根据业务需求的分析结果进行总结 考虑需求的分解和合并 实现方式 用户的使用 编写最终的功能需求类别 25 但是这不是无止境的循环 26 需求分析过程 系统实现模型 目标系統 当前系統 物理模型 逻辑模型 逻辑模型 物理模型 模型化 抽象化 实例化 具体化 理解需求 表达需求 导出 做什么 怎么做 需求分析的主要工作 系统流程图或高层DFD图 DFD图 STD图 E R图 用例图 类图 顺序图等 27 业务需求列表需求描述 需求提出部门 业务价值 使用者 客户期望 分析维度 分析指标等功能需求列表功能名称 实现方式 权限分配 输入条件 维度指标 界面展示 展现周期 数据来源等功能规格说明书根据需求功能列表整理功能规格说明书 该说明书经过用户评审 签字后作为后期设计 开发 验收的基础和依据 28 业务需求列表是从业务的角度来分析考虑用户的使用要求 具体内容可参考如下模板 Intheprocess 29 需求调研人员由用户方的业务人员和集成方的技术人员构成 技术人员以前端应用开发人员为主 后台处理人员为辅 如果需求调研分成不同小组 则在分析过程中需要有专人从总体上把握