俗语说的好：万丈高楼平地起。所以要想楼体稳固，地基需要打的牢。最近参与项目，偶然对撰写需求规格说明书萌生了一些想法和心得，因而在此记录下来，以供大家参考和借鉴。

所谓的需求规格说明书就是在项目初期与客户在需求上达成的一种协议，需求拆字解释就是需要和要求，客户提供需求，开发人员根据需求进行研发。所以需求就相当于万丈高楼的地基，只有在项目前期将需求定准了才能确定整个项目的走向，引领整个项目最终走向成功，由此可见需求说明书在整个项目中的地位。

在实际的IT项目中大致可划分为业务类项目与集成类项目，其中的业务类项目就是以客户的实际业务需求为主体来开发的一套系统，而集成项目则是将各个不同业务系统进行整合，实现数据打通的同时完成的一套信息化整合方案。本文主要对集成类项目需求的定位及整个需求至最终确认的流程进行阐述。

意义表述

1 可依据性

基于需求规格说明书是作为厂商与客户达成的一种协议的准则的特性，所以说明了其可依赖的性质。所谓的可依赖性也就是在项目稳步运行期间如果客户提出异议或变更即可根据最初与客户达成的需求说明书进行委婉的拒绝，当然此处所说的拒绝不代表将客户的异议等全部否定，需要适情况拿捏，如果客户的态度很强硬且变更较大的时候则需要再次签订需求变更并重新评估工作量方可。换个角度来讲需求说明书的撰写也正是对自己的一种保护。

2 可延展性

由于后续展开的所有工作包括对整个项目的设计都是根据客户需求扩散展开的，所以也就确定了需求规格说明书的可延展性。当需求与客户达成一致后就可以根据确定的需求进行相关功能的设计，此时就要将需求抽丝剥茧规划出整体的脉络与研发方向，每个功能细节都要围绕确定的需求进行展开，所以在需求撰写的同时也要完成对设计说明书初稿的拟定，这样才能将需求与功能页面等设计有效的进行结合，以免在某处发生脱节的现象产生。

3 可解读性

需求规格说明书最后的一个特性也就是解读性，这一点主要针对项目初期建立及后期维护。何为解读性呢？所谓的解读性就是通过对需求的研读可以让开发人员与维护人员对整个项目中客户的诉求及方向有明确的定位，方便项目的展开及后期调错升级等一系列的维护工作。

过程说明

1 搜集整体需求

在承接项目的初期首先要做的就是与客户进行沟通听取客户的诉求，还有很重要的一点就是在听取客户诉求时要与客户建立良好的关系，这样才能更加便于后期工作的展开。这一点听上去很简单就是与客户进行初步的沟通，往往容易对此进行忽视，其实不然，处在这个环节时说明是与客户的首次接触，客户的信任也是在此时建立，如果因为疏忽而对客户阐述的需求遗漏导致出错，就会直接失去客户的信任，进而对后续工作的开展产生巨大的影响。而在实际搜集整体需求的过程中为了避免类似以上的情况发生往往要对整体需求进行二次或多次调研及客户确认，在最终确认后方可进行后续工作，这么做即确保了需求的无遗漏也为后续工作提供了准确发方向。

2 系统需求确认

2.1 明确功能需求

此处也是与客户进行需求的确认，与上诉了解需求不同的是在这里不再是明确整体需求，而是对整体需求进行细化对整个开发过程需要完成的任务进行明确，比如功能性需求及实现方式等。此处一定要细致入微，因为在确认后就需要对整个项目的脉络有一个清晰的认知，知道客户想要什么，我们要去做什么，从而对整个项目进行分解评估。

2.2 明确集成需求

与客户确定好整体需求后就要与客户所述的需要进行集成的业务厂商进行沟通，沟通的目的在于了解被集成业务系统的功能及其大致体系，这么做的原因用一句话来解释就是“知己知彼，百战不殆”，所谓的知己知彼就是对我方及业务系统有足够的了解，而所谓的百战不殆的意思就是当客户提出对业务系统某项功能及实现方式需要集成时可以针对我方需要解决的问题及协助办法快速的给出回应，避免在后期因无法对接及难以实现等问题产生分歧。

2.3 明确非功能需求

在说这点之前笔者认为有比较先阐述一下什么是非功能性需求，所谓的非功能性需求就是与业务逻辑、功能实现无关的一系列需求，比如整个系统的安全性，体系的可靠性等等。这类需求看似关系不大，但其实不然，它就如同楼体框架，只有明确这些需求后才能确保整个系统的正常运行，同时它也决定着产品/项目架构及设计要点。所以在与客户研讨时一定要将此类需求考虑进去并进行明确。

3 撰写需求解析

3.1 分步撰写需求

