浅谈软件项目管理（三）

 刚刚犯了一个错误，文章写好了忘了发表，就切换到了另外的页面，结果写了1个小时的东西全丢了。可能是今天感冒的缘故，头有点晕晕的。本想不写这部分了，但是觉得不好，不像我做事情的风格。

这篇文章主要写如何写需求说明书。写需求说明书，应该来讲我写得不是很好，不过好像我所有的计算机技术也不好。

这里我不写如何作用户需求。在我参加工作的这一年中，我很少直接和用户去做需求，这主要是由于我所在公司目前作的很多事情还是一个研发阶段，具体的用户还不是很明确。即使有用户，这些用户对他们想要的东西也是一塌糊涂，很多时候他们都说这些东西是你们公司提出来的，说了我也不知道：）。就我个人而言，用户能够参与需求分析那是最好不过的了。然而现在的大多数用户的确对他们想要的东西也不是很清楚，所以对于我们来讲，在作需求时，很多时候是在引导需求。即我们根据自己的经验和想法，觉得这个用户可能会需要这个功能，然后由我们提出来，然后让他决定这个功能是否对他有用处。

需求分析的最终输出结果肯定是一个需求说明书。关于需求说明书的格式，我想各个公司都有自己的模板，网上也有很多这方面的模板可以借鉴。由于涉及保密问题，我用的这个模板是不能提供下载的。虽然这个模板不是我写的，但是我觉得它的依据还是一些关于这方面的国家标准。比如《计算机软件产品开发文件编制指南》等等。有兴趣的朋友可以到http://www.gb99.cn上去下载。

在实际工作中，给用户阅读或者讨论的需求说明书与最后软件开发人员拿到的是有区别的，当然两者的目的都是把用户想要什么东西说清楚。给用户看的专业化的程度要低一些，很多都是口语化的东西或者图形表示。而给软件开发人员的有很多专业上的东西，因为需求说明书是后面概要设计，详细设计，编码测试以及更加细致的工作安排的基础。

下面说说需求说明书应该包含哪些内容。

1、总体功能描述。一份好的需求说明书，在最开始的章节一定要有一个对系统的总体说明，先给读者一个总体的认识。关于总体描述的形式有很多，这里我谈谈我的想法。首先，应该有一段文字性的说明，这段文字应该叙述了该系统的目标。比如帮某某用户解决什么问题。这段文字不能太长，太长就不是总体描述了。然后，画一个功能分解图（就是一个树状图），用该图来描述系统有哪些功能模块。当然，功能模块的名称一定要通俗易懂，最后人家一看名字就知道你这个模块主要实现什么功能。功能模块的划分不需要很细致，一般写到第二层就够了。当然，如果功能模块的名称看起来的确比较难懂，则可以加一些文字上的说明。有了功能分解图后，就可以画一个功能列表了。在功能列表中对每个功能模块进一步细分，细分的程度我的建议是划分到系统的最小功能点。当然，在功能列表中，不需要对功能点有很详细的说明，详细的说明可以在具体功能描述中叙述。实际的书写需求说明书中，不可能每个功能点都非常清楚，在这种情况下，功能的划分也就不可能很细致了。但是需求总是不断明确的，在系统完成时，应该要补上这部分的内容。实际上，软件开发的很多文档，也是在实际的开发过程中不断完善的。也许有人认为后面补文档没有用处，我并不这样认为。文档对于后续的软件开发比如升级，维护是很有用处的，而且当有新的开发人员加入时，文档对于他们很快的进入角色有很大的作用。

2、与外部系统的联系。在需求说明书中，一定要说明所开发系统与其他系统的联系是什么，是共享数据还是什么等等。实际上在做需求调研时，调查已有的系统是一个必须的过程。这样不仅能够帮用户节约资源，也可以提高系统的实用性，因为从用户已有的系统上，可以搞清楚用户的操作习惯，以及用户的真实需求。

3、用户说明。在需求说明书中，一定要清楚详细的说明系统针对的用户是谁，这类用户的特点，这类用户要使用系统什么功能。当然这里说的用户，可以是自然人，也可以是非自然人，比如某个系统等等。有很多同行在写需求说明书时，会有一个总体用例图，在这个用例图中反映了系统的用户，以及用户要使用什么功能。

4、具体功能说明。根据总体功能描述中的功能列表，要逐个细致的描述每个功能点。描述功能点的方式很多，可以采用文字的形式，也可以采用用例的形式。但是其主要目的还是说明这个功能是为谁做的，为谁做什么而已。

5、性能说明。比如系统对精度的要求，时间的要求等等。

6、设计约束。比如系统要符合什么标准，以及技术上的限制，比如采用什么操作系统，什么语言，什么数据库等等。

上面的内容是我依据我公司现行模板在写需求说明书时的心得。但是在写需求的过程中，也发现了现有模板的很多问题，因为发现有些问题依据现有模板没有办法说清楚。最近时间，我看了一本叫做《系统分析与设计教程》的书，这不书用了很大的篇幅来说明需求的撰写。从这本书里发现，公司现行的需求说明书实际上只规定了“事实描述”这部分的内容，即需求建模的内容，对于企业建模，开发策略上并没有要求说明。最近公司出了一个软件开发流程的规范，已经提到了企业建模这部分的内容，但是模板目前还没有改，希望以后会改过来。

最后，还需要强调一点，在作需求分析时，最好要出一个系统原型，这个原型可以作为与用户明确需求，与开发人员讨论需求，进行设计的基础。可能建系统原型需要花费一段时间，但是我认为这个时间是值得去花的，一方面可以更加明确的确定需求，另一方面也可以便于开发人员理解系统，以提高开发的效率。