点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

1. 案例成果

1.1. 问题背景

2015年底，*GW产品提出了需求体系化的概念，其本质是将产品的需求、特性、功能建立有机体系，使其对外可以呈现产品能力、对内可以指导产品设计。之前，*GW产品的需求体系化是基于对外交付的用户文档来建设的，通过需求体系化的理念和方法建立用户文档的体系化。

*GW产品实践需求体系化之后，除了实现了产品需求体系化的目标之外，用户文档质量也有了明显的提升。但是，需求内部研发流程相关的设计类文档仍然维持之前的方式，word、excel编写、无体系碎片化、svn保存，相互之间没有关系。很多时候，由于文档查找难、浏览难、无关联、无体系，导致内部设计文档变成一次性的。同时，内部研发的需求设计文档与交付的用户文档间也缺乏关联。

1.2. 改进结果

针对上述问题，*GW产品利用wiki空间，借助需求体系化思想，设计了用于组织管理需求研发流程的体系化空间（如图1），将需求研发的内部设计类文档纳入体系化，并且与外部交付文档建立关联。

图1 *GW需求体系化空间

该空间汇聚了*GW产品需求研发阶段所有内外部需求特性文档及特性相关资源，以特性节点为单位贯穿了端到端的价值交付全流程。该空间向研发人员提供了路标式需求开发指引，一方面规范了研发需求开发流程，另一方面也简化了研发过程。此外，该空间的设计还考虑了研发流程中不同角色的需要，为诸如市场规划、项目管理、研发设计、文档开发等角色分别设计了不同的空间视角。

2. 实践情况

2.1. 背景知识简介

需求体系化是对产品所提供的需求及需求之间的关联关系进行系统的分析及有序的管理的过程。需求通过文档作为载体呈现，将承载产品需求描述的文档进行有序组织的过程即是文档体系化。

外部文档是随产品版本一起交付用户的关于本产品的综合性说明文档，包括产品功能特性描述、产品参考类手册、产品安装调试、产品操作维护等多部分内容。*GW产品于2015年底提出需求体系化的概念后，就致力于使用需求体系化的

理念与方法组织外部文档的体系化，经过近2年的努力，*GW产品的外部文档获得了显著的提升。

内部文档是指导研发开发流程的方案设计类文档，主要包括原始需求说明、需求分析说明、系统方案、测试方案、测试用例等多种类型文档。*GW产品于今年6月开始启动基于需求体系化的内部文档体系化工作，通过需求体系化理念和方法将内部文档建立体系并与外部文档建立关联，同时通过对设计文档建立体系来组织规范需求研发流程。

图2 需求体系化与内外部文档

2.2. 方案描述

相对外部文档，内部文档与研发流程的关系要更密切，同时内部文档不需要遵循外部文档的严格的交付标准。因此，*GW产品选择利用wiki空间来组织内部过程文档的体系化，同时具有编写简便、协作性好、易于维护等优点。

2.2.1. 用户分析

体系化空间的预期使用人员包括：研发人员、市场规划、项目管理、文档交付等多种角色。其中：

• 研发人员包括BA、DEV、QA、后端测试专家四种角色，BA主要使用空间来设计需求分析、编写系统方案；DEV主要通过空间中的设计方案来指导开发；QA主要使用空间编写测试方案，关联测试用例；后端测试专家主要使用空间在特性交付时检查关于特性的所有设计、文档工作都满足DoD要求。

• 市场规划提出原始需求后，可以通过体系化空间跟踪、确认：原始需求进入了预期的产品版本，研发正在设计、开发的特性符合原始需求。

• 项目管理主要包括产品负责人、项目跟踪者等角色，他们需要通过体系化空间跟踪某版本包括哪些需求特性、哪些需求特性已经开始设计开发、进展如何，以及查阅某个特性所关联的所有资源。

• 文档交付角色主要是文档部同事，负责产品的对外文档交付工作。他们需要通过体系化空间了解当前版本有哪些特性需要交付用户文档，这些特性的对外商用Feature List编号是什么等信息。

2.2.2. 空间设计

根据空间设计的目的、用户角色及其使用目的，空间设计包括以下几个重要部分：

1）特性节点

这是体系化空间中的一个重要概念，特性节点是一个逻辑概念。它是某个需求在空间中建立的一个节点页面，在这个节点上汇聚了这个产品需求的所有相关文档资源；同时，特性节点上也附加一些特性信息，为体系化构建提供依据。

图3 特性节点

2）文档库

文档库主要为研发使用，研发过程所有设计类文档都在文档库中编写与存放，所有设计类文档在文档库中都以特性节点为单位聚合。文档库主要为研发设计工作提供两种功能：

• 路标指引，从体系化首页开始就提供文档库的快捷导航，跟着导航每一步设计工作要做什么都有详细说明指引；

