需求文档模板

需求文档模板

我曾经也纠结于需求文档的模板，寻找并参考了很多模板。其实模板并没有绝对唯一的标准，可以根据项目的需要，修改现有的一些优秀模板而来。

以下是我喜欢也在用的需求文档模板，一个简要的大纲，是根据项目需要和工作经验不断修改而来，以后也许还会继续修改完善。模板中的第2部分用例（Use Cases）是需求的重点，是个很大的课题。

有了模板并不代表会需求分析，更不代表可以做的好。模板只是一个“壳”，是需求内容的组织形式，关键是要有“陷”。

 

=================  需求文档模板  =================

修订历史记录

日期	版本	修订说明	作者

1 引言

1.1 需求背景

1.2 需求目标

1.3 术语

1.4 文档约定

（描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。）

1.5 参考资料

2 用例

2.1 参与者

2.2 用例图

2.3 用例描述

2.3.1 用例名称

• 简要说明
• 参与者
• 前提条件
• 基本流程
• 扩展选流
• 后置条件

3 业务规则

4 数据需求

4.1 域的细节

4.2 域的校验

5 非功能需求

（性能需求、安全性需求等等。）

6 用户界面

<!-- .entry-content-->

Posted in 需求分析/产品设计.

Tagged with PD, Use Case.

1 comment

By TzingChu – 2010年03月9日

 

 

 

 

 

 

 

先谈谈我的想法。

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

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

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

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

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

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

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

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

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

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

大家是什么看法呢？