需求文档——需求文档怎么写
3星 · 超过75%的资源 需积分: 50 119 浏览量
2010-03-31
15:38:51
上传
评论 3
收藏 24KB DOC 举报 
相关文章:
用例和
UP
的讨论
——对业务建模的思考 为什么要业务建模 ( 转 )
UML 中各种图形的重要性排行
推荐圈子: JBPM @net
更多相关推荐
先谈谈我的想法。
一、要讨论怎么写需求文档，首先就的搞清楚需求的构成，我是这么分的：
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
二、弄清楚需求的构成后，我们就得考虑以什么样的文档结构来描述这些需求了，UP 的做
法是这样的：
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP 的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例
规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数
据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是
比较麻烦的，特别是对于用户来说。
而且 UP 中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。
但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。
资源评论
zqf08012014-08-13内容太少，写的太粗，不值10分。- yy_zyw2014-05-01不怎么样，内容太粗糙了。
- qq_345015512017-07-07等于没说，不值得下载
阿飞一世2014-09-24内容一般，不太好推荐