明确好整体与功能需求后就要开始对需求规格说明书进行撰写，因为最终一切都要落实到字面上才有凭有据。文档撰写要立意明确、脉络清晰、细致无疑，清楚的将客户阐述的需求转化为文字，书写内容要把了解到的客户需求都囊括在内，并将功能性需求抽出分级进行说明。需要注意的是在撰写过程中对于某些点可能要再次与客户确认，对于模糊点要确认清楚，不可自行臆测推断，这样才能确保准确性并无遗漏之处。

3.2 设计倒逼需求

需要注意的是往往在编写需求规格说明书的同时也会初步拟定设计规格说明书，因为需求简而言之就是客户的一种想法，最终如何将这种想法落实才是重中之重，而设计规格说明书的主要用途就是将想法实体化。所谓的设计倒逼需求就是两者同时进行，通过需求构思设计，再通过设计直观的体现某些需求的实现方式进行倒推，可以更有效的保证需求的准确性。

4 内部评审需求

完成上文所述内容后说明对客户需求已经有了清晰的认知并且对需求规格说明书的撰写已初步完成，此时需要做的就是对所撰写的文档进行首次内部的评审，为了确保评审的准确性撰写人需邀请主管人员或者有经验的人员参与，以这种多人参与方式的好处就是不但可以提升需求的准确性还可以确保需求的完整性。评审的目的无它，只为纠错，如同项目上线前的测试一般，对发现的问题及时更正，更正后再次进行评审，周而复始，直至确认无误。这样多次评审的目的就是避免因书写不规范及内容有偏差而造成客户的不满，确保呈现在客户面前的是最准确最完整的一版需求说明。

5 客户评审确认

我想读者也应该清楚了一点，就是以上所做的一切都是为了此处的最后一步做准备，能够顺利的与客户完成评审才是最终目的，只有评审通过后才能进行下一步工作。与客户进行评审时仍需要仔细听取客户所述，因为此时客户难免会对需求内容有异议，而我们所要做的就是记录客户异议并提出看法最后再对需求说明书进行修改，修改后确认无误再与客户进行评审，直到最后达成一致并将确认一致的需求以邮件形式发送给客户。针对于上述的确认只是在评审过程中与客户达成的一种思维上的一致，所以在邮件发送后最好还是要有客户的回复或者签字留存作为一种佐证。

注意事项

1 需求搜集

其实在搜集需求时有些人往往会不自觉的走入一个误区，那就是搜集需求的同时会夹带着一些假定的想法和过多的去考虑实现方式，其实这样很容易为以后错误的产生埋下祸根，过多的考虑这些只会混淆我们的视听扭曲客户对需求真实的想法。在搜集需求时我们只需心无旁骛的认真记录客户所阐述的需求，对不明确的点及时与客户沟通明确，且不要轻易对客户提出的需求做出承诺，待需求明确后才可进一步考虑实现方式等。

2 文档撰写

在搜集完需求后就要将所有的需求落实到书面上也就是撰写需求说明书，撰写需求时可以以分工形式由多人共同完成，但是需要注意的是书写的格式必须一致不可在一篇需求文档中出现多种格式。对于需求说明书的撰写首先要将大纲列出保证脉络清晰无漏项，内容要以样例搭配文字说明的方式书写，在撰写期间可以对待明确的需求进行标注以便与客户进行确认后的内容填充，最后确认无问题后进行统一合并，并且要对合并后的需求规格说明书进行审查，内部评审，达成一致无误后方可进行客户评审。

3 迭代完善

最后一点需要注意的就是对于需求不是在项目前期做完就万事大吉了，因为在整个项目的生命周期中不可避免的会有需求变更等问题，所以对于需求来说会一直衍生到项目验收阶段，针对于期间变更的需求等要及时做好记录后续根据具体的变更内容对需求说明书进行修改，直至项目验收后再对完整的需求文档进行归档封存，为后期维护提供支撑。

个人所以

一个项目的成功不仅需要强大稳定的人员架构还需要参与人员各司其职无缝衔接，今天这篇文章，就是想让大家对此引起关注，撰写需求规格说明书看似平淡无奇无关紧要并与代码无任何关联，但实际上其发挥的作用却是巨大的，它发挥着串联整个项目中的所有业务及功能的作用。前文也说过需求说明书就像是基石，只有基石牢靠才能撑起整幢大楼，同理只有需求明确后才能引领整个项目走向成功。

而从另一个角度来讲需求也不是一成不变的，针对于小的需求变更可以直接调整但是大的需求变更却需要填写需求变更并与客户确认，在这点需要明确的是一定要甄别变更需求与蔓延需求的区别，需求变更是针对于当前的需求进行更改而蔓延需求则是根据当前需求提出的延展性的需求，所以它已不属于当前需求，对于蔓延需求的处理可以放在二期完成等方式。