来，讨论一下怎么写需求文档吧

Scott

原文摘自JavaEye http://www.javaeye.com/topic/178200
iFire
先谈谈我的想法。

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

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

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

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

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

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

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

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

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

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

大家是什么看法呢？


上一篇：软件质量管理体系概论
下一篇：项目经理经典时间管理教材－别让猴子跳回背上

Scott

alexv
需求文档的后段维护，重点在专人负责，有一定的工具辅助效果可以更好。个人认为word文档适合作为对外交流的格式，内部使用并不合适，还是把数据录入系统方便很多。


引用
交叉阅读，导航困难的问题。易理解，易沟通，易确认

用wiki效果还不错，提供整体导出。

引用
易跟踪，易测试

这是问题追踪系统（如BugZilla、Jira）的强项

把两者结合起来的
1、开源的Trac系统
2、atlassian的Confluence + Jira

还有很专业的需求管理系统，要银子砸的，不过复杂到没有什么用的欲望了
1、DOORS
2、RequisitePro开始的RUP套件，基本围绕word搞得需求系统，很强悍
细节参见http://blog.csdn.net/msde/archive/2006/11/28/1418486.aspx

最近发现Jolt Project Management Tools提名的软件还有很多，如Rally、VersionOne等，不过偏项目整体管理了。

Scott

alexv 写道
需求文档的后段维护，重点在专人负责，有一定的工具辅助效果可以更好。个人认为word文档适合作为对外交流的格式，内部使用并不合适，还是把数据录入系统方便很多。

我倒觉得内部使用还不是太大的问题，对用户来说问题大些。如果不便于阅读，用户是很烦的。甚至都没有耐心仔细读下去。


alexv 写道


引用
交叉阅读，导航困难的问题。易理解，易沟通，易确认

用wiki效果还不错，提供整体导出。


恩，wiki内部交流确实不错，但作为需求管理是否合适呢？有啥优劣么？如果你对外交流仍然用word那你是否需要维护两套文档呢？这非常的不便啊。


alexv 写道


引用
易跟踪，易测试

这是问题追踪系统（如BugZilla、Jira）的强项

把两者结合起来的
1、开源的Trac系统
2、atlassian的Confluence + Jira


我说的易跟踪，易测试主要是指需求或需求文档本身需要具备这些特质。另外貌似.net社区基本上不使用这套工具。呵呵。


alexv 写道

还有很专业的需求管理系统，要银子砸的，不过复杂到没有什么用的欲望了
1、DOORS
2、RequisitePro开始的RUP套件，基本围绕word搞得需求系统，很强悍
细节参见http://blog.csdn.net/msde/archive/2006/11/28/1418486.aspx

最近发现Jolt Project Management Tools提名的软件还有很多，如Rally、VersionOne等，不过偏项目整体管理了。


恩，有两个主要因素制约使用这些工具：
1、很贵的说；
2、使用复杂，而且从中所能获得的收益似乎远远不及这些工具厂商宣传的那样。

Scott

先讲讲我这里的情况：
1、我们的最终用户不是IT人事，不关心提交文档的细节，他只关心宏观的功能是否有，基层使用是否满意……so，需求文档的内部意义 比 对外重要很多。
2、需求文档一旦提交用户确认后，对外变动仅仅需要提交变动说明即可，不用重新搞一个新版本；必要的时候，从wiki导出吧。

我更关心需求的完备性、可检索性。文档格式难以胜任：
1、需求和设计间是有一个过程的，需要对需求逐条分析、讨论、设计，中间有很多有价值的过程信息，往word里写很麻烦，而且很难事后检索；
2、功能需求是分阶段发布的，如何跟踪功能需求在各阶段的覆盖情况，对我很重要；
3、对需求的定向检索、需求关联（in-link,out-link）、版本变动、需求变更；
4、开发阶段对需求的追踪、反馈。

如果关注的仅仅是文档本身的质量，word可以搞定；
但关注文档的维护性，可能需要一些工具的支持吧。

Scott

iFire
恩，我没有太多使用这些工具的经验，但从使用的角度来讲，我希望将需求撰写、维护、管理和需求展示分离。我只需要维护一套需求文档（要很方便撰写，大部分工具比Word还是差远了啊），但可以以不同的格式展示出来（比如对用户使用其最适宜的格式进行展示）。如果工具能做到这点还是不错的。当然我希望工具也能尽可能简单。呵呵。

Scott

iFire
继续抛砖。

前面我谈到了将业务规则放到业务规则文档中。但这样做导致交叉阅读，非常不便。并且不容易让读者更好的全面理解需求。因为用例和业务规则的交互是很频繁的并且他们的联系是十分紧密的。那么有什么办法解决么？

我的想法是将业务规则直接放到对应的用例中作为一个逻辑上的小节。那么问题就来了，如果多个用例引用相同的业务规则呢？这导致很多重复，难于维护啊。

那么我们先考虑一下用例作为用户的一个比较单一的业务目标。不同的用例是否真的有那么频繁的引用相同的业务规则呢？实际使用中，我发现其实是很少的。

如果确实遇到了该怎么办呢？

有两个方法可以考虑采用：
1、检查用例是否划分得当；我觉得大多数情况都是提取的用例粒度过大导致的。
2、将不同用例中相同的部分提取为子功能用例。

Scott

alexv
多个用例引用相同的业务规则原文，交给人去维护，会死人的......一修改，就改的鸡飞狗跳，典型的冗余导致的修改异常

引用同样的规则，就用word的链接搞吧，会轻松一点的...

Scott

iFire
我上面的意思是说，多个用例引用相同的业务规则的情况本来就不多。而且通过适当的划分用例的粒度，以及提取子功能用例的方法。基本上可以消除重复。所以不存在维护冗余信息的问题。

我之所以把业务规则放到用例中。主要基于用例和业务规则实在是联系紧密。把他们分开实在是很不便于阅读及理解。

caixf919

可以介绍下有哪些维护工具吗？

@睫毛溺水了

很有借鉴意义，先收藏了，谢谢楼主。

不落╭若殇舞

学习下我只是路过，不发表意见……

我是定期发光i

看了LZ的帖子，我只想说一句很好很强大！

满分

看起来好像不错的样子

絮夏o

以我的经验来看，楼主的想法是可以执行的~

╭ァ1个没

打酱油的人拉，顺便赚点金币