管理信息系统 需求分析

需求分析 需求 导致项目失败的罪魁祸首 l 根据 Standish Group对 23000个项目进行的研究结果 表明， 28%的项目彻底失败， 46%的项目超出经费预 算或者超出工期，只有约 26%的项目获得成功。 l 而在于这些高达 74%的不成功项目中，有约 60%的失 败是源于需求问题。 l 也就是说，有近 45%的项目最终因为需求的问题最终 导致失败。 我们在哪里重重摔了一跤 l 在 Standish Group的报告中总结了导致项目失 败的最重要的 8大原因中，有 5个与需求相关： l 不完整的需求 (13.1%)； l 缺乏用户的介入 (12.4%)； l 不实际的客户期望 (9.9%)； l 需求和规范的变更 (8.7%)； l 提供了不再需要的 (7.5%) 缺乏资源 (10.6%),没有执行层支持 (9.3%),缺少规划 (8.1%) 项目成功的因素 l 用户的参与： 15.9% l 管理层支持： 13.9% l 清晰的需求描述 (13.0%)； l 合适的规划 (9.6%)； l 现实的客户期望 (8.2%)； l 较小的里程碑 (7.7%)； l 有才能的员工 (7.2%) 软件需求曾经让我们如此狼狈 参与各方都以自已角度讲述问题 分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换 财务计算 管理报表 工作流自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 问题的根源是什么？ l 用户说的不是他想的： 客户提供（陈述的需求 ）的需求并不是真实的需求，还需要作进一步 的分析，以确定客户的真正需求和期望，接下 来需要澄清并重新描述。可以这么说客户在理 解基础业务过程和描述自己的需求方面有很大 的差异。 l 需求分析方法有问题： 系统开发人员 使用低效的需求分析和项目管理方法。 l 共同责任强调不足： 对客户和提供商 在项目成功的共同责任方面强调不够。 优秀的团队遇到糟糕的需求 l 用户参与不足 l 用户需求扩展 l 有歧义的需求 l 过于抽象的需求 l 忽略某种用户 l 不准确的计划 l 我们应该怎么办？ l 对 “需求 ”建立正确的认识； l 客户和供应商 一根绳子上的两个蚂蚱； l 和客户一起建立起 “共同的目标 ”； l 寻找并使用正确的、有效的需求捕获、描述（ 建模）、管理方法； l 动态、持续地适应需求的变化； 需求是什么？ 业务需求 l 业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。 l 背景描述： XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信。 l 业务需求 /目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短 10以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。 业务目标示例 某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作 某医院管理系统目标： B1.降低 IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量 业务需求就是定义系统目标 l 目标在哪里？业务需求是构建在 “项目发起人 ”的脑子 里的，也就是谁提出项目，谁就拥有对 “业务需求 ”的 最清晰的理解。 l 引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？ l 将大任务分解成为小目标，并且引导客户良好地定义 ，这也是我们形成 “项目子目标描述 ”的关键基础。 l 衡量这些目标的合理性与可行性。 业务需求就是定义系统目标 l 形成一个不超过 50字的项目目标，并且列出 5-9个主 要子目标，并且将其制作成一页文档，作为 “项目的 行动纲领 ”，还应该得到 “项目发起人 ”的认可。 l 在此基础上，可以编写 “项目的目标和范围文档 ”(或称 项目综述，即 POS，内容包括问题 /机会、项目目标 、项目目的、成功标准、假设 /风险 /障碍 )，对于产品 而言，我们还可以构建一个从市场角度分析的 “愿景 ” 文档。 l 该部分工作是处于 “需求过程 ”的金字塔尖，多花费一 些时间和精力是值得的，也是必要的。 业务需求就是定义系统目标 l 有了清晰的目标之 后，还应该对系统 划定范围： 用户需求 l 用户需求是指描述用户使用产品必须要完成什么任务 ，怎么完成的需求，通常是在问题定义的基础上进用 户访谈、调查，对用户使用的场景进行整理，从而建 立从用户角度的需求。 l 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者 系统需求 l 解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。 l 解释二：从系统实现的角度描述的需求。 l 开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。 功能需求 l 功能需求是需求的主体，是需求的本质 l 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 l 零散（需求项） 整理（特性、用例） l 敏捷方法：用户故事 质量属性 l 产品必须具备的属性或品质 l 可靠性：成熟性、容错性、易恢复性 l 易使用性：易理解性、易学习性、易操作性 l 效率：时间特性、资源特性 l 可维护性：易分析性、易更改性、稳定性、易测试性 l 可移植性：适应性、易安装性、一致性、易替换性 设计约束 l 也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 l 例如：必须采用国有自主知识版权的数据库系 统 l 再如：必须运行在 UNIX操作系统之下 优秀的需求 l 完整性：完整描述即将交付使用的功能，发现缺少某 项信息正确性：经过用户或用户信任的代理人审阅 l 可行性：在已知能力和约束条件中实现 l 必要性：每项需求记录的功能都应是用户真正需要的 l 有优先次序：提供了实现优先级 l 无歧义：对所有读者只有一种一致的解释 l 可验证性：可以设计测试方法来检查 检查表示例 需求错误的代价 需求： 1 设计： 5 编码： 10 测试： 20-50 运行与维护： 200 信息系统立项前的分析方法 l G（目标）：要确定需要开发某个信息系统之前，应 该分析其应该达到的目标：业务性、可度量 l P（问题）：要达到该目标所需解决的问题！ l O（选项）：针对这些问题可选的解决方案 l A（答案）：针对各种 Option进行分析、评估，最终 确定答案。 信息系统立项可行性分析 l 确定目标：信息系统实现前，信息系统实现后 l 提出解决方案：分析 P，给出 O，得出 A l 可行性分析： 效益分析：经济可行性，投资回报 社会可行性 技术可行性 信息系统立项时的常见误区 l 目标：含混不清，过为宏观 Solution: 基于业务需求思考 l 解决方案：思路过于受限 Solutions: 只想 What，别想 How 了解、理解 IT技术 l 期望值：脱离现实 l 发起人、用户、使用者想法不一致 问题分析的四个步骤 l 问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程 l 在问题定义上达成共识 l 理解根本原因 问题背后的问题 l 定义解决方案系统的界限 l 确定加在解决方案上的约束 在问题定义上达成共识 l 把问题写下来，看每个人是否都同意 l 采用标准化格式： 问题：描述问题 影响：确定受问题影响的风险承担人 结果：确定问题对风险承担人和商业活动的影响 优点：指出解决方案并列出主要优点 理解根本原因 问题背后的问题 理解原因后对问题的陈述 l 问题：不准确的订单 l 影响：订单操作者、客户、生产者、销售者及客服 l 结果：增加废品、额外处理成本、客户不满及收益降 低 l 成功的解决方法： 增加输入点订单的准确性 增加销售数据的报告以便进行管理 确定涉众和用户 l 系统的用户是谁？ l 还有哪些人会受系统输出的影响？ l 系统完成并投入使用后，有谁会对它进行评估？ l 还有没有其他系统内部或外部用户，他们的需要有没 有必要被考虑到？ l 系统将来由谁维护？ l 还有其他人吗？ 定义解决方案系统的界限 l 谁会对系统提供信息？谁会在系统中使用信息？谁会 从系统中删除信息？ l 谁将操作该系统？ l 谁是系统的维护者？ l 系统将会在哪儿被使用？ l 系统从哪儿得到信息？ l 哪些外部系统要 和系统进行交互？ 确定加在解决方案上的约束 l 经济约束：预算？ l 行政约束：存在许可问题？潜在内外部政问题？部门 间问题？ l 技术约束：技术选择有何限制？限制在已有平台或技 术上？禁止使用新技术？需要购买软件包？ l 系统约束：建立在现有系统上？需要维护与原系统的 兼容性？必须支付什么操作系统？ l 环境约束：合法吗？安全性要求？其他标准限制？ l 进度及资源：进度要求？已有资源？外部劳动力可用 否？有无扩展资源？ 确定加在解决方案上的约束 l 操作性：销售订单数据必须在数据库中备份一年，因 为数据丢失风险太大，需并行运行至少一年的数据 l 系统及操作系统：应用在服务器上占用不超过 200M ，因为服务器上存储空间有限 l 设备预算：必须在已有服务器和主 机上开发 l 人员预算：固定的人力资源，没有外部资源 l 技术要求：应用新的面向对象的方法 需求开发与管理 需求开发活动 需求获取 l 应收集什么信息： 问题的描述 要求解决的问题列表（需求） 用户对解系统的行为或结构施加的任何约束 l 信息来源： 客户（实际的和潜在的） 任何原有解系统（已有系统）及其文档 原有系统用户 / 新系统的潜在用户 应用（问题）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规 需求获取技术 阅读背景资料 头脑风暴 讨论分析 文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离 现场观摩 任务观察 用例和场景 需求获取的误区 l 缺乏计划性：随意、走过场，预先没计划 l 缺乏科学性：未从本质入手 l 捕获对象不明确，甚至造成岐义 l 过于迷信现有文档 l 过于迷信 “听 ”到的东西 需求捕获的主要障碍 l 大多数情况下，系统相关的人员无法陈述自己的需要 l 许多用户难以解释所执行的任务，更难解释为什么执 行这些任务 l 相关人员经常指定解决方案而不是需求 l 相关人员也难以构想出新的工作方法，或者想像出使 用提供的方法执行熟悉的任务所能够得到的结果 l 不同的相关人员可能持有相互矛盾的观点 l 相关人员经常出于抵制变更而拒绝新系统 l 需求可能过多 过度的需求 l 需求随着时间而变化 需求捕获的各方职责 l 用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 l 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 观察和学习该项工作，从用户角度来理解它 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 发明完成该工作更好的方法 以需求规格说明书和分析模型的方式记录 用户在需求捕获过程中的角色 l 作为设计组、专题讨论会的成员，参与设计用户界面 l 作为知识来源，提供任务、商业过程的当前执行情况 l 参与集策讨论会，提供构想、确定问题 l 作为测试用户，在验收时测试系统检查能否正常工作 l 作为审查者评估用户界面 l 进行可用性测度，尝试使用新的用户界面执行任务 需求心理学 常见现象 l 言过其实心理：说的流程是一种理想化流程，与实际 情况严重不符 l 越俎代疱心理：对非自己处理的流程津津热道，根据 自己的理解、想像进行肯定的描述 l 非正事心理：一直忙于工作，无瑕配合需求调研 l 抗拒心理：新系统对其利益有损，故意不配合 l 推卸责任心理：装不知，说没需求 需求变化的预期 l 流程变化：流程顺序变化，流程细节变化，流程负责 人变化，流程输入变化，流程输出变化。 l 数据变化：数据格式变化、数据规则变化、数据输出 变化、数据项变化 l 业务规则：规则增加、规则减少、规则变化 l 系统表现形式变化：界面、风格、输入形式、 展现方式、访问方法、网络环境 系统化地组织需求捕获 l 应该搜集什么信息？ 细化地研究流程图，看看是否已 经对每个环节、每个步骤都清楚地认识了。我们应该 根据自己的理解首先对每个流程的工作进行定义，写 出事件流，并且标识出疑问点，这些都将使我们明白 “应该收集什么信息 ”。 l 从哪搜集这些信息？ 流程涉及到什么部门、岗位，答 案就应该从谁身上找。 l 用什么机制来搜集？ 需求捕获技术有多种，重点在于 因地制宜地使用不同的机制 流程图 用户访谈 l 用户访谈 ：最基本、最常见的技术 l 利：直接有效、形式灵活、交流深入，应该做为主要 的需求捕获技术（宽带通信、固有灵活性、各类信息 ） l 弊：占用时间长（特别当客户忙时更显示出其不足） 、面窄而容易造成信息的片面性。 l 要点：首先要有准备：通常包括说明对流程的理解， 并征得客户的意见；预先根据流程中的不明确点设计 要询问的问题，并将客户的反馈记录下来；应留有一 些即兴的空间，根据实际情况应变，以确保信息完善 。第二是要有计划性：计划好时间、计划好人员、计 划好策略。 用户访谈：询问的问题 l 问题类型：待解决的问题、开发解决方案的过程、需 求获取本身 l 需求获取本身的问题： 我的问题看起来相关吗？ 你的回答正式吗？ 你是回答这些问题的最佳人选吗？ 我问了太多的问题吗？ 还有其他什么我该问你的？ 你想问我什么？ 我还应该见其他什么人？ 关于这个项目有什么人我们不需要？ 用户访谈：主要困难 l 缺乏对所需要的人的访问（知道最多的人最忙） l 在面谈时记录信息很困难 l 被访谈人会试图说他们认为你想要听的话 l 访谈人用诱导性问题提问 l 束缚关键职员的有关费用 l 由不同领域知识和行话引起的交流困难 l 隐蔽的动机和组织政策产生错误信息 用户调查：概述 l 用户调查： 调查面最广的技术 l 利：面广，能够获得更多的人的反馈。这点是对用户 访谈技术不足之处的最好补充。 l 弊：不够深入，容易形而上学。而这点是正是用户访 谈技术所能够解决的。 l 要点：结合用户访谈技术使用，具体来说：先设计问 题，制作成为用户调查表，下发填写完后，进行仔细 的分组、整理、分析，以获得基础信息，然后再针对 这个结果进行小范围的用户访谈，作为补充。 用户调查：主要用途 l 搜索某项假设的统计依据 ：设计一些封闭的问题，例 如 “从现有系统中取得客户统计资料的难易程度：非 常困难、相当困难、容易、非常容易 ” l 搜索意见、建议 ：询问与用户访谈类似的开放性问题 ，例如 “日常工作中的三个最大问题是什么？ ”， “你对 能够更好地支持日常工作的 IT系统有什么建议 ”。 -误 解你的问题，你误解他的回答 现场观摩：概述 l 现场观摩： 最生动的技术 l 利：百闻不如一见，能够对需求与业务流程建立直观 的认识。 l 弊：消耗时间长，而且由于 “被观摩 ”的微妙心理变化 ，会使得 “观摩 ”失真。 l 适用性：要对于复杂流程的更加深入的 理解时。 l 要点：悄悄地进行，明确要强化理解的 具体流程环节。 现场观摩：常用变体 l 任务示范： 要求用户示范如何执行特定的任务 l 利：可用于发现异常的、关键性的任务 l 弊： “示范 ”失真、耗时 l 做学徒： 和用户坐在一起，通过观察、问问题、并在 用户指导下完成一些工作来学习 l 适用性：用户无法详细解释清楚他们在做什么时 l “人们正在做一件事时，最能解释他们在 做什么，为什么要这么做 ” l 需求分析员可以通过学徒关系试验他的 需求和设计思想 联合开发：概述 l 联合开发： 最理想的技术 l 利：客户、开发人员直接的头脑风暴，是击破需求盲 点的关键手段。 l 弊：成本高，如果缺乏控制会变成一次闲扯大会。 l 要点：需要有一个经验丰富、能够把控大局的主持人 。 联合开发：优点 l 协助建立一支高效的团队，围绕一个目的：项目成功 l 所有风险承担人都畅所欲言，没人被落下 l 正如应用项目所必须做的，它促进风险承担人和开发 团队之间达成共识 l 它能够揭露和解决那些妨碍项目上成功的行政问题 l 能够产生一个在特征级别上的初步系统定义 需求开发与需求管理的分界 需求基线管理 l 频繁的需求变更会破坏开发的节奏，使整个项目开发 的进度陷入混乱和失控的状态，而且会变成一个 “救 火队 ”式的工作，整天都在处理突发事件 l 将所有现在的、将来的需求进行优先级评估，然后分 解成为不同的组，每次迭代都选择其中优先级最高的 部分进行开发，然后在迭代完成之前，开发工作不响 应变更，这些划入的需求项就是需求基线的组成部分 需求基线管理 操作思路 l 我们应该在分析的基础上，将需求整合成为用例或功 能项，然后对其进行优先级、依赖性进行综合性评估 l 优先级判断：业务人员确定业务决定，技术人员确定 技术决策； “满意度 /不满意度 ”模型 l 依赖性是指对于某些功能，在实现上有必须的依赖关 系，即当某些功能没有实现时，另外的功能无法开始 ，这就需要对其进行调整 需求变更管理 l 需求变更是一定存在的，而需求变更管理并不是指逃 避它，更不是说要避免它，它实际上是希望控制变更 l 在基线内的需求不响应变更，为开发人员提供一个安 静的工作时间状态 l 专门的需求变更管理来对所有的需求变更进行响应， 了解需求变更的关键意图、新产生的工作量，从而良 好地进行重新计划，以便能够有效地解决其对整个开 发带来的麻烦 需求变更管理 变更的流程 l 提出变更：正式的方式提交变更是很重要的，合约式 的沟通平台 l 变更评估： 合理性评估 ，进一步了解其变更的主要原 因，认清其是否是因为沟通上的误会与不理解而造成 的不必要的变更； 工作量评估 则是评估其对进度的影 响； 影响面分析 则是评估该变更会对哪些部分工作产 生影响，具体地说会对哪些人的工作产生影响 l 分级响应评估：不影响相关模块开发进度的，可直接 响应；影响本模块开发进度但不影响项目总体进度的 ，可由项目经理协调后直接响应；影响项目进度的， 则应该交与客户协商响应方式 需求跟踪 l 需求的跟踪是指对需求的完成情况、变更影响进行系 统化的跟踪与处理 l “需求是不是已经被实现？ ”、 “需求的变化将需要修改 哪些设计元素？会影响谁的工作？对已经完成的部分 是否有影响？ ” 需求管理的参与者 需求分析师 l 需求分析员是对项目涉众的需求进行收集、分析、记 录和验证等职责的主要承担者，是用户群体与软件开 发团队间进行需求沟通的主要渠道 l 典型活动：定义业务需求、确定项目涉众和用户类别 、获取需求、分析需求、为需求建模、编写需求规格 说明、主持对需求的验证、引导对需求的优先级划分 、管理需求 l 必备技能：倾听、交谈和提问的技巧，分析、 协调、观察、写作、组织、建模、人际交 往和创造能力 需求分析师 l 必备知识：现代需求管理技术、各种软件开发生命周 期、领域知识 l 需求分析员的来源：用户转为分析员（软件工程知识 欠缺）、开发人员转为分析员（领域知识、沟通能力 ）、主题专家（易按自己的偏好来构建系统） 系统分析 l 1、 组织 结构和功能业务 l 2、组织目标和发展战略 l 3、工艺流程和产品构成 l 4、数据与数据流程 l 5、业务 流程与工作模式 l 6、管理方式和具体业务进行方法 l 7、决策方式和决策过程 l 8、 可用 资源和限制条件 l 9、现存问题和改进意见 一、组织结构一、组织结构 组织结构指的是一个组织（部门、企业 、车间、科室等）以及这些组成部分之间的 隶属关系或管理与被管理的关系。通常可用 组织结构图来表示。 厂长 计划调度组 计划科 生产部 财务部 供销科 计划组 统计组 统计组外协组 成本组 会计组 出纳组 供应组 销售组 仓 库 组织结构图 二、业务功能二、业务功能 为了实现系统的目标，系统必须具有各 种功能。 如何理解 功能 所谓功能，指的是完成某项工作的能力。 可以用功能层次图来描述从系统目标到各项功 能的层次关系。 销售系统的管理功能图 业务流程业务流程 业务流程应顺着原系统信息流动的过程逐步地 进行，内容包括：各环节的处理业务、信息来源、 处理方法、计算方法、信息流经去向、提供信息的 时间和形态（报告、单据、屏幕显示等）。 （ 1）业务流程的内容）业务流程的内容 （ 2）业务流程图）业务流程图 管理业务流程图是一种描述系统内各单位、人员 之间业务关系、作业顺序和管理信息流向的图表，利 用它可以帮助分析人员找出业务流程中的不合流理向 。 业务流程常用符号业务流程常用符号 案例案例 某企业物资管理的业务流程分析某企业物资管理的业务流程分析 1. 车间填写领料单到仓库领料，库长根据用料计划审批领料单， 未批准的领料单退回车间。 2. 库工收到已批准的领料单后，首先查阅库存账，若有货，则通 知车间前来领取所需物料，并登记用料流水账，否则将通知采 购人员缺货。 3. 采购人员根据缺货通知，查阅订货合同单，若已订货，则向供 货单位发出催货请求，否则就临时申请补货。 4. 供货单位发出货物后，立即向订货单位发出提货通知。 5. 采购人员收到提货通知单后，就可办理入库手续。 6. 库工验收入库，并通知车间领料。 7. 仓库库工还要依据库存账和用料流水账定期生成库存的报表， 呈送有关部门。 图例图例 说明说明 业务处理业务处理 单位单位 业务处理业务处理 描述描述 表格制作表格制作 传递传递 存储存储 收集资料收集资料 计划 处 银行 技改 处 各部门 各单位 局 领导 上级 领导 投资 总规划 更新改造 贷款规模 开会 讨论 报表 审批 综合平衡 （讨论） 批准 下达 各单位 各部门 正式 计划 计划 各单位 上报表 计划 处 各部门 各单位 技改 处 银行 各部门 各单位 存档 数据流程数据流程 一、数据流程的作用一、数据流程的作用 为了用计算机进行信息管理，还必须进 一步舍去物质要素，收集有关资料，绘制出 原系统的数据流程图，为下一步分析做好准 备。 二、数据流程的内容二、数据流程的内容 p收集原系统全部输入单据、输出报表和数据 存储介质（如账本、清单等）。 p弄清各环节上的处理方法和计算方法。 p在上述各种单据、报表、账本的典型样品上 或用附页注明制作单位、报送单位、存放地点 、发生频度、发生的高峰时间及发生量等。 p并在上述各种单据、报表、账册的典型样品 上注明各项数据的类型、长度、取值范围。 三、数据的来源三、数据的来源 p现行组织机构 p现行各系统或部门的业务流程 p各种会议的决议 p计算机文件（或数据库）系统的数据组织结构 p上级下达的各种文件和各项任务指标 p与本单位有关的其它单位的有关信息 p其它各种报表、报告、图表 四、数据流程图四、数据流程图 数据流程图是一种能全面地描述信息系统逻 辑模型的主要工具，它可以用少数几种符号综合地 反映出信息在系统中的流动、处理和存储情况。 （ 1） 定定 义义 数据流程图具有抽象性，表现在它完全舍去了 具体的物质（如业务流程图中的车间、人员等）， 只剩下数据的流动、加工处理和存储；数据流程图 具有概括性，它可以把信息中的各种不同业务处理 过程联系起来，形成一个整体。 （ 2） 特特 点点 （ 3）数据流程图的常用符号）数据流程图的常用符号 l不受系统控制，位于系统边界以外 l数据处理的外部来源和去处 l为避免交叉，可出现若干次。 名称 标识 功能描述 完成者 l标识：数字（编号、层次） l功能描述：祈使句（动 +名） l逻辑描述 l数据存储的地方 l ，表示流动的方向 l名称（名词） l唯一与其他图例都有联系 名称 （ 4）常用符号的画法）常用符号的画法 为了使图形清晰，避免流线交叉，同一外部实体 可在不同处出现。外部实体要有标记。同一实体在不 同处出现，要在右下角打上斜线。 外部实体 数据流可以是双向的。数据流上要有文字 说明，也可以加符号。 数据流 处理块的画法可以有标识、功能描述、实 行的部门或程序名。 处 理 l数据存储也有标识和名称。 l指向数据存储的数据流箭头说明是读出还是写入。 l有时可用小三角形 来表示搜索关键字。 数据存储 （ 5）数据流程图的实例）数据流程图的实例 厂办 统计表 销售统计 用户 合同 合同登记处理 合同数据 合同台账 合同执行 登记 销售分 配处理 库存台账车间 入库单 入库处理 入库数据 出库数据 查 询 查 询 出库处理 发货 处理 发货 通知 出 库 单 出 库 单 财务科 p首先画出顶层（第一层）数据流程图。顶层数据流程图只有一张 ，它说明了系统的总的处理功能、输入和输出。 p下一步是对顶层数据流程图中的 “ 处理 ” 进行分解。 （ 6）数据流程图的画法）数据流程图的画法 （ 1）数据流程图是分层次的，绘制时采取自顶向 下逐层分解的办法。 （ 2）数据流程图分多少层次应现实际情况而定， 对于一个复杂的大系统，有时可分至七八层之多。为 了提高规范化程度，有必要对图中各个元素加以编号 。 （ 3）通常在编号之首冠以字母，用以表示不同的 元素，可以用 P表示处理， D表示数据流， F表示数 据存储， S表示外部实体。例如： P3.1.2表示第三 子系统第一层图的第二个处理。 按业务流程图理出的业务流程顺序， 将相应调查过程中所掌握的数据处理过程， 绘制成一套完整的数据流程图，一边整理绘 图，一边核对相应的数据和报表、模型等。 如果有问题，则定会在这个绘图和整理过 程中暴露出来。 由于实际数据处理过程常常比较繁杂，故 应该按照系统的观点，自顶向下地分层展开绘制。 黑 灰 半透明 透明 分层数据流程图 IDEF0图 用户 P1 销售处理 订货单 发货单 展展 开开 （ 3）与规划中的企业模型相对应 p外部项的确定也就是规定了系统与外部环境的分界线 （ 7）绘制数据流程图应遵循的原则）绘制数据流程图应遵循的原则 （ 1）首先确定系统的外部项 （ 2）高层流程图与中、低层流程图的分工 p高层中只画出系统正常运行时的主要输入和输出。 p对于错误或例外条件所产生的数据流不在高层中反映。 （ 4）按从左到右、从上到下的原则进行 （ 5）反复修改，仔细检查，保证其正确性 。 案例案例 1 某企业财务管理的数据流程分析某企业财务管理的数据流程分析 p采用 “ 自顶向下 ” 的原则进行 p是否有遗漏的数据处理功能 p有关数据载体部分是否与业务流程图一致 （ 8）业务流程图）业务流程图 数据流程图的检查数据流程图的检查 （ 1） 检查 DFD和 TFD的一致性 （ 2）检查 DFD的一致性和完整性 p检查数据流，确认数据流是否有遗漏或多余 p检查数据存储，是否没有被业务过程使用或没有生成它的业务过程（ 根据 C/U矩阵的判别标准来进行） p检查处理功能，所有的处理功能都应有输入数据流或从数据存储中检 索数据，也要有输出的数据流或向数据存储中发送数据。 课堂讨论背景资料：课堂讨论背景资料： 汽车配件公司分层数据流程图绘制汽车配件公司分层数据流程图绘制 第一层数据流程图（环境图） 顾客顾客 供应商供应商 1 处理处理 业务业务 订货单订货单 发货单发货单 订货单订货单 发货单发货单 配件库存配件库存 第二层数据流程图 顾客顾客 供应商供应商销售销售 订货单订货单 发货单发货单 配件库存配件库存 1 1 采购采购 1 2 订货单订货单 发货单发货单 到货通知到货通知 会计会计 1 3 收收 据据 应应 付付 款款 通通 知知 向供应商的订货单向供应商的订货单 第 三 层 数 据 流 程 图 顾客顾客 采购采购 编编 辑辑 订货单订货单 订货单订货单 配件库存配件库存 1.1.1 确确 定定 顾顾 客客 订订 货货 1.1.3 产产 生生 暂暂 存存 订货单订货单 1.1.5 对对 照照 暂暂 存存 订货单订货单 1.1.6 业务业务 员员 开发货开发货 单并修单并修 改库存改库存 1.1.4 不合格不合格 顾客顾客D2 D3 可发可发 订货订货 不满足不满足 的订货的订货 登登 录录 新顾客新顾客 数数 据据 1.1.2 暂存订货单暂存订货单D4 到到 货货 通通 知知 新顾客新顾客 编制销编制销 售和库售和库 存报表存报表 1.1.8 销售历史销售历史D5 应收款明细账应收款明细账D10 配件库存配件库存D3 合格的订货单合格的订货单 检检 索索 库库 存存 1.1.7 经理经理 询询 问问 库库 存存 库库 存存 状状 态态 第四节第四节 数据字典数据字典 一、数据字典的含义一、数据字典的含义 是在新系统数据流程图的基础上， 进一步定义和描述所有数据的工具，包 括对一切动态数据（数据流）和静态数 据（数据存贮）的数据结构和相互关系 的说明，是数据分析和数据管理的重要 工具，是系统设计阶段进行数据库（文 件）设计的参考依据。 二、数据字典的内容二、数据字典的内容 主要是对数据流程图 中的数据项、数据结构、 数据流、处理逻辑、数据 存储和外部实体等六个方 面进行具体的定义。 数据字典是关于数据流程图内所包含的数据元数据字典是关于数据流程图内所包含的数据元 素（数据存储、数据流、数据项）的定义及说明的素（数据存储、数据流、数据项）的定义及说明的 集合。集合。 数据字典由数据流、文件（数据存储）和数据项数据字典由数据流、文件（数据存储）和数据项 （数据元素）三类条目组织。（数据元素）三类条目组织。 数据字典要求：数据字典要求： 1）完整性）完整性 2）一致性）一致性 3）可用性）可用性 （ 1）数据项的定义）数据项的定义 数据项又称数据元素，是数据的最小 单位。 分析数据特性应从静态和动态两个 方面去进行。在数据字典中，仅定义数据 的静态特性。 1.数据项的名称、编号、别名和简述； 2.数据项的长度； 3.数据项的取值范围。 （ 2）数据结构的定义）数据结构的定义 数据结构描述某些数据项之间的关系 。一个数据结构可以由若干个数据项组成 ；也可以由若干个数据结构组成，还可以 由若干个数据项和数据结构组成。 1.数据结构的名称和编号； 2.简述； 3.数据结构的组成。 （ 3）数据流的定义）数据流的定义 数据流由一个或一组固定的数据项组成 。定义数据流时，不仅要说明数据流的名称 、组成等，还应指明它的来源、去向和数据 流量等。 （ 4）处理逻辑的定义）处理逻辑的定义 处理逻辑的定义仅对数据流程图中最底 层的处理逻辑加以说明。 （ 5）数据存储的定义）数据存储的定义 数据存储在数据字典中只描述数据的逻 辑存储结构，而不涉及它的物理组织。 （ 6）外部实体的定义）外部实体的定义 外部实体定义包括：外部实体编号、名 称、简述、及有关数据流的输入和输出。 第五节第五节 描述处理逻辑的工具描述处理逻辑的工具 一、判断树一、判断树 库存量 欠款时间 30天 100天 30天 100天 需求量 需求量 库存量 库存量 库存量 先按库存发货， 进货后再补发 先付款，再发货 立即发货 不发货 通知先付欠款 处理方案 这是一张用于查找产品并计算金额的判 断树，以说明对不同交易额、不同信誉、不 同交易时间的顾客所采取的不同优惠待遇。 判断树比较直观，容易理解，但当条件 多时，不容易清楚地表达出整个判别过程。 二、判断表（决策表二、判断表（决策表 ） l 判断表（决策表）可以清晰地表达条 件、决策规则和应采取的行动之间的逻辑关 系。 决策规则号 1 2 3 4 5 6 条 件 欠款时间 30天 Y Y N N N N 欠款时间 100天 N N Y Y N N 需求量 库存量 Y N Y N Y N 应采 取的 行动 立即发货 先按库存量发货 ,进货后再补发 先付款 ,再发货 不发货 要求先付欠款 条件语句 行动语句 条件项 行动项 三、结构英语表示法三、结构英语表示法 l 是一种模仿计算机语言的处理逻辑描述 方法。它使用了由 “IF、 “THEN“、 “ELSE“ 等词组成的规范化语言。 第六节第六节 系统化分析系统化分析 在原系统详细调查的基础上进行系统分 析是提出新系统逻辑模型的重要步骤。这一 步骤通过对原有系统的调查和分析，找出原 系统业务流程和数据流程的不足，提出优化 和改进的方法，给出新系统所要采用的信息 处理方案。 一、分析系统目标一、分析系统目标 根据详细调查对可行性分析报告中提出 的系统目标作再次考察，对项目的可行性和 必要性进行重新考虑，并根据对系统建设的 环境和条件的调查修正系统目标，使系统目 标适应组织的管理需求和战略目标。 二、分析业务流程二、分析业务流程 分析原有系统中存在的问题以对现有业 务流程进行重组，产生新的更为合理的业务 流程。 业务流程分析过程包括以下内容