产品特性的分类规划，新增需求的分析维护，是软件产品研发的基础。两者之间的关系维护，也一直是困扰产品研发团队的老大难问题。
是否可以借助需求分析的利器--“需求实例化”方法，来构建“需求体系化”这项产品，解决产品研发的需求全生命周期管理问题？
step 0--建立愿景
确定这个“需求体系化”产品要达成的整体效果，它所存在的价值就是助力产品价值交付，为产品价值交付流程的相关干系人提供一种知识服务、工具服务、管理服务。
step 1--确定系统
“需求体系化”的外部表现是一个网络空间，向上提供一个产品的文档持续交付平台，向下依赖产品研发的DevOps工具链，这三者构成一个完整的系统，为各类用户提供他们需要的服务内容。
step 2--寻找用户
一个产品或者服务，必须以满足用户的需要而存在。所以，我们要找到“需求体系化”的产品用户，分析他们的特征，以及使用产品的频度，便于后续产品功能的优先级评估。
step 3--问询目的
优先寻找产品使用频度高，内容贡献量大的用户，开始用户目的探寻。
目的探寻不能仅仅停留在浅层，必须深入挖掘，找出用户背后的动机，才能有可能真正实现用户想要的产品。
在研发流程的诸多角色中，PO、SE、BA均为本系统的重度使用者，他们的目的需要优先分析探寻。
每个角色在产品交付中的位置，决定了他们看待问题的角度，对“需求体系化”产品的要求也都存在差异。印证了一句经典名言：
屁股决定脑袋
但是，我们可以找到两个共识：
①建立完整清晰的产品特性树
产品由一系列必选和可选的特性组成，每个特性包含一个或多个相互独立的组件/子特性。
特性与组件/子特性之间可以有两种关系：
①or关系：多个同类组件/子特性可以同时服务于父特性
②xor关系：多个同类组件/子特性只能有一个服务于父特性
②生成覆盖全程的需求全景图
需求交付全过程的相关角色，都可以通过全景图都得自己想要的关注点。
step 4--勾画场景
下面，我们可以依据前面3步的工作成果，确定典型的产品场景，构建一个“需求体系化”的MVP(最小化可行产品)。
我们商业模式画布的方法，分析“需求体系化”MVP的典型场景。
结合客户细分、价值主张、客户关系、渠道通路等关键要素，可以推导出其它关联要素，共同确定系统的运作模式。
下面列举了一个PO和SE交互的典型场景，使用故事板的形式呈现。
step 5--列举功能
根据上一步的典型场景，可以开始基本功能的梳理和分解。
以上步骤4和5，仅仅完成了MVP中一个典型场景和基本功能输出，在产品原型得到使用者的实际反馈后，需要重复迭代步骤4和5，输出完整结果，规划产品的交付计划。
接下来就要开始实际行动了，构建一幅产品特性的全景图。
--end--
