产品需求分层管理案例

admin

当前困扰很多研发团队的问题是产品需求多变，并且对哪些是产品需求，哪些是线索，比较模糊，导致产品需求管理比较混乱。

那产品需求要如何进行描述呢？目前并没有统一的标准。比如，有的公司曾经认为产品需求就是问题加解决方案，这有一定的道理，但是还是有些粗糙。

下面分享一个产品需求分层管理的案例，希望能给有需要者带来帮助。

在这个模型中，把需求分为面向分析、商务、实现三个模块，这三个模块是逐步递进的关系。在面向分析的模块中，包括原始需求和初始需求，“原始需求”是指客户反馈或者直接从客户那里收集到的信息，信息的详细程度和颗粒度的大小也是很不相同的。

“初始需求”则是经过内部的需求分析团队进行分析以后，按照内部规范整理出的比较清晰，分类明确，颗粒度相对统一的需求，原始需求和初始需求可能是多对多的关系。

再来看面向商务的需求，它包括客户问题和系统特性。客户问题并不是指鸡毛蒜皮的小问题，而是客户深层次的问题。比如手机从键盘键向智能机的演化，苹果抓住的深层次的问题是消费者如何实现更便捷的沟通，而不是如何让键盘更好用，从而发明了智能机，掀起了一场革命。

系统特性，则是指产品的亮点，或者是以用户的视角描述的产品的功能。对于新产品，新增的特性往往就是产品的卖点。比如，对于一款手机，产品最薄，上网速度最快，抗摔、防水等等都是产品的特性。

这里需要特别注意的是，客户问题和系统特性都是基于对市场和产品的了解而分析总结出来的。

下面来看看面向实现层面的需求描述。系统需求是指为了支撑系统特性，必须实现的产品功能，是站在产品和研发的角度来描述的产品要实现的功能规格。比如手机要做到最薄，那对结构、内部的电池、内部的PCB板都有具体的要求，这些具体的要求就是支撑“薄”这个特性的。

对于某个具体的系统需求，可能会由不同的研发小组来实现，比如有的由硬件实现，有的由软件实现，有的由结构实现。这些分配到具体的开发小组去实现的需求就称为分配需求。

通过如上模型，就实现了由客户原始需求到分配需求的全链条的监控和管理过程，为产品需求的科学管理提供了指导。

fuhe

一、老的产品包需求架构
OR：Offering Requirement，产品包需求
DR：Design Requirement，设计需求
DS: Design Specification，设计规格

二、新的产品包需求架构
RR：Raw Requirement，原始需求
来自公司内、外部客户的、关于公司产品与解决方案的、需要需求管理/分析团队（RMT/RAT）分析评审后作出决定的所有需求。

IR：Initial Requirement，初始需求

原始需求经过RMT/RAT分析后，站在内外部客户/市场角度，以准确的语言（完整的背景、标准的格式）重新描述的需求。
之所以称为初始需求，是因为后续此需求还会经过第2轮分析，归纳到“系统特性”或者“系统需求”等标准需求架构层面。
初始需求便于RAT将分析后的原始需求进行重新描述后，分发到路标规划版本上，再由CDT进行进一步加工与取舍。
初始需求还是特性提炼的资源池，部分重要的初始需求可以提炼为产品卖点，则由CDT归纳为特性。
CDT在charter的需求交付件包括：IR、PB、SF三类，并要求整理为树形结构。
初始需求IR除通过RR转换得到外，还可能通过解决方案需求分解到网元、公司DFX需求重用到产品、Marketing市场调研热点需求包重用等途径产生。
PB：Problem，客户问题
描述客户面对的挑战与机会（客户战略与痛点），也就是该版本为客户带来的核心价值。

SF：System Feature，系统特性
描述该版本为支撑“客户问题（PB）”所具备的重大能力。系统特性是产品包的主要卖点（销售亮点）集合，每条特性都是满足客户特定商业价值诉求的端到端解决方案，一部分特性是可以通过license控制单独销售的。

SR：System Requirement，系统需求
描述为支撑“系统特性SF”所需要支持的具体需求，定义：系统需求（SR）是系统对外呈现的、可测试的全部功能需求和非功能需求，其中功能需求是对系统提供的功能的场景化的具体要求，非功能需求是对系统的成本、全局质量属性、技术限制等非功能性方面的具体要求。

AR：Allocated Requirement，分配需求
根据“系统需求SR” 分配到子系统/模块的功能或非功能需求。

CR：Process Change Requirement，流程变更需求
业务发生变化或者已有流程存在缺陷，导致不能满足而对扣成变更的需求。

三、新老需求架构对比
简单理解的话，可以理解成OR=IR、DR=SR、DS=AR。