关于需求条目化，我所能想到的

文章来自：http://www.agilep365.com

首先来说，这个概念并不难，我们过去是采用需求规格说明书的形式来编写的，所以也会产生一个非常大的文档，里面包含了种种我们所需要的项目基本的需求，当然其中也会包含的功能性的和非功能性的一些需求，也有一些项目的例外情况所能考虑到的。

那么为什么需要去悄悄谋划呢？很多的一部分原因是因为我们的一顿一份大的需求在项目进行过程中可能会被无数次的更改，并且底下的工作人员，我在开发的时候在后期发现这些需求和开发的进度是很难被完全的追踪起来的疾病，按照项目管理的做法，我们也会有需求跟踪矩阵，但是这么一份需求跟踪矩阵如何去有效地跟踪到那么大的一份需求规格说明书呢？

由此，我们需要需求条目化来17更清晰易懂。而在敏捷的时候，我们说可以采用那用户故事地图的一个方式是最早的大型的一个需求能够被有效的有层次的进行拆解，其实每一次的裁决都是对其进行的一次细化，而最终我们把这些需求每一条需求细化成一到两句非常简单的语句来表达这个需求所包含的一个真正的内容。

这样做的话，这些需求其实就会变成碎片化，这很好地顺应了我们现在的碎片化信息的时代，但是由此也会产生一些问题，就是这么多碎片化的一些需求如何才能有效的去跟踪，有效跟踪他们的进度呢？

我们，我们还是可以利用项目管理的需求，跟踪矩阵来进行跟踪。一个简单的方法就是在用户故事地图做完以后，我们就可以妥善地去建立这么一个矩阵，同时也可以很有效的去管理这些需求，后期所产生的变化。

用户故事地图之后所产生的用户故事地图还是可以予以保留，作为组织的一资产，以便将来某些西化的条目可以被其它项目重复利用。