用户需求分析模型,软件需求分析模板( 二 )


解释,是 “为什么”,是对于描述的理解、归类、定义和解释 。其目标是将描述内容背后的成因、原理、动机,内容中各部分之间的相关,依存、依赖和影响关系等进行说明,以便对于描述内容有更清晰、更细致、全面的了解 。
预测,根据以因果关系为内容的内在联系,相互影响来推导未来的发展或者将要发生的事情 。通过研究解释内在的联系,准确地表达内在联系,从中推导出正确的预测 。
监控,是对于预测行为、现象的观察和监督,包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生,以及因此而采取的对应的反映动作;这些反映动作是预测过程中根据内在联系制定的“响应”机制,并任其自然发生或者通过提供“系统”的自制能力来实现 。


二、需求准备、编写和检查
回归到产品经理的日常工作中,在时间占比上较为集中的就是产品需求管理了,包括了需求的准备、分析、编写和检查过程 。在这个过程中,描述——解释——预测——监控这个通用的科学分析过程也同样使用,且可以贯穿其中,并可以帮助理解、形成并固化成我们前文提到的需求文档的模板 。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同 。


1. 描述
描述的过程是客观的进行“需求向”描述的过程,是一个“背景”信息的补充,用来说明,这个需求文档的源出是什么,是针对什么问题,这个问题是在具体什么领域,在怎样的范围内,涉及到的是那些人;在需求相应的功能设计实现之前,当前的解决方案存在的问题是什么,参与者是怎么解决的,解决的情况怎么样,是好,还是不好,还是勉强可以,对于新的需求的紧迫性是什么样的 。此外,描述的过程还需提供一个基础的概念和流程的解释,用来统一作为背景去理解一个现实的业务场景和“沟通字典”,避免在沟通中因为误解而产生不必要的偏差 。


需求准备的过程:了解需求来源,需求背景;
需求分析的过程:了解需求目标、预期效果、使用者习惯、相关人影响;
需求编写的过程:描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围;
需求检查的过程:需求的背景、目标、过程、干系人、结果预测和预防的完整性检查;


2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题,同时还加入了“是什么”和“怎么样”的部分 。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题,这个新的解决方法需要要做什么,对于原有的业务过程有哪些改变,会提升什么,会降低什么,会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生 。这个部分,是需求文档的最主要、最核心的内容部分,也是在内容上占比最大的一部分 。


这里的解释根据产品需求面向的要解决的问题不同,而可能存在多个层面,多个维度的层面,比如对于运营的影响,对于前端市场的影响,对于用户的影响,对于财务、法务的影响;从技术开发、技术实现维度,比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响,还可能涉及到对于运维资源的影响等;因此对应到实际的产品需求工作中:


需求准备的过程:了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑;了解面向的内外部用户的产品使用水平、学习能力和使用习惯;
需求分析的过程:选择和制定最有效的,满足时间、资源投入等要求的方案;
需求编写的过程:详细描述需求的业务流程,通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品,产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出;每个业务节点明确的输出物和节点标志,重要性和优先级;系统架构、干系人角色和影响范围;
需求检查的过程:需求的流程、用户交互动作、系统信息交互等完整性检查;


3. 预测与监控
预测与监控在产品需求文档的管理上是联动的,是对于预测的事件发生的时候,进行管理的机制,监控=预测+干预 。在产品需求文档的管理上,对于设计好的业务流程、使用功能,在实际过程中可能会出现这样或者那样的 “非规划”的使用,也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品,而且,往往相反 。”因此,这部分内容很大的比例需要来对于用户的行为进行预测和监控,并提供“预防”或者“解决”方案 。其中:

推荐阅读