规格说明，它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。它是开发设计的蓝本，也是系统测试和用户文档的依据。
4、需求验证
需求验证是为了确保需求说明书准确无误、完整地表达必要的质量的一种方式。客户、分析人员、设计人员、测试人员等利益相关人员经过多次的评审后的需求说明书就可作为需求管理的基线。用户和开发方对软件项目内容的描述是以需求规格说明书作为基础，它是软件验收时合同双方确认的重要依据。
三、需求开发中存在的困难以及对策
在软件项目开发过程中，风险无所不在，如何有效规避风险，尤其是需求开发过程中的风险（需求风险）。本文按着需求开发的过程提供几条建议：
1、需求获取
问题一：用户对于自己的需求不太清楚或工作繁忙无暇理清需求
在很多的实际开发过程中，第一种情况就是用户对自己真正的需求并不十分明确，他们认为计算机是万能的，只要简单地说一说自己想要得到什么样的结果就行了。对于自己的业务规则、工作流程都不愿说谈。笔者在2006年曾准备开发一个医院的库房管理系统，当本人开始做需求调查的时候，就是存在用户无法准确有效地表述功能需求的问题。针对这种情况，其对策是：需求分析人员一定要深入用户工作场地，仔细查看用户的资料和报表，与不同层面的用户交流、沟通，且要多了解用户实际工作的场景，有条件的话，可以做一个“实习生”亲身体验用户的日常工作。站在用户的角度帮助用户分析需求。关注用户工作的每个细节，搞清用户的真实需求，以最大可能减少后期地需求变更。第二种情况就是业务人员配合力度不够。有的用户日常工作繁忙，他们不愿决付出更多的时间和精力向分析人员讲解业务。面对这种用户，其对策是：需求分析人员改变沟通技巧，讲清楚软件需求的重要性，见缝插针，抓住关键点，向其咨询，以用例和模型的方式向其演示，达到用户和分析人员互相了解和理解。
问题二：用户与需求分析人员缺乏有效沟通，双方误解需求
人们在交流的时候，经常会发生“答非所问，问非所求”的事情，软件用户与开发人员缺乏有效沟通方法，交流上存在障碍，用户与开发人员存在知识背景差异，都从自己的角度，使用自己的专业术语或语言表达方式来描述和理解问题，使得双方并不能够很好地就软件需求达成共识。2005年北京某公司到我公司做调查，对方技术人员常挂在嘴边的就是“BOM”，但作为用户还没有完全接受这个词，他们用得最多的是流水号、生产线、配套件等。一般说来，用户不太容易从计算机的角度去理解自己的需求问题。从而使需求描述的不一致，不规范，多义性。笔者今年夏季为某事业部编写库房管理软件的时候，笔者采用快速原型化开发了此软件，双方出现了误解的情况，比如：针对“数量”，我理解为整数，但实际上库房数据中“数量”就是以小数为单位，她认为我应该理解了这个问题，实际上她前面输入的数据的确都是整数，使用到一定的程度，结果显示大相径庭。对策：分析人员需要花更多的时间去了解系统用户的特点，多学习用户行业的专业术语，用用户看得懂的语言来表达需求的内容。其次，分析人员除了需要过硬的专业知识，还要具备较强的沟通交流能力。谦虚、诚恳地向用户学习，才能探索出用户的真正需求。如果能在用户方找到即对生产过程了解，又懂计算机知识的行家来为开发人员与用户牵线架桥则是最好不过的事情。
问题三：用户的需求不断变更
由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，随着客户对项目的越来越深刻的理解，对他过去提出的需求要求一变再变，面对这种情况：需求人员要意识，做软件就像装修房子，永远可以找到需要增加的东西、需要改变的
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
