需求文档开发体会_写于AE内网需求开发中_软件开发需求文档范例

需求文档开发体会_写于AE内网需求开发中由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“软件开发需求文档范例”。

最近一直忙得不可开交，也没来照顾下版面，抱歉哈。

今天刚刚尝试做了个需求文档，上来谈谈感受，欢迎大家拍砖。

先谈谈开发的需求的简单情况，这次是公司的一个内网管理系统的开发，负责项目的同事做了一个需求原始文档出来，因为我一直在攻需求方面的工作，所以就中途加了进来。

需求文档的一般结构应该包括概述和正文两个部分。概述部分主要介绍文档的目的、读者对象参考文献，以及项目的范围等内容，还有一些梗概性的需求可能也会放在这里。正文部分一般包括功能性需求和非功能性需求，非功能性需求一般包括各种约束，系统的接口，硬件平台、软件平台等约束，还有性能需求等内容。只要是用户要求的合理内容都要作为需求，这是区别需求和设计的一个判断标准。比如，某个系统需要用一个具体的方案实现，如果这个实现方案是客户要求的，那么这个方案实现就要作为一个需求，如果这个实现方案，客户没有明确要求，那么这个方案实现就不能作为一个需求，而应该作为设计考虑。

另外，概述部分还应该包括对术语的介绍，以统一需求开发中对于概念的描述，不要小看这个东西，当你真的写起需求的时候，你会发现不断的有新的名词加进来，而你需要定义的名词会越来越多。

在写需求时，最好先把客户的整体需求把握好，就是最好先把最骨干的需求写出来，写完这些骨干需求的时候，可能你会发现需求之间就已经有一些约束要考虑了，（这些需求之间的约束也是写在需求文档中的）比如在我们的需求中，项目经理和部门经理之间的权利该如何划分，如果这个问题不弄清楚，软件需求的设计就很难继续，因为他们之间的权利可能存在重叠，而这种重叠可能是存在问题的，这个问题可能是本身工作流程的问题，那么应该怎么解决呢？

对于暂时不能确定的需求，建议在这个需求项上标注TBD（to be determined）

把握了大需求后，就可以在每个大需求下面分割小需求了。写需求的工作有点像写目录，一级一级的往下写，最初的写上的都是需求树的枝，当发现这些枝再也没有办法往细分的时候，就可以添加需求的叶子了。需求的枝一般用一个短语或者名词描述比如一个项目管理的功能，它的分支可能是这样的：

项目管理

1.1 项目创建

1.2 项目修改

1.3 项目检索

接下来是需求的叶子如何描写，一般情况下，具体的需求项应该有一个需求ID用于标识需求，比如这样一个项目管理的需求，我们可以定义需求ID前缀为PM，在ID前缀后面加上编号就是一个完整的需求ID了。

接着上面的例子我们来看一下：

项目管理

1.1 项目创建

PM1：项目应该由项目经理创建

1.2 项目修改

PM2：项目提供xxx修改方式

1.3 项目检索

PM3：项目经理可以通过项目编号检索项目

PM3.1：检索到的项目应该分页显示

PM4：项目经理可以通过项目关键字检索项目

建议：

1、需求的ID最好在整个文档中是唯一的，不要在不同的地方出现同一个ID。

2、最好的情况是，ID的排列是有顺序的。

3、如果一个需求不能完整的描述一个内容，可以考虑在这个需求下面添加个子需求，如PM3.1。这只是一个建议，因为这样可能不是一个良好的树状结构——因为叶子下面又增加了叶子。另外一种更好的表述方式：

1.3 项目检索

1.3.1 项目编号检索

PM3：项目经理可以通过项目编号检索项目

PM4：检索到的项目应该分页显示

PM5：如果没有检索到项目，应该提示出错信息

下边这种方式是更值得推荐的，但是在我们编写需求的过程中，似乎上一种方式更加自然，更容易适应我们的思路，大家可以在实际的尝试中试一下。

在编写需求过程中，我觉得需求不宜写成一大段，而没有分隔，这种情况下很难识别需求点。也不便于阅读。能够将需求拆分成项，也利于需求开发者的思考。在开发人员根据需求实现的时候也更直观。

开发需求的过程中，建议大家一定要从始至终按着一定的规则，从一而终的开发，不要因为嫌效率太低而放弃这种方式，你在后期的开发中会发现没有放弃是多么的正确。需求本身就是一个不断丰富的过程，即便你从一而终的按照一定的格式编排，到最后还是发现格式需要调整，所以千万不要以为忽略了格式没什么大不了，当你发现的时候已经乱成一团了。

对过程的描述，有时候可能功能之间的关系是一个有联系的过程，比如项目管理这个需求，项目的创建是项目检索的基础，而只有检索到项目，才能对项目进行修改。这样一个过程，可能我们在之前的需求中并没有明确的描述，同时对于不了解的人，他们只从上面的需求中可能也不能看出这个工作流程是怎样的。因此有时候对于过程的描述是有必要的，尤其那些过程比较复杂的工作，更需要描述过程。

描述过程可以通过文字，也可以通过图形，在UML建模中则通过用例图、顺序图、场景图来描述。通过图能够更直观的演示过程，而文字可能能够描述更多的细节，这要看具体的使用情况了。UML建模是一种非常推荐的方式。

在我们描述过程的时候，往往会发现更多的需求点，以及需求之间的约束，这些都应该反映在需求项的开发中。

过程的描述可能存在的问题是：在描述的过程中，可能是一段文字，而文字中对需求点的划分不明确，不容易把握需求点。在开发设计方案中，可能会造成遗漏。图形的方式固然很直观，这样的方式会不会带来其他问题我说不好。所以建议大家能够相互结合来进行需求的开发。

需求开发本身就是一个复杂的过程，需要将手头的各种资料进行分析和整合，而得到一份系统的需求文档。写出一份漂亮的需求并不是容易的事情，所要耐心、细心，甚至疑心。找到那些客户需要的功能，也要考虑这些功能是否的实现性，以及存在的潜在需求或约束。甚至在需求开发中，还会发现原有流程的漏洞，而这时，需求开发可能还要担负一部分流程改造的职责。