(原创文章，欢迎转载，请注明出处)

上回说到需求分析的一些内容。这回我总结总结我对需求建模和跟踪方面方法。

 

需求也是有模型的，有很多UML语言支持需求的建模，它不是UML的标准视图，而是扩展的视图。我喜欢用UML的Enterprise Architect, EA；虽然有很多很好用的开源UML工具，我还是选择了EA。原因很简单：稳定、简单、易用、强大。

 

EA支持对需求建模。需求是一个非常复杂的东西，可能需要不同的方式进行表达，才能表述清楚。如界面的需求，其实就是很麻烦的，除了功能的组织外，可能还有每个控件的位置及其显示的内容和交互方式。用自然语言还不太好描述，最好能用图片画一下，那就一目了然了。所以EA提供的Requirements建模的工具箱里的元素不够多，如果是在有别的需要，可以考虑使用Toolbox里的Custom工具。里面就含有对界面的建模。如图所示：

 

需求的建模，是为了：

1.理清楚需求与需求之间的关系；

2.理清楚需求的种类，哪些需求是功能需求，哪些需求是性能需求，哪些需求是扩展性需求等等；

3.将需求细化到可追踪的粒度；

4.明晰需求的范围；

5.确定需求的优先级别。

 

EA为需求模型准备了聚合、继承、关联、实现等关系。需求分为：功能、性能、打印、报告、测试、验证等类别。EA里这些需求类别倒是没什么太多的意义，我觉得功能、性能、维护、测试等需求分类可能更好。不过，这个分类仁者见仁，智者见智，没啥太好说的。主要看这需求间的几种关系：

 

• 聚合关系：一组需求聚合为一个需求，旨在强调整体与部分的关系。“包含”、“组成”、“组成...部分”都是聚合关系的一种描述。例如，客户端与服务器之间通信的需求，实际上就是由服务器与客户端握手、服务器与客户端传输数据、服务器与客户端停止通信等需求聚合而成的。聚合关系可以用来分解顶层的需求，将其分为粒度较小的需求；
• 继承关系：继承关系或泛化关系旨在强调普遍和特殊的关系， 例如，系统允许客户登录这个需求，实际上可以特殊化成两个需求，一是该计算机的终端登录，另一个是从网络或其它通讯接口远程登录；这两个需求是客户登录这个需求的特殊的例子。分析继承关系的时候，旨在强调特殊需求之间的独立性和互斥性。聚合关系是一组需求组合成一个需求，如果少了任意一个需求，被聚合的需求就不完整。而继承关系下的特殊需求少了任何一个需求，这个需求看起来都是完整的。终端登录和远程登录少了其中任何一个，用户登录这个需求都能完成。这个关系还强调终端登录与远程登录之间的独立性和互斥性。
• 关联关系：个人觉得使用被使用的关系，除实现、聚合、继承以外的关系都可称为关联关系。:) 大杂烩。
• 实现关系：实现关系也很好理解，就是一个需求是为了实现另外一个需求而存在的。实现需求一般都是系统的边界了，用例、交互等等都可以与实现需求对应上了。

我在学习EA的时候，发现EA里也允许需求模型中出现依赖关系，当然为了增强语义，指出单方面的使用关系，可以使用依赖关系来描述需求与需求的关系。当把需求建立完模型后，EA的强大就显现出来了。选择View > Relationship Matrix，你可以发现

 

 

Source/target都选择需求模型，类型都选择需求，Link type:选择聚合，Direction可以选择both,我这里选择了Sorce->target。矩阵表会把所有需求间的聚合关系都列在这里，一目了然，当然，也可以查看其它链接类型。让我们很方便的查阅一个大项目中的需求与需求之间的关系。

 

需求变动那是经常的，有时候需要查看一条需求改变以后能影响哪些需求，其实这个用EA是很方便办到的。选中变动的需求，ctrl + shift+ 4 或 view > Traceability。

 

 

看到左侧多了一个Traceability的框，它显示了这个需求与其他所有UML中的元素之间的关系。 我们可以很轻松的分析这条需求变动后会对整体产生什么样的影响。

 

其实，在实践中，我不是UML专家，很多情况下就是为了团队能看清楚需求与需求间的关系，需求更改后能影响到哪一部分，相关的东西应该怎么改。所以分析需求与需求间的关系，我不刻意的去做，实在头疼了需求之间直接就使用关联关系。每个人拿到模型后，都是需要先理解需求的。再分析需求与需求间的关系，所以关联关系就被我滥用了。这有个好处，那就是使用跟踪矩阵的时候，不用来回切换了，直接选择Association即可查阅所有关系。但这不意味着，需求之外也这样干，那是自寻死路。

 

(To be continued...)

(原创文章，欢迎转载，请注明出处)