《需求说明书》是需求阶段最关键的产出物，我们公司测试部的同事常常抱怨，有的项目的需求说明书看到末尾还是不清楚系统要做什么，无法写出测试用例。我想我们很多人，尤其是工作经验不多的人，对需求说明书要写些什么东西也是糊里糊涂的，即使能够从RUP的教材上搬出来一些名词，也往往不理解其中的内涵。我把我的经验写下来，放在博客上，一方面自我总结，另一方面，希望和大家讨论，共同提高。

以前我们学过各种各样的软件工程理论以及具体的操作方法，我也不记得这些书籍或者资料里面是如何讲解需求说明书的写法的。可能是我当时没有认真学习，也可能是当时对很多东西并不理解，死记硬背一些东西过会儿就忘了。

我认为，需求说明书首先要描述目标系统的背景、功能概述、系统边界、和其他系统的关系、系统的运行环境要求等等。然后针对目标系统的每一个功能逐一详细描述。详细描述需要说清楚如下四个要素：

<!--[if !supportLists]-->1、 <!--[endif]-->该功能的业务流程，

<!--[if !supportLists]-->2、 <!--[endif]-->该功能的业务规则

<!--[if !supportLists]-->3、 <!--[endif]-->该功能的操作界面

<!--[if !supportLists]-->4、 <!--[endif]-->该功能涉及的业务实体

业务流程：

业务流程说明这个功能的办理步骤、以及每个步骤有哪些角色参与。

建议业务流程用活动图并辅以文字加以描述。

业务规则：

业务规则是指业务办理过程中的一些约束条件，包括前台界面校验规则和后台业务逻辑规则。

业务规则一般用文字描述，建议紧接着业务流程图，针对业务流程图中的每个操作环节，逐一描述其业务规则。

操作界面：

操作界面是要说明，系统建成之后，用户面对的操作界面的布局以及界面元素。

有些人喜欢用visio画原型界面，我本人建议用html做原型。用html有两个好处。

<!--[if !supportLists]-->第一，   <!--[endif]-->逼真。可以做到原型系统的界面以及操作模式和验收后的真实系统非常接近。这样用户就容易对系统产生直观的认识，需求阶段提意见也提得更准确，可以大大减少需求的不确定性。

<!--[if !supportLists]-->第二，   <!--[endif]-->用html做的原型可以直接在编码阶段采用，既减少工作量，又使得产品与需求偏离不会很大。

业务实体

业务实体是指业务流程中的各个环节操作的表单、数据等对象。

需求阶段明确了业务实体以及业务实体的属性非常有利于后续的数据库设计。

需求说明书说清楚了“四要素”，实际上就说清楚了如下问题：业务的办理流程是什么？业务办理条件是什么？操作员通过怎么样的界面办理该业务？系统最后操作哪些数据、生成哪些表单？

基于需求的四要素，需求说明书的目录结构一般是这样的。

本文出自 “非也” 博客，请务必保留此出处http://feiye.blog.51cto.com/126688/40405