• 规范模板，每一种设计文档都提供模板，而且模板的生成使用一键按钮嵌入到路标指引中，方便研发按步骤方便的使用。

图4 文档库

3）市场视图

市场视图可以分版本汇聚特性，并同时呈现特性对应的原始需求编号与市场Feature List编号信息。市场视图主要提供给市场规划与文档交付两种角色使用，他们可以从市场视图中获知：

• 市场提出的原始需求规划进产品哪个版本中交付，当前进展如何；

• 某个版本有哪些特性的用户文档需要交付，这些文档的市场Feature List编号是什么。

图5 市场视图

4）管理视图

管理视图主要是分版本汇聚、呈现需求开发过程某特性的所有阶段性输出结果，便于项目管理者及时了解某版本中规划的特性及特性开发进度。

图6 管理视图

除以上列出的几种视图外，空间还提供了综合解决方案视图与文档类型视图。综合解决方案视图是针对热门的市场综合解决方案（如NBIoT、VoLTE等），将产品中的特性组织在一起呈现的视图；文档类型视图根据各类文档模板自动生成时附带的类型标签将文档分类呈现的视图，如需求类文档、系统方案类文档等。

2.2.3. 内外部文档关联

研发过程中内外部文档的关联关系主要通过空间中的特性节点建立，建立关联的过程主要如下：

图7 用户文档开发流程

1) 在需求分析阶段，BA判断该特性是否需要输出用户文档，如果需要则确定该特性的FeatureList ID，并将FeatureList ID填入体系化空间中特性节点中；

2) 迭代开始前，文档部同事会扫描一遍体系化空间中的市场视图，将带有FeatureList ID的特性（需要输出用户文档的特性）在用户文档包的体系树（e读上的体系树）上建立节点与用户文档模板。

3) 迭代过程中开发人员一方面在特性节点下进行需求分析、方案设计；另一方面在e读的体系树上根据文档部同事建立的节点完成用户文档编写，并将完成的用户文档链接填入体系化空间中的特性节点中。

根据上述步骤，一个需求开发完成后，通过体系化空间中的特性节点将该特性的内外部文档建立了关联。在需求研发过程中，通过体系化空间中的特性节点完成了研发与文档部的协作。

2.3. 系统介绍

本节主要从空间部署、使用方法两个方面介绍*GW需求体系化空间的建设。

2.3.1. 空间部署

*GW需求体系化空间是部署在公司的wiki空间内的，部署时主要包括以下三个部分：

1）空间构架部署

主要包括首页导航、文档库设计、各种视图的设计。

• 首先设计自己的空间应该包括哪些视图，如*GW的开发、市场、管理，在wiki空间内建好空间结构，然后在首页建一个导航链接即可；

图8 空间结构

• 文档库是研发进行需求分析、方案设计等工作的地方，*GW体系化空间设计时充分考虑如何减轻研发设计负担，文档库中的文档不要求组织结构，所有特性以特性节点为单位在文档库中平铺。其他视图中的结构根据特性节点中的标签信息自动生成。

• 视图的设计根据产品中各角色的需要分别设计，视图主要是根据某种标签（如版本标签）将特性节点或特性文档有组织的聚合，并过滤出需要的信息。视图中信息生成主要使用的是wiki中“页面属性报告”的插件完成。

图9 管理视图中“页面属性报告”设置

2）流程路标设计

流程路标设计一方面是为了方便研发跟着路标一步一步比较容易的就完成设计工作；另一方面是为了使研发在这种方便的指导中自动就采用一种规范统一的设计流程。

图10 流程路标设计

3）文档模板设计

空间中生成各类设计文档都有规范的模板，并且研发对于模板的使用是不感知的，使用一键生成的方式。这样做的好处有：

• 研发在一键生成文档时就自动使用了模板，使所有设计文档都可以统一规范；

• 模板内容设计全面规范，促使研发在做设计工作时，综合考虑，不会有遗漏点；

• 文档模板中会预先附带空间需要的附加信息，自动带进文档中，省去研发填写。

图11 一键生成文档模板

2.3.2. 使用方法

空间针对多种角色设计，提供不同的视图。空间的使用对于市场规划、文档交付与项目管理来说比较简单。本小节主要介绍研发如何使用空间进行需求设计，以下使用实例化的方法模拟研发进行需求设计的过程来说明。

1）打开空间主页，点击开发视角；

图12 空间首页

2）进入文档库，创建特性节点

图13 文档库

3）生成特性节点

图14 特性节点

4）根据提示的固定动作填写特性节点的信息，完成后打勾

图15 设计固定动作

5）使用一键生成相应设计文档，如需求分析文档

图16 一键生成需求分析文档

6）根据模板进行需求分析，编写需求分析文档

图17 需求分析文档模板