第四章 确定系统需求.ppt

第四章 确定系统需求 学习目标 描述策划和执行面谈方案，制定执行面谈以确定系统需求计划。 设计、分发和分析调查表以确定系统需求。 观察工作人员和分析商业文档以确定系统需求的优点和缺点。 参与并帮助规划一个联合应用设计会议。 用原型化方法确定需求。 选择合适的方法以获取系统需求。 业务过程重建及其对需求确定的影响。 将需求确定技术应用于Internet应用的开发。 4.1执行需求确定 4.1.1需求确定过程 信息来源：当前系统用户、报表、表单核规程。 结构化：在需求确定阶段发现需求，并整理成表单、图表和其他格式，使其容易转换成系统的技术规范。 系统分析员确定需求时注意点 不耻下问 公正无私 放松约束 注意细节 再构造 4.1.2交付物和结果 4.1.3需求结构化 分析瘫痪（analysis paralysis）:描述一个项目在大量的分析工作前陷入困境。由于过度分析的危险，现在的系统分析员更多地关注要开发的系统，而不是现行系统。 4.2传统的需求确定方法 4.2.1面谈和倾听 面谈指南如下表 4.2.2调查表管理 选择被调查者 便于取样调查的人：工作人员愿意接受调查或者最愿意配合调查的人。 随机组 目的取样：满足某种标准的人。 分层取样：从每类人中随机选取一组人。 面谈和调查表特征比较 4.2.4直接观察用户 只能得到被观察的人或任务的短暂印象。 4.2.5分析规程和其他文档 正式制度：系统按组织文档中描述的那样运作的正式方式。 非正式制度：一个系统的实际运作方式。 4.3现代系统需求确定方法 联合应用设计（Joint Application Design， JAD） 原型化方法 4.3.1联合应用设计 起源于20世纪79年代末IBM，把参与当前系统分析的关键用户、经理和系统分析员召集在一起的方法。 通常在一个远离人们平时上班的地方举行，在同一个时间内将所有关键的人物集中在一个地方，允许分析员看到意见一致的领域和意见相左的领域。 JAD的典型参与人员 JAD会议领导：策划和领导联合应用设计会议并受过相关培训的人。 用户：唯一知道系统日常使用的人。 经理：研究系统工作组的经理。 发起人：由公司的高级人员发起。 系统分析员 抄写员：详细纪录联合应用设计会议上发生的事情 信息技术人员 4.3.2用原型化方法确定需求 适用于： 用户需求不清楚或者没有充分了解 一个或几个用户和其他风险承担者参与系统 设计可能比较复杂，并要求具体表单进行全面评价 过去用户和分析员之间存在沟通问题，并且两方都希望系统需求尽量具体 可以随时利用工具（表单，报表生成器）和数据，快速构建工作系统。 原型法缺点 倾向于取消制定系统需求的正式文档，从而可能使系统更难发展为一个完全可工作的系统 原型可能充分满足初始用户特质，而且这种特质很难散去，却很难适应潜在的用户。 原型通常作为一个独立系统建立，因而忽略数据共享以及其他现有系统交互等问题。 忽略SDLC中的检查，可能会忘掉某些较微妙的但仍然重要的系统需求（安全性、数据标准化等） 4.4用于确定系统需求的全新方法 业务过程重组（business process reengineering，BPR）：探索和实施业务过程的根本变化以实现产品和服务的突破性改进。 4.4.1识别要重建的过程 关键业务过程：为了产生特定客户或市场的特定输出而设计的一组借结构化、可度量的活动。 4.4.2破坏技术（disruptive technology） 能够使阻碍组织实现根本性变革的长期保持的业务规则得到破坏的技术。 4.5电子商务应用：系统需求确定 * * 需求确定 构造需求 选择最佳设计方案 系统分析 联合设计会议的结果、现有系统的CASE存储库内容和报告、系统原型的现实报告 基于计算机的信息 商业使命和战略声明、商业表格和报告及计算机显示样例、操作手册、作业描述、培训手册、现有系统的流程图和文档、咨询报告 现有的文档和文件 面谈记录、有效的调查问卷、观察记录、会议记录 通过与用户交谈而收集到的信息 特定交付物 交付物类型 研究商业文档以发现报告的问题、政策、法规和说明，以及组织中的数据和信息的具体使用实例。 商业文档 在选定的时间观察工作人员，查明他们是如何处理数据的一级完成他们的工作需要哪些信息 观察工作人员 通过调查表对人们进行调查，发现问题和需求 调查表 与熟悉当前系统的操作和问题及未来组织活动对系统的需求的人进行面谈 与个人面谈 涉及的活动 传统方法 与各种各样的人进行面谈，包括潜在的用户和经理。 寻找不同的观点 在会谈后的48小时内整理你的笔记。如果发现后续问题或者需要其他信息，联系受访者 整理笔记 全神贯注地倾听受访者，同时记笔记/或用磁带录音 倾听和记笔记 不要暗示性提问 保持中立 通过预约和说明面谈的目的，使受访者有