软件工程中明确定义了，为一个软件需求说明书的任务，它是一个沟通客户和程序员的纽带，是一个对于系统将要干什么的详细描述。因此，在这个文件中，必须包含很多内容，近几天，我一直在阅读一份很奇怪的需求说明书和设计说明书，这两份资料里，不但没有系统流程说明，而且没有概念定义，需求说明书先写系统与其他系统关系，然后是系统菜单，后写菜单内容，后写设计的表结构，我连软件对应的实体有几个都没弄清。设计说明书中，先写系统目的和产生原因，后写定义的数据和功能界面设计，我连设计的那些表哪些是其他系统定义的，哪些是自己生成的，数据如何关系都不知道。这样两个文件，要设计程序代码，读得我这个头疼啊！

　　下面是我根据我历史曾经做过几个管理软件系统的需求分析与设计的经验，写的心得，希望能给大家以帮助。

　　一个需求说明书，必须包含以下内容：

　　1、必须包含系统建立的背景资料，目的和参考资料索引以及附带相应的参考资料文件。这部分信息看上去似乎对于软件开发没有直接关系，但是，它象我们吃一道菜必须有盘子一样，必不可少。它首先告诉读者，这个说明书依据什么而写的。

　　2、必须包含系统的简单介绍。简单介绍好能用图片说明，或者不要超过200字。象文章的关键词一样，系统简单介绍是让人们快速把握系统是什么的关键内容，使阅读者有一个概念。这象一个菜的名字/简介一样，简单，易于掌握。

　　3、必须包括系统的范围、主要完成什么内容、和已经有的或已知的正在建的系统关系是什么？这个关系描述，有两种，一种以业务操作为线索描述操作员在哪个系统做什么，又到另一个系统做什么。还有一个线索，是程序开发角度，一个系统给另一个系统提供了什么，内容是什么，或者系统间用什么方式沟通的等。根据阅读者已经有的共识和知识体系去书写。

　　4、必须包括计划安排或开发人员安排。这个内容很关键。也很微妙。因为开发人员有的能力强，有些功能能做，有的能力弱，有些需求他可能不会做。我曾经做过些系统，也写过需求说明书，很多时候，因为开发人员的变动，往往会影响系统计划与质量。因此，一定事先获得开发人员的配置。一般需求说明书在书写开始，是没有这个信息的，只有当需求基本确定后，可以根据功能范围，由开发团队计划出一个人力预安排，根据这个人力安排，时间安排等来决定系统开发到什么程度与范围。这部分内容，如果放在概要设计时，有些偏晚。因为需求不应该只是用户想要干什么，很多时候，需求目标是要综合多方面因素来确定的。如果放在概要设计上，会使一个系统说好完成什么，但实际上却被分出几个阶段来实现，或者需求都谈好了要这样实现，结果开发人员不会做，不得不改变目标甚至流程。因此，在需求说明书书写中，一定要在需求框架基本明晰的基础上，进行开发人员的确认与预安排。预安排的结果要写在文件里，作为一个参考资料。

　　5、必须包含业务/操作流程描述。可以用E-R图，写清楚都牵扯了什么部门，每个角色/实体都怎么怎么样操作的。或者用业务流程图去说明，或者用表格/文字说明。但是必须说明清楚。并且，是需求分析中占主要的部分，尤其是一个新建立的系统，这部分内容可能经常被改动！这是我做过10来个管理信息系统（包括几个大型管理软件）分析设计的经验。这部分内容的改动是恐怖的，尤其是新建立一个系统，各部门先决定这么干，讨论讨论出问题了，又换一个想法。建立管理信息系统的时候，会引起企业流程重组，业务关系变化，个别操作简化，职能重组，这些都直接引起要建立一个新的流程。所以，如果想让系统做好，要把这部分内容写的不能再细，说的不能再清楚，同时，还要忍受在与用户讨论、小组分析中可能要不断推翻重写与改动。要经得起各方面推敲。

　　6、必须包含概念定义。不要小看概念定义，它象说文解字一样，是解决沟通障碍的关键问题。如果懒得做名词解释，一定会为它付出代价。代价是可能会多出去很多问题，多开好几次讨论会，延长整个软件项目实现的时间。甚至，可能程序都做出来，某个功能根本不是用户要的。概念定义一定要定义准确，严谨，反复推敲，避免二义性，要同时能被用户和开发人员读懂。好定位阅读者具有小学文化。