软件系统需求说明书写的经验之谈.doc

软件系统需求说明书写的经验之谈 软件工程中明确定义了，最为一个软件需求说明书的任务，它是一个沟通客户和程序员的纽带，是一个对于系统将要干什么的详细描述。因此，在这个文件中，必须包含很多内容，最近几天，我一直在阅读一份很奇怪的需求说明书和设计说明书，这两份资料里，不但没有系统流程说明，而且没有概念定义，需求说明书先写系统与其他系统关系，然后是系统菜单，后写菜单内容，最后写设计的表结构，我连软件对应的实体有几个都没弄清。设计说明书中，先写系统目的和产生原因，后写定义的数据和功能界面设计，我连设计的那些表哪些是其他系统定义的，哪些是自己生成的， 数据如何关系都不知道。就这样两个文件，要设计程序代码，读得我这个头疼啊！ 下面是我根据我历史曾经做过几个管理软件系统的需求分析与设计的经验，写的心得，希望能给大家以帮助。 一个需求说明书，必须包含以下内容： 1、必须包含系统建立的背景资料，目的和参考资料索引以及附带相应的参考资料文件。这部分信息看上去似乎对于软件开发没有直接关系，但是，它就象我们吃一道菜必须有盘子一样，必不可少。它首先告诉读者，这个说明书依据什么而写的。 2、必须包含系统的简单介绍。简单介绍最好能用图片说明，或者不要超过 200 字。就象文章的关键词一样，系统简单介绍是让人们快速把握系统是什么的关键内容，使阅读者有一个概念。这就象一个菜的名字 /简介一样，简单，易于掌握。 3、必须包括系统的范围、主要完成什么内容、和已经有的或已知的正在建的系统关系是什么？这个关系描述，有两种，一种以业务操作为线索描述操作员在哪个系统做什么，又到另一个系统做什么。还有一个线索，是程序开发角度，一个系统给另一个系统提供了什么，内容是什么，或者系统间用什么方式沟通的等。根据阅读者已经有的共识和知识体系去书写。 4、必须包括计划安排或开发人员安排。这 个内容很关键。也很微妙。因为开发人员有的能力强，有些功能能做，有的能力弱，有些需求他可能不会做。我曾经做过些系统，也写过需求说明书，很多时候，因为开发人员的变动，往往会影响系统计划与质量。因此，一定事先获得开发人员的配置。一般需求说明书在书写开始，是没有这个信息的，只有当需求基本确定后，就可以根据功能范围，由开发团队计划出一个人力预安排，根据这个人力安排，时间安排等来决定系统开发到什么程度与范围。这部分内容，如果放在概要设计时，就有些偏晚。