收集需求
需求池
（1）该需求发生的业务场景是什么，这些业务活动是为了实现什么目的。
（2）在这些业务场景中用户遇到了哪些困难，当前是怎么解决的，期望通过该需求怎么解决这些困难。
（3）该需求还与哪些周边系统或哪些模块相关，它们的运行逻辑是什么样的。
（4）该需求可能还有哪些用户会用到，会对他们有哪些影响，他们的期望会有哪些。
（5）业务模式是否已经成熟稳定，预计未来何时可能会发生调整。
需要的功能是什么（What）
为什么要有这样的功能（Why）
功能的用户是谁（Who）
用户在什么时候使用（When）
在哪个模块使用（Where）
怎么使用（How）
频次或数据量怎么样（How Much）
需求的价值就是需求能带来什么收益。比如做了该需求能节约多少劳动力、挽回多少损失、增加多大社会效益等。不做有多大损失，是否影响业务的连续性，是否造成巨大损失等。
如果一个需求做和不做没多大区别，那么就说明该需求并无实质价值，建议把该需求过滤掉。
需求的合理性包括需求的定位是否合理、需求的实现是否合理两个方面。
确定需求的定位是否合理：比如该需求在本系统中实现是否恰当，权限开放出来是否合适，是否泄漏了公司的机密等。有的时候，用户并不区分某需求是不是应该在这个系统中实现，所以他们提出的需求有可能与本系统无关，这时候就要求产品经理能分析出合理的功能归属。
确定需求的实现是否合理：比如技术的投入产出比是否合适，使用第三方的应用的成本是否更低，当前公司的人才储备是否足以支撑该需求的实现等。实现起来不合理的需求，就应当过滤掉。
使用需求得分权重法，排出各个需求的整体得分名次，作为需求的优先级。优先级低的需求可以考虑过滤掉
确定大致方案
参与者、用例、系统边界以及它们之间的关系构成
系统是做什么的
描述用户处理业务的流程
从业务角度进行绘制
描述系统功能运行的流程
更接近需求方案
核心作用：描述与操作相关的动作，每个方框都是一个具体的事件，不能把状态放到方框中
针对状态的变化，如审核流程
需求点的汇总图
所有功能点罗列出来
原型图
整体角度考虑和规划
具体方案
背景
目标
功能说明
当前的业务流程怎么了
当前的功能是怎么样的
问题是什么
需要怎么办
需要达到什么目标
从效果角度表达需求的预期
用例图
名称定义
概念框架
业务流程图
功能流程图
功能说明
逻辑规则
参考资料
利益相关者
从投资者角度看问题
用户角色分析
重视解决的问题，而不是解决方案
把类似的接收到的需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题
在考虑需求时，不应该只是孤立地考虑功能逻辑，而应该把这些功能和流程放到具体的用户使用上下文里面去
充分地把自己带入，把每个细节都摸到。闭上眼一步步地演进，考虑具体利益相关人的情绪、关注点、好恶，以及所处的环境，所用的终端等等
成为自己产品的重度用户
流程上的、逻辑上的，也包括交互和体验上
抽象考虑同样的问题还有哪些不同的方案
用户故事
产品所涉及的领域中，有哪几种用户，他们之间的关系是什么
颗粒度、边界、优先级
基本信息
特定信息
例子表述真实性
做某事的准备
做某事的过程
做完某事之后
用户的观点和需求
目标用户是谁
需求表现为什么
何时何地，什么情况下
用户需求被的目标和动机
用户言行的原因
解决方案
做哪一个功能，对截止的判断和优先级判断
一次做多少个功能
愿意花多大成本
人性与价值观
需求的本质
0
0
分享
