掌握需求过程阅读总结.pptVIP

功能性需求 从业务角度来看，产品必须做的事情 也可理解成从顾客角度看，产品应该完成的事情 而不是从产品实现角度来看的功能点 功能性需求与技术没有任何关系 谢谢观赏 掌握需求过程阅读总结 提 纲 需求定义 业务工作与需求调研 确定和理解业务工作 场景和功能性需求 提 纲 需求定义 业务工作与需求调研 确定和理解业务工作 场景和功能性需求 需求定义 需求是产品必须完成的事以及必须具备的品质！ 因此： 1 需求是与技术无关的,需求不因实现技术发生变化而变化 2 需求纯粹是对业务方面的说明，没有任何实现方面的偏好。 3 根据所指系统范围，需求是分层次的。 4 需求分析目标是明确产品必须完成的事(功能性需求)和必须具备的品质(非功能需求)。 提 纲 需求定义 业务工作与需求调研 确定和理解业务工作 场景和功能性需求 我们以前需求调研方式 一般这样问用户 “你希望我们的系统提供什么样的功能？” “我们系统存在哪些不足， 希望怎么改进？” 我们希望 用户告诉我们越详细越好，最好可以给我们画出所有的操作界面和操作过程，方便我们直接开始coding! 这是一种最直接和最想当然的方法，但是是错误方法! 调研前假想存在一个已经实现自动化系统 调研的焦点集中在将要实现的自动化系统底层次的、操作细节上。 幕后的想法 财务系统 电话，打印机 会计\出纳 财务部门 公司 其他部门 将要实现自动化系统只是整个业务系统的一个部分 自动化系统的功能只是整个业务处理过程中的一个环节 自动化系统只是业务系统一个环节 为什么要了解业务工作 做任何事情之前必须明白需要解决问题。问题不清楚，方向就不对，就做不对事情。 同样道理，设计自动化系统之前，必须明白客户投资该自动化系统的目标，既希望花钱投资自动化系统想解决的问题。 由于自动化系统只是整个业务系统中的一个环节，因此要搞清楚客户投资自动化系统想要解决的问题，必须先了解业务系统所以需要解决的问题，既要了解业务工作。 只有理解了业务工作,才能确定怎样的产品对业务工作最有帮助. 业务工作 业务工作是客户/顾客的业务活动(注意: 不是用户!) 我们打算构建的自动化产品是一个有帮于工作的工具 业务工作是开展业务的整个系统 顾客/客户/用户/系统参与者 客户: 为产品开发付费 顾客: 产品开发完成后购买该产品 用户: 最终操作产品的人,强调直接接触!(系统参与者) 用户通常有两种: 一是客户或者顾客雇佣的操作人员(银行柜台人员) 二是享受工作服务的人(银行储户操作ATM) 第一类人在业务工作范围之内。 第二类人在业务工作范围只外,用户即顾客。 提 纲 需求定义 业务工作与需求调研 确定和理解业务工作 场景和功能性需求 确定业务工作范围 设定范围将要研究工作与围绕它的工作区分开 通过定义进入和离开工作的信息流来定义工作的范围。 业务工作范围不只是软件产品的上下文范围。如果业务工作中不包含任何的人，那么很有可能工作上下问范围太窄了。 如果只研究想象中的产品包含哪些内容，就构建不出最有用的产品 需求分析第一步最关键是能正确确定工作 范围和上下文！ 确定业务工作范围 工作范围划多大: 所有允许改变的东西都在工作范围之内 所有受产品影响的东西都在工作范围之内 工作范围必须包括:预期的参与者和他要做的工作. 不要一开始就把工作想象成: 操作员+自动化系统,而是看成一个整体老考虑业务工作. 需求分析重点不要聚焦在自动化的产品身上,而是要理解业务工作 从越远地方来看预期的自动化系统,就越可能发现产品的有用和创新之处 业务事件和业务用例 工作要么为相邻系统提供服务,要么相邻系统为工作提供信息 工作在提供服务时就是在响应业务事件 业务事件: 在讨论顾客的业务工作时,发生的事件 工作对每个业务事件的响应就是业务用例 时间触发的业务事件 注意: 业务事件一定是在发生在工作范围之外,通过信息流,工作得知业务事件已经发生. 业务事件的触发职责是在工作控制的范围之外 相邻系统 主动相邻系统： 行为是动态的、他们与工作交互或者参与工作. 主动相邻系统一般是人. 主动相邻系统发起业务事件时,头脑中总有一些目的. 必须理解主动的相邻系统的愿望和动机! 例如：业务审计系统,用户查询操作信息时,必须要搞清楚查询的动机和真正的目