育才学习网1.怎样的需求文档才是合格的需求文档
软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。
开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。
构造并编写软件需求规格说明，并使用户和其它读者能理解它牢记以下可读性的建议： ● 对节、小节和单个需求的号码编排必须一致。 ● 在右边部分留下文本注释区。
● 允许不加限制地使用空格。 ● 正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。
● 创建目录表和索引表有助于读者寻找所需的信息。 ● 对所有图和表指定号码和标识号，并且可按号码进行查阅。
● 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。 优秀需求具有的特性 怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（ Davis 1993;IEEE 1998）。
让风险承担者从不同角度对S R S需求说明进行认真评审，能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的（尽管并不十分完美）需求文档，同时也会开发出更好的产品。
1、需求说明的特征 1）完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 2）正确性 每一项需求都必须准确地陈述其要开发的功能。
做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。
只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”
其实这完全是评审者凭空猜测。 3）可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。 4）必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。
“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。
2.市场需求文档和产品需求文档区别是什么
该文档是软件产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是某个软件产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。
一般在互联网企业中MRD都是由运营人员和产品设计人员共同制定完成的，互联网软件产品由于最终直接面向终端用户，且需要长期运营，作为互联网企业中的运营人员是最清晰市场动向？产品受众是哪些人？为什么需要产品人员配合呢，主要是因为运营人员很普遍的观念是以运营商品的视角来考虑问题并未能深埋产品级的需求，所以两者配合来制定编写市场需求文档是最合适不过的。产品需求文档（Product Requirement Document,PRD），该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。
该文档一般是由产品设计人员来完成，也就是传统意义上的需求分析，其主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程、子流程、分支流程，等几大块），功能点业务流程框线图，界面说明，Demo等。
3.来,讨论一下怎么写需求文档吧
用例和UP的讨论
UML 中各种图形的重要性排行
先谈谈我的想法。
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
易理解，
易沟通，
易确认，
易跟踪，
易测试，
易验收
我想我们都应该以这个为目标来进行思考。
推荐链接Java开发新方式：专注UI，快速开发！