【转】软件系统需求说明书写的经验之谈

原文地址：http://tech.it168.com/a2009/0430/274/000000274583.shtml

    软件工程中明确定义了，最为一个软件需求说明书的任务，它是一个沟通客户和程序员的纽带，是一个对于系统将要干什么的详细描述。因此，在这个文件中，必须包含很多内容，最近几天，我一直在阅读一份很奇怪的需求说明书和设计说明书，这两份资料里，不但没有系统流程说明，而且没有概念定义，需求说明书先写系统与其他系统关系，然后是系统菜单，后写菜单内容，最后写设计的表结构，我连软件对应的实体有几个都没弄清。设计说明书中，先写系统目的和产生原因，后写定义的数据和功能界面设计，我连设计的那些表哪些是其他系统定义的，哪些是自己生成的，数据如何关系都不知道。就这样两个文件，要设计程序代码，读得我这个头疼啊！
    下面是我根据我历史曾经做过几个管理软件系统的需求分析与设计的经验，写的心得，希望能给大家以帮助。
    一个需求说明书，必须包含以下内容：
    1、必须包含系统建立的背景资料，目的和参考资料索引以及附带相应的参考资料文件。这部分信息看上去似乎对于软件开发没有直接关系，但是，它就象我们吃一道菜必须有盘子一样，必不可少。它首先告诉读者，这个说明书依据什么而写的。
    2、必须包含系统的简单介绍。简单介绍最好能用图片说明，或者不要超过200字。就象文章的关键词一样，系统简单介绍是让人们快速把握系统是什么的关键内容，使阅读者有一个概念。这就象一个菜的名字/简介一样，简单，易于掌握。
    3、必须包括系统的范围、主要完成什么内容、和已经有的或已知的正在建的系统关系是什么？这个关系描述，有两种，一种以业务操作为线索描述操作员在哪个系统做什么，又到另一个系统做什么。还有一个线索，是程序开发角度，一个系统给另一个系统提供了什么，内容是什么，或者系统间用什么方式沟通的等。根据阅读者已经有的共识和知识体系去书写。
    4、必须包括计划安排或开发人员安排。这个内容很关键。也很微妙。因为开发人员有的能力强，有些功能能做，有的能力弱，有些需求他可能不会做。我曾经做过些系统，也写过需求说明书，很多时候，因为开发人员的变动，往往会影响系统计划与质量。因此，一定事先获得开发人员的配置。一般需求说明书在书写开始，是没有这个信息的，只有当需求基本确定后，就可以根据功能范围，由开发团队计划出一个人力预安排，根据这个人力安排，时间安排等来决定系统开发到什么程度与范围。这部分内容，如果放在概要设计时，就有些偏晚。因为需求不应该只是用户想要干什么，很多时候，需求目标是要综合多方面因素来确定的。如果放在概要设计上，就会使一个系统说好完成什么，但实际上却被分出几个阶段来实现，或者需求都谈好了要这样实现，结果开发人员不会做，不得不改变目标甚至流程。因此，在需求说明书书写中，一定要在需求框架基本明晰的基础上，进行开发人员的确认与预安排。预安排的结果要写在文件里，作为一个参考资料。
    5、必须包含业务/操作流程描述。可以用E-R图，写清楚都牵扯了什么部门，每个角色/实体都怎么怎么样操作的。或者用业务流程图去说明，或者用表格/文字说明。但是必须说明清楚。并且，是需求分析中占主要的部分，尤其是一个新建立的系统，这部分内容可能经常被改动！这是我做过10来个管理信息系统（包括几个大型管理软件）分析设计的经验。这部分内容的改动是恐怖的，尤其是新建立一个系统，各部门先决定这么干，讨论讨论就出问题了，又换一个想法。建立管理信息系统的时候，会引起企业流程重组，业务关系变化，个别操作简化，职能重组，这些都直接引起要建立一个新的流程。所以，如果想让系统做好，就要把这部分内容写的不能再细，说的不能再清楚，同时，还要忍受在与用户讨论、小组分析中可能要不断推翻重写与改动。要经得起各方面推敲。
    6、必须包含概念定义。不要小看概念定义，它就象说文解字一样，是解决沟通障碍的关键问题。如果懒得做名词解释，就一定会为它付出代价。代价就是可能会多出去很多问题，多开好几次讨论会，延长整个软件项目实现的时间。甚至，可能程序都做出来，某个功能根本不是用户要的。概念定义一定要定义准确，严谨，反复推敲，避免二义性，要同时能被用户和开发人员读懂。最好定位阅读者具有小学文化。
    7、必须包含系统数据流的说明。这部分内容看上去好象是概要设计的内容。其实，在需求报告中，不应该只简单说明有什么什么单子，上面有什么。一定要说明清楚，谁根据什么产生了这个信息，信息里有什么，经过什么途径，又给了哪个位置等。同时，如果流程重组了，可以不描述旧的流程，直接按照新的流程开始说明。这部分不仅可以使阅读者明白详细的系统要求，同时还可以给需求报告书写人员一个整理思路的方式。它可以使需求分析更准确严谨，避免出错，遗漏或避免一些关键点没问清楚。
    8、必须包含界面或其他要求的描述。比如数据精度，界面颜色与布局风格等。很多人尝试在概要设计中，去做这部分内容，其实，有的时候，在需求报告中，也要反应用户的要求。现在很多用户已经具备了比较强的计算机理解与使用能力，他们有时会主动告诉你他要的是上面有什么，下面有什么，左面什么样，右边什么样，哪个地方都怎么样。这是很宝贵的信息，采集并获得用户确认，就可以使系统推广的时候，减少不少阻力。
    9、必须包括系统未来的思考。这部分内容主要是作为一个需求调研人员，需求分析后，认为系统现在这样做，还有哪些局限或不足，将来还可以发展成什么样。这部分书写，可以给系统概要设计人员定义系统生存周期、设计数据结构等提供宝贵的参考资料。因此，如果有能力，就要让自己发挥作用，一定别忘了写上。
    在需求说明书的书写中要注意的几个问题与误区：
    1、不要怕写的多。一定要建立合理的目录结构，使人们可以按照自己关心的部分去阅读。不要怕长，但是语句一定要准确精练。有的时候，阅读者不一定需要第一次就把文件全看完，他首先是有一个概念，然后去某部分仔细确认与查找。要把需求说明书写得象我们的手机使用说明书那样，越明白越细致越准确越好。
    2、千万不能出现二义性。在需求说明书中，有二义性的语句可能会产生灾难性后果的！所以，作为书写人员，一定要尽量回避二义性，同时做需求报告评审审核时，也要把二义性做为重点消除目标。
    3、写报告前定义阅读者。这个工作可以写在需求说明书里，让每个阅读者都知道，也可以开发小组内部确认就行了。因为实际情况不同，需求说明书可能不是给用户读，也可能是用户与开发人员，还可能是用户、开发人员和某些特殊部门。阅读者的不同，会影响我们说明书的内容与书写角度。看看手机说明书，如果是给用户，一种写法，如果是给维修人员，一种写法，如果是给测试人员，一定是另一种写法，所以，需求说明书书写前，要确认阅读者范围。
    4、一定要在写需求说明书的同时，保留一份书写记录。这个工作看上去没什么，其实，这个工作可以帮助你去清理思路，甚至指导需求分析人员，去问什么，找什么人，系统计划是否合理等。我的记录内容是一个表格，从什么时间开始，到什么时间，做了什么，参与人是谁，内容简介。比如，我接触一个系统，先根据个人经验，写了一个系统框架，以它为第一稿。然后获得了一些电子文件资料，我就会在书写记录里加一行，什么时间，从谁那里获得电子资料，是什么，放哪个目录里了。然后，根据这个电子资料，写了一个改动文件，定义为第二稿，我也会写什么时间，写了第二稿，与第一稿的区别主要是增加/修改了哪些内容。 我个人觉得，这个资料对于一个大型管理系统的分析非常有用，前后责任人及项目进度很清晰。
    5、讨论会议与流程确认前，一定要写计划及执行结果。内容为有哪些疑问，都是怎么回答的。这个资料可以使需求说明书更严谨，不容易出错，也可以避免一些理解偏差与重复讨论。还可以参考结果进行计划安排。
    6、个人定位要低调。做需求调研和报告书写，必须本着唯物主义，客观的，冷静的观点去书写。同时，还要肯付出，对于反复修改的工作不厌其烦，始终保持耐心细致，扎实认真的态度。这个态度决定说明书的可用性有多高。