没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
《有效需求分析》精读笔记
书籍信息
书名:有效需求分析
作者:徐锋
公众号:刻意练习产品产品思维
整理人:猪哥
共读:关注本公众号,回复 有效需求分析 一起共读此书
作者金句
我们不是在画活动图,而是在做流程分析;不是在画类图,而是在厘清数据关系;
不是在画用例图,而是在识别场景……
左脑喜欢逻辑,右脑喜欢故事;最好的陈述一定是起于故事,终于逻辑。
要做好软件需求工作,业务驱动需求思想是核心。
价值需求是方向,是成功的标准。
哪里有分解,哪里就有接口
需求=预期-现状
我们才是解决方案专家,客户只是问题专家
大事化小,逐个击破
于很多系统涉及的问题域有多个,如果直接对整个系统进行功能、数据、非功能
主线的梳理,会很困难。如果存在这种困难,我们就【应该先从业务的角度,按
系统涉及的不同子问题域进行分解,以便逐一分析】。
1·需求
如何分析政府、企业的信息化系统需求?
针对这些组织应用类软件系统的需求分析工作,核心在于“业务分析”。而要想厘
清此类软件系统的需求,必须要抛开具体的技术实现,站在用户的视角审视用户
想要解决的问题、想要达成的业务目的。
个人感悟:一切围绕业务
什么是业务驱动的需求思想?
开发视角:
组织应用类软件系统就是带一定业务逻辑的增删、改查功能
做需求就是先搭菜单结构
传统的需求分析是站在技术视角展开的,关注的是“方案级需求”;而业务驱动的
需求思想则是站在用户视角展开的,关注的是“问题级需求”。
个人感悟:站在用户视角思考问题本质
方案非需求,需要还原问题本身
案例1:年仅3岁的小孩夜里醒来,吵着要吃饼干。本质:小孩实质是肚子饿了,
并非一定要吃饼干。
案例2:用户提出变更、优化型需求
如何还原需求本质?
澄清问题
了解背景
建议并确定解决方案
如何澄清一个问题?
确定问题:谁,遇到什么问题?
了解现状:针对该问题,当前采用了哪些临时解决方案?
明确需求:把一些很模糊的概念和规则沟通清楚。
了解背景:此问题发生的前因后果
如何了解需求背景?
谁,什么时候,做了什么?
明确业务术语的定义
了解业务环境:不做谁生气,多久生气一次
如何提出合理的解决方案?
列出所有可行性解决方案
分析各方案优缺点、利弊关系
与业务人员协商敲定
有其他需要挖掘的需求吗?
需求变更、优化分析模板?
原始需求:编号、提出人、哪个部门
问题澄清:到底要解决什么问题?现在如何应对该问题?问题描述中有需要澄清
的定义吗?还有其他相关的需求吗?
目标用户:不做谁生气?多久生气一次?
业务场景:何时何地什么情况下发生
业务术语:列出容易引起歧义的业务名词
解决方案:针对该问题可以有哪几种解决方案,各有什么优缺点,推荐哪种?为
什么?
宏观角度,B端系统需求可以分为
价值需求(目标场景、干系人关注点、干系人阻力点)
详细需求(功能需求、数据需求、非功能需求)
什么是价值需求?
整个软件系统为客户解决了什么问题、创造了什么机会?
最关键的干系人有哪些?
各个重要干系人对系统的关注点是什么?有哪些担心?
很多系统设计存在以下问题
目标假大空,放之四海而皆准
忽略相关业务干系人,在《需求规格说明书》中根本找不到
价值需求分析的关键是?
执行好目标分析:多份《问题卡片》,场景化地定义项目目标
干系人识别:一张《干系人列表》,列出所有关键干系人
干系人分析:多份《干系人档案》,针对每个关键干系人整理相应的关注点和阻
力点
什么是详细需求?
功能需求:为了给客户提供业务、管理、维护支持,需要提供哪些功能?
数据需求:系统所涉及的问题域中有哪些数据,之间是何关系?
非功能需求:所处的业务环境会带来哪些约束和质量要求?
系统中的所有功能是因何而存在?
功能主线的梳理可以从业务支持、管理支持、维护支持三个角度展开。
业务支持:
(1)通过系统固化、优化业务流程,提升流程执行效率、节约成本、降低
风险等。
(2)通过系统拓展业务的渠道,使其延伸到电话、互联网、移动互联网等
通道上。
(3)通过系统将个人知识、能力转化为组织知识、能力。
管理支持:
(4)通过系统实现数据的信息化,辅助管理、决策。
维护支持:
(5)帮助系统不断演变和优化
什么是业务支持型功能?
固化、优化业务流程
业务延伸到新的通道(诸如手机端)
将个人能力转化为组织能力,而这种能力存在于具体的业务场景中,因此“专家
场景”是核心。
如何梳理业务支持型需求?
业务流程识别:根据目标和干系人关注点,系统涉及哪些业务流程?
业务流程分析:这些业务流程是如何定义的,需要优化吗?
业务功能识别:系统对流程中所有业务场景都要支持吗?还是只支持一部分?
业务功能分析:有哪些业务场景的工作经验需要模型化?
什么是管理支持型功能?
事前风险避免,通过增加管理流程;
事中风险控制,通过“规则”和“审批”;
事后总结优化,通过“数据分析”。
如何梳理管理支持型需求?
识别管控点:管理层用户希望通过系统来实现哪些管理、控制需求?
期望:希望通过系统做哪些辅助决策?
分析:要实现这些管理、控制、决策支持,需要哪些信息?用什么方法获得它
们?
什么维护支持型需求?
“有谁会需要对系统进行维护?”
“他们需要执行哪些维护任务?”
如何梳理维护支持型需求?
有谁会需要对系统进行维护?
他们需要执行哪些维护任务?
列举不同的维护场景
逐个排错,可总结归纳,应用于多个同类系统
核心四流?
工作流、信息流、资金流、物流。在一个组织应用类软件系统中,资金流和物流
是不会真实出现的,而是以信息流的形式呈现。
数据主线的需求分析怎么做?
数据主线重点就在于厘清组织中的“信息流”
数据-“系统相关的问题域中有哪些业务数据?”
关系-“它们之间是什么样的关系?”
构成-“每个业务数据的具体构成是怎么样的?”
数据主线的关键任务有两个
领域建模:用类图描述业务数据实体之间的关系
业务数据分析:详细定义数据构成与推演过程
什么是非功能主线的需求分析?
“系统相关的外部环境会带来什么样的约束和质量要求”
非功能主线的需求分析的误区有哪些?
定性描述,目标大而空。比如“高可靠、高易用、高灵活……”之类
盲目定量,拍脑袋写出量化指标
以偏概全的全局性描述。诸如“所有查询都在7秒内响应”之类
如何做好非功能主线的需求分析?
对于非功能需求的分析工作,最核心的是逆向思维,从威胁入手。
识别出业务环境中可能产生的破坏力大、出现概率高的威胁场景
总结:需求分析包含哪些内容?
通过价值需求、详细需求(包括功能、数据、非功能三条主线)的梳理,识别并
描述业务功能、业务报表、业务数据、质量场景、业务接口五类最小需求单元。
还有两方面内容,一是约束,二是规则,有时需要单独进行更加详细的分析。当
系统中有大量的约束时,需要强化约束分析。当系统是一个强规则,规则量大、
规则很复杂时,就可以考虑单独作为一个主题来分析,否则可以在流程分析、业
务功能分析、领域建模时附带对规则进行分析即可。
18项需求分析关键任务汇总
什么是需求?
需求=预期-现状。
需求,实际上就是用户的预期和现状之间的差距。
如果没有差距,也就不会出现需求。
需求的三种状态?
(1)预期高于现状:也就是用户不满于现状,希望自己的业务、管理能够开展
得更好,甚至有明确的改进预期。这种情况下,用户通常会比较积极地配合需求
调研,只要调研方法得当,就能够很好地识别出目标。
(2)预期等于现状:我们也经常接触到一些用户觉得现状已经不错,基本能够
符合自己的预期。这种情况下,他们通常对变化表现不积极,基本上很难用直接
的调研方法来获取需求。
(3)预期低于现状:有时部分用户甚至觉得现状已经很好,常说“想当年我们多
么混乱,现在这么好”。这种情况下,他们甚至会抗拒变化,对需求的调研表现
出消极的态度。
当遇到后两种情况时,就需要我们通过对现状的深入了解,提出用户可能为之心
动的“新预期”,从而让他进入“预期高于现状”的状态
如何分析问题?
访谈问题:项目来源,项目背景
研讨机会:新业务、新技术、新场景
定义问题/机会:描述问题、机会,以及它影响谁、产生什么结果。
分析问题并确定解决方案:深入分析问题,然后确定策略级的解决方案。
目标分析主要针对的是?
剩余24页未读,继续阅读
资源评论
小麦进城
- 粉丝: 11
- 资源: 9
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功