管理信息系统 需求分析

《管理信息系统 需求分析》由会员分享，可在线阅读，更多相关《管理信息系统 需求分析（139页珍藏版）》请在金锄头文库上搜索。

1、需求分析需求导致项目失败的罪魁祸首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提供了不再需要的

2、(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用户说的不是他想的：客户提供（陈述的需求 ）的需

3、求并不是真实的需求，还需要作进一步 的分析，以确定客户的真正需求和期望，接下 来需要澄清并重新描述。可以这么说客户在理 解基础业务过程和描述自己的需求方面有很大 的差异。l需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。l共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。优秀的团队遇到糟糕的需求l用户参与不足l用户需求扩展l有歧义的需求l过于抽象的需求l忽略某种用户l不准确的计划l我们应该怎么办？l对“需求”建立正确的认识；l客户和供应商一根绳子上的两个蚂蚱；l和客户一起建立起“共同的目标”；l寻找并使用正确的、有效的需求捕获、描述（ 建模）、管理方法；l

4、动态、持续地适应需求的变化；需求是什么？业务需求l业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。l背景描述：XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信。l业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。 业务目标示例某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数

5、据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作某医院管理系统目标： B1.降低IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量业务需求就是定义系统目标l目标在哪里？业务需求是构建在“项目发起人”的脑子 里的，也就是谁提出项目，谁就拥有对“业务需求”的 最清晰的理解。l引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果

6、？l将大任务分解成为小目标，并且引导客户良好地定义 ，这也是我们形成“项目子目标描述”的关键基础。l衡量这些目标的合理性与可行性。业务需求就是定义系统目标l形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可。l在此基础上，可以编写“项目的目标和范围文档”(或称 项目综述，即POS，内容包括问题/机会、项目目标 、项目目的、成功标准、假设/风险/障碍)，对于产品 而言，我们还可以构建一个从市场角度分析的“愿景” 文档。l该部分工作是处于“需求过程”的金字塔尖，多花费一 些时间和精力是值得的，也是必要的。

7、业务需求就是定义系统目标l有了清晰的目标之 后，还应该对系统 划定范围：用户需求l用户需求是指描述用户使用产品必须要完成什么任务 ，怎么完成的需求，通常是在问题定义的基础上进用 户访谈、调查，对用户使用的场景进行整理，从而建 立从用户角度的需求。 l用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者系统需求l解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。 l解释二：从系统实现的角度描述的需求。l开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。功能需求l功能需求是需求的主体，是需求的本质l功能需求定义了：系统必须完成的那些事，即为了

8、向 它的用户提供有用的功能，产品必须执行的动作 l零散（需求项）整理（特性、用例）l敏捷方法：用户故事质量属性l产品必须具备的属性或品质 l可靠性：成熟性、容错性、易恢复性l易使用性：易理解性、易学习性、易操作性l效率：时间特性、资源特性l可维护性：易分析性、易更改性、稳定性、易测试性l可移植性：适应性、易安装性、一致性、易替换性设计约束l也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。l例如：必须采用国有自主知识版权的数据库系 统l再如：必须运行在UNIX操作系统之下优秀的需求l完整性：完整描述即将交付使用的功能，发现缺少某 项信息正确性：经过用户或用户信任的代理人审阅l可行性

9、：在已知能力和约束条件中实现l必要性：每项需求记录的功能都应是用户真正需要的l有优先次序：提供了实现优先级l无歧义：对所有读者只有一种一致的解释l可验证性：可以设计测试方法来检查检查表示例需求错误的代价需求：1设计：5编码：10测试：20-50运行与维护：200信息系统立项前的分析方法lG（目标）：要确定需要开发某个信息系统之前，应 该分析其应该达到的目标：业务性、可度量lP（问题）：要达到该目标所需解决的问题！lO（选项）：针对这些问题可选的解决方案lA（答案）：针对各种Option进行分析、评估，最终 确定答案。信息系统立项可行性分析l确定目标：信息系统实现前，信息系统实现后l提出解决方案

10、：分析P，给出O，得出Al可行性分析： 效益分析：经济可行性，投资回报 社会可行性 技术可行性信息系统立项时的常见误区l目标：含混不清，过为宏观Solution: 基于业务需求思考l解决方案：思路过于受限Solutions: 只想What，别想How 了解、理解IT技术l期望值：脱离现实l发起人、用户、使用者想法不一致 问题分析的四个步骤l问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程l在问题定义上达成共识l理解根本原因问题背后的问题l定义解决方案系统的界限l确定加在解决方案上的约束在问题定义上达成共识l把问题写下来，看每个人是否都同意l采用标准化格式： 问

11、题：描述问题 影响：确定受问题影响的风险承担人 结果：确定问题对风险承担人和商业活动的影响 优点：指出解决方案并列出主要优点理解根本原因问题背后的问题理解原因后对问题的陈述l问题：不准确的订单l影响：订单操作者、客户、生产者、销售者及客服l结果：增加废品、额外处理成本、客户不满及收益降 低l成功的解决方法： 增加输入点订单的准确性 增加销售数据的报告以便进行管理确定涉众和用户l系统的用户是谁？l还有哪些人会受系统输出的影响？l系统完成并投入使用后，有谁会对它进行评估？l还有没有其他系统内部或外部用户，他们的需要有没 有必要被考虑到？l系统将来由谁维护？l还有其他人吗？定义解决方案系统的界限l谁

12、会对系统提供信息？谁会在系统中使用信息？谁会 从系统中删除信息？l谁将操作该系统？l谁是系统的维护者？l系统将会在哪儿被使用？l系统从哪儿得到信息？l哪些外部系统要 和系统进行交互？确定加在解决方案上的约束l经济约束：预算？l行政约束：存在许可问题？潜在内外部政问题？部门 间问题？l技术约束：技术选择有何限制？限制在已有平台或技 术上？禁止使用新技术？需要购买软件包？l系统约束：建立在现有系统上？需要维护与原系统的 兼容性？必须支付什么操作系统？l环境约束：合法吗？安全性要求？其他标准限制？l进度及资源：进度要求？已有资源？外部劳动力可用 否？有无扩展资源？确定加在解决方案上的约束l操作性：销

13、售订单数据必须在数据库中备份一年，因 为数据丢失风险太大，需并行运行至少一年的数据l系统及操作系统：应用在服务器上占用不超过200M ，因为服务器上存储空间有限l设备预算：必须在已有服务器和主 机上开发l人员预算：固定的人力资源，没有外部资源l技术要求：应用新的面向对象的方法需求开发与管理需求开发活动需求获取l应收集什么信息： 问题的描述 要求解决的问题列表（需求） 用户对解系统的行为或结构施加的任何约束l信息来源： 客户（实际的和潜在的） 任何原有解系统（已有系统）及其文档 原有系统用户 / 新系统的潜在用户 应用（问题）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规需

14、求获取技术阅读背景资料头脑风暴讨论分析文档考古面谈（用户访谈）联合应用设计用户调查需求剥离现场观摩任务观察用例和场景需求获取的误区l缺乏计划性：随意、走过场，预先没计划l缺乏科学性：未从本质入手l捕获对象不明确，甚至造成岐义l过于迷信现有文档l过于迷信“听”到的东西需求捕获的主要障碍l大多数情况下，系统相关的人员无法陈述自己的需要l许多用户难以解释所执行的任务，更难解释为什么执 行这些任务l相关人员经常指定解决方案而不是需求l相关人员也难以构想出新的工作方法，或者想像出使 用提供的方法执行熟悉的任务所能够得到的结果l不同的相关人员可能持有相互矛盾的观点l相关人员经常出于抵制变更而拒绝新系统l需

15、求可能过多过度的需求l需求随着时间而变化需求捕获的各方职责l用户、顾客和客户：有责任向需求分析师提供他们的 工作知识l需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 观察和学习该项工作，从用户角度来理解它 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 发明完成该工作更好的方法 以需求规格说明书和分析模型的方式记录用户在需求捕获过程中的角色l作为设计组、专题讨论会的成员，参与设计用户界面l作为知识来源，提供任务、商业过程的当前执行情况l参与集策讨论会，提供构想、确定问题l作为测试用户，在验收时测试系统检查能否正常工作l作为审查者评估用户界面l进

16、行可用性测度，尝试使用新的用户界面执行任务需求心理学常见现象l言过其实心理：说的流程是一种理想化流程，与实际 情况严重不符l越俎代疱心理：对非自己处理的流程津津热道，根据 自己的理解、想像进行肯定的描述l非正事心理：一直忙于工作，无瑕配合需求调研l抗拒心理：新系统对其利益有损，故意不配合l推卸责任心理：装不知，说没需求需求变化的预期l流程变化：流程顺序变化，流程细节变化，流程负责 人变化，流程输入变化，流程输出变化。l数据变化：数据格式变化、数据规则变化、数据输出 变化、数据项变化l业务规则：规则增加、规则减少、规则变化l系统表现形式变化：界面、风格、输入形式、 展现方式、访问方法、网络环境系统化地组织需求捕获l应该搜集什么信息？细化地研究流程图，看看是否已 经对每个环节、每个步骤都清楚地认识了。我们应该 根据自己的理解首先对每个流程的工作进行定义，写 出