五月 9, 2012

讨论一下怎么写需求文档

Written by

作者:iFire

先谈谈我的想法。

一、要讨论怎么写需求文档,首先就的搞清楚需求的构成,我是这么分的:
1、功能需求;
2、非功能需求或技术需求;

我一般把功能需求划分为几个部分:
a、业务过程;
b、业务规则;
c、业务数据;

非功能需求(技术需求)我就不多说了,大致就是可用性,可靠性,性能,可支持性等等。

二、弄清楚需求的构成后,我们就得考虑以什么样的文档结构来描述这些需求了,UP的做法是这样的:
1、用例规格说明描述业务过程;
2、业务规则文档描述业务规则;
3、术语表描述业务数据;
4、补充规格说明描述非功能需求(技术需求);

UP的做法还是很有道理的。这体现了两个原则:
1、分离关注点(每个文档描述相对独立的领域);
2、减少重复(很多用例都会引用相同的业务规则及业务数据);

这样便能够尽可能的使文档结构清晰,易阅读,易理解。也便于跟踪和维护。

但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航,你可能需要打开多个文档进行交叉阅读。这是比较麻烦的,特别是对于用户来说。

而且UP中每个用例都单独作为一个文件存在,这可能是为了便于跟踪及管理的缘故吧。但正如上所述,文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中(比如根据子系统划分)。

至于交叉阅读,导航困难的问题是否有什么别的方法解决呢?html文档似乎不错。不过写起来似乎没word方便啊。

三、总结:
无论怎么写需求文档,最终的目的无外乎易阅读,易理解,易沟通,易确认,易跟踪,易测试,易验收。我想我们都应该以这个为目标来进行思考。

发表评论

电子邮件地址不会被公开。

Proudly powered by WordPress and Sweet Tech Theme