需求定义最佳实践资料.ppt

讨论 你认为需求定义的目标是什么？ 通常需求定义在什么阶段进行？ 其主要的产物是什么？ 信息系统立项前的分析方法 GPOA方法：Goal?Problem?Option?Answer 信息系统立项前的分析方法 G（目标）：要确定需要开发某个信息系统之前，应该分析其应该达到的目标：业务性、可度量 P（问题）：要达到该目标所需解决的问题！ O（选项）：针对这些问题可选的解决方案 A（答案）：针对各种Option进行分析、评估，最终确定答案。 信息系统立项可行性分析 确定目标：信息系统实现前，信息系统实现后 提出解决方案：分析P，给出O，得出A 可行性分析： 效益分析：经济可行性，投资回报 社会可行性 技术可行性 信息系统立项时的常见误区 目标：含混不清，过为宏观 Solution: 基于业务需求思考 解决方案：思路过于受限 Solutions: 只想What，别想How 了解、理解IT技术 期望值：脱离现实 发起人、用户、使用者想法不一致 框定问题的技巧 问题的定义是需求工作的第一步，也是最重要的一步。 问题是否能够解决，通常与是否能够更好、更准确地框定问题相关。 例如，经典的马的遍历问题：寻找一系列的移动步骤，使马走完每个方块，而落入任何一个方块一次： 框定问题的技巧 框定问题的技巧 软件需求第一和可能最重要的步骤是框定问题—把问题的特定部分，以及部分间特定的关系，放入一个特定的形式中。问题框定方法应使问题的细节适合一个简单连贯的框架 同时，这也表现出，深入地理解问题域的知识，正确地抓住其本质特性，是十分重要的。 （你的灯还亮着吗？） 框定问题的技巧 问题：日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。 解决方案一：“警告！前有隧道请打开车头灯” 新问题：隧道出口风景很美，返回时发现汽车没电—忘了关车头灯！！ 解决方案二：出口处立标牌“关掉车灯” 新问题：夜行车也会关掉车灯？ 解决方案三：建充电站 新问题：维护开支大，充电站也会出故障 框定问题的技巧 解决方案四：授权私人经营充电站 新问题：风景区商业化，政府与游客均不接受 解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请熄灭车灯； 如果天色已晚，并且车灯没开，请打开车灯； 如果是白天，并且车灯没打，就别打开它； 如果天色已晚，并且车灯开着，请别关掉它。 新问题：谁能在行驶时读完？！ 终极解决方案：你的灯亮着吗？ 问题分析的五个步骤 问题分析：理解真实世界中的问题和用户的需求并提出满足这些多方面要的解决方案的过程 ①在问题定义上达成共识 ②理解根本原因—问题背后的问题 ③确定风险承担人和用户 ④定义解决方案系统的界限 ⑤确定加在解决方案上的约束 在问题定义上达成共识 把问题写下来，看每个人是否都同意 采用标准化格式： 问题：描述问题 影响：确定受问题影响的风险承担人 结果：确定问题对风险承担人和商业活动的影响 优点：指出解决方案并列出主要优点 理解原因后对问题的陈述 问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降低 成功的解决方法： 增加了输入点订单的准确性 增加了销售数据的报告以便进行管理 获得更好的效率 理解原因后对问题的陈述 问题：随时提供大学体育赛事的最新报道 影响：移动办公的人群 结果：他们不可能花很多时间来搜索他们感兴趣的新闻，因此无法随时了解到有关他们母校的赛事（或者他们感兴趣的其他大学的体育赛事）。 成功的解决方法：当发生他们感兴趣的新闻时，向他们发出通知，并提供一个地点来为他们提供所请求的新闻。 理解根本原因—问题背后的问题 TQM的鱼骨图 帕雷托图 确定涉众和用户 系统的用户是谁？ 系统的客户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没有必要被考虑到？ 系统将来由谁维护？ 还有其他人吗？ 用洋葱图来寻找涉众 定义解决方案系统的界限 谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？ 谁将操作该系统？ 谁是系统的维护者？ 系统将会在哪儿被使用？ 系统从哪儿得到信息？ 哪些外部系统要和系统进行交互？ 定义解决方案系统的界限 不好！大部分工作都留给操作员了 常见划分，但可以更好 订单接收自动化 顾客缺货前提醒 上下文范围图示例 上下文范围图示例 确定加在解决方案上的约束 经济约束：预算？