需求分析师培训-1.ppt

理解原因后对问题的陈述 问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降低 成功的解决方法： 增加了输入点订单的准确性 增加了销售数据的报告以便进行管理 获得更好的效率 理解原因后对问题的陈述 问题：随时提供大学体育赛事的必威体育精装版报道 影响：移动办公的人群 结果：他们不可能花很多时间来有哪些信誉好的足球投注网站他们感兴趣的新闻，因此无法随时了解到有关他们母校的赛事（或者他们感兴趣的其他大学的体育赛事）。 成功的解决方法：当发生他们感兴趣的新闻时，向他们发出通知，并提供一个地点来为他们提供所请求的新闻。 理解根本原因—问题背后的问题 TQM的鱼骨图 帕雷托图 确定涉众和用户 系统的用户是谁？ 系统的客户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没有必要被考虑到？ 系统将来由谁维护？ 还有其他人吗？ 用洋葱图来寻找涉众 定义解决方案系统的界限 谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？ 谁将操作该系统？ 谁是系统的维护者？ 系统将会在哪儿被使用？ 系统从哪儿得到信息？ 哪些外部系统要和系统进行交互？ 定义解决方案系统的界限 不好！大部分工作都留给操作员了 常见划分，但可以更好 订单接收自动化 顾客缺货前提醒 上下文范围图示例 上下文范围图示例 确定加在解决方案上的约束 经济约束：预算？ 行政约束：存在许可问题？潜在内外部政问题？部门间问题？ 技术约束：技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包？ 系统约束：建立在现有系统上？需要维护与原系统的兼容性？必须支付什么操作系统？ 环境约束：合法吗？安全性要求？其他标准限制？ 进度及资源：进度要求？已有资源？外部劳动力可用否？有无扩展资源？ 确定加在解决方案上的约束 操作性：销售订单数据必须在数据库中备份一年，因为数据丢失风险太大，需并行运行至少一年的数据 系统及操作系统：应用在服务器上占用不超过200M，因为服务器上存储空间有限 设备预算：必须在已有服务器和主 机上开发 人员预算：固定的人力资源，没有外部资源 技术要求：应用新的面向对象的方法 项目定义—业务需求 产品/项目的目的：对业务目标的简短、可度量的描述 客户：为谁构建？ 顾客 ：谁会购买？ 风险承担者：哪些人在产品中拥有既得利益？ 用户：谁将操作它？他们的能力如何？ 限制条件：必须采用某设计方案？时间？经费？ 名称：该项目使用哪些术语？ 相关事实和假定：每个人都需要知道什么？ 工作的范围：什么是产品和项目的边界？ 估算的费用：需要花费多少工作量或资金 风险：面临的主要风险 项目定义—目标的六要素 目标：精确预报道路结冰时间并分派除冰卡车 业务优势：通过预报道路结冰情况来减少道路事故 度量：因结冰而发生的事故数年将低于冬季发生的事故总数的15% 合理性：消除因结冰而发生的事故而减少的损失，与构建该系统所花费的成本和工作量相比，是否有价值？ 可行性：及时地除冰能否减少事故的发生？会降到总数的15%以下吗？ 可达成性：该目标能达到吗？ 项目定义—风险承担人与用户 用户：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别 风险承担者：用户、客户、顾客、管理者、业务主题相关者、开发人员、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团队、技术专家、文化利益、相邻系统 （Stakeholder解析） 项目定义文档—前景文档 业务需求 背景：新产品的来由与背景 业务机遇 业务目标与成功标准 客户与市场需求 业务风险 解决方案的前景 前景说明(目标客户、需求与机会、竞争对手与优势) 主要特性 假设与依赖 项目定义文档—前景文档 范围与限制 第一个版本的范围 各后续版本的范围 限制与排除 业务背景 涉众简介 项目优先级 操作环境 前景文档模板 示例一 示例二 愿景陈述—ABC航空 ABC航空通过提高对旅行服务的深入，以及提供其竞争对手无法提供的创新服务，来维护自己的形象。具体手段包括： 通过创建一个公共网站，提高ABC航空的品牌知名度 通过让30%的客户在线订票，将市场份额提高15%，并降低订票的成本 通过提供出色的订票服务，向独立的旅行社开放ABC旅行系统，这样也就产生了一个新的收入流 …… 愿景陈述—自动铁道信号系统 项目的目的是通过如下方式降低与交通工具控制中心的维护和修改相关的成本： 将系统从老化的16位微型计算机移植到现代的32位计算上 使用高级