需求规格说明书怎么写( 三 ) _说明书

从我们的经验来讲
“需求管理”需要产出的文档大体上包含【需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件】
“需求开发”需要产出的文档大体上包含【需求规格说明书，需求规格说明书检查表，需求开发指南等】
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
4. 监理方如何审核《需求规格说明书》君欲食坚果必先破其壳需求范围控制是需求阶段控制的难点，如果处理不好，会导致业主方与承建方的纠纷，甚至项目没完没了，不能验收。
因为在项目验收时往往以招标文件、投标文件、开发合同、需求成果文档为依据来确定项目是否达到了范围的要求，往往是招投标文件对用户需求范围规定不细，合同没有规定，如果需求成果文档再写的很草，项目到了上线试运行时，业主方会认为所要的功能没有实现，承建方认为用户开始没有提出需求，后来不断改变和新增需求，项目不可控，永远没法验收。为解决这一难题监理方应从中起到重要作用。
建议的做法是：一是控制好软件开发方法利于需求获取：根据项目复杂度、业主方信息化基本情况，选好开发方法，如果复杂度高业主方信息化基础弱可能选用原型法，如果时间紧、承建方经验丰富可选用敏捷法。二是巧妙引导使用《用户需求说明书》，协调、建议业主方和承建方，需求调研时汇总“需求调研表”形成《用户需求说明书》对开发的范围和性能目标需求进行界定，并建议业主方业务部门对其业务需求签字确认，同时约定更的范围比如10%—15%为合理变更范围，如果在这个范围内，承建方应开发和调整不增加费用，如果超出这个范围或对系统架构有较大的变更，业主方要增加费用。
形成会议纪要或备忘录各方遵守。三是以《用户需求说明书》为依据对《需求规格说明书》的开发范围进行检查和审核。
金玉其外秀慧其中要求《需求规格说明书》形式与内容并重，本节主要阐述形式要求和内容的完整性，只有形式与内容都达到要求才认为是合格的《需求规格说明书》。一是形式完美：包括封皮完美、版本控制信息清晰、章节分部合理、文字简练、准确、专业、无冗余、图文并茂等二是内容完整：包括引言（包括目的、范围、阅读对象、参考资料、缩写词、略语、相关法律法规等）；功能需求；非功能需求（包括可靠性、安全性、易用性、可用性、可扩展性、可维护性、可移植性等）；接口需求、约束条件等文档结构合理，其中要求运行环境、操作方式、故障处理、备份需求、反应速度、流量、频度等一应俱全，把握一个原则是：不能缺项。
慧眼点睛更上层楼重点一：把握《需求规格说明书》的三要素是审核的第一关键，首先要了解软件开发中采用结构化方法、面向对象的方法、SOA架构对《需求规格说明书》的影响。《需求规格说明书》除了与用户沟通要用户理解、监理人员作为控制项目的依据、测试人员作为测试依据之外，也是开发设计人员的依据和工作指南，如果开发方法用的是结构化方法，那么《需求规格说明书》中“业务流”、“数据流”、“数据字典”成为其不可缺少的三要素，缺一不可，并且是环环相扣，相互对应，下面分别述之。