育才学习网1. 需求规格说明书包括哪两个部分
三、需求规格说明书
1.引言 1
1.1编写目的 1
1.2项目背景 2
1.3定义 2
1.4参考资料 2
2.任务概述 2
2.1目标 2
2.2运行环境 2
2.3条件与限制 2
3.数据描述 3
3.1静态数据 3
3.2动态数据 3
3.3数据库介绍 3
3.4数据词典 3
3.5数据采集 3
4.功能需求 3
4.1功能划分 3
4.2功能描述 3
5.性能需求 3
5.1数据精确度 3
5.2时间特性 3
5.3适应性 4
6.运行需求 4
6.1用户界面 4
6.2硬件接口 4
6.3软件接口 4
6.4故障处理 4
7.其它需求 4
1.引言
1.1编写目的
【阐明编写需求说明书的目的，指明读者对象。】
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
本文档供项目经理、设计人员、开发人员参考。
1.2项目背景
a. 项目的委托单位、开发单位和主管部门
b. 该软件系统与其他
1.3定义
【列出文当中所用到的专门术语的定义和缩写词的原文。】
1.4参考资料
a. 项目经核准的计划任务书、合同或上级机关的批文
b. 项目开发计划
c. 文档所引用的资料、标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
2.任务概述
2.1目标
2.2运行环境
操作系统：Microsoft Windows 2000 Advanced Server
支持环境：IIS 5.0
数 据 库：Microsoft SQL Server 2000
2.3条件与限制
3.数据描述
3.1静态数据
3.2动态数据
【包括输入数据和输出数据。】
3.3数据库介绍
【给出使用数据库的名称和类型。】
3.4数据词典
3.5数据采集
4.功能需求
4.1功能划分
4.2功能描述
5.性能需求
5.1数据精确度
5.2时间特性
【如响应时间、更新处理时间、数据转换与传输时间、运行时间等。】
5.3适应性
【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时，应具有的适应能力。】
6.运行需求
6.1用户界面
【如屏幕格式、报表格式、菜单格式、输入输出时间等。】
6.2硬件接口
6.3软件接口
6.4故障处理
7.其它需求
【如可使用性、安全保密、可维护性、可移植性等。】
2. 谁会写软件需求规格说明书啊
规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。
2 适用范围
本规范适用于集团开发项目的（软件）《需求说明书》的编写。
3 编写内容提示
1 引言
3.1.1 背景说明
说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。
3.1.2 参考资料
列出有关资料（名称，发表日期，出版单位，作者等）。
3.1.3 术语和缩写词
列出本文件中用到的专门术语的定义，及术语缩写词。
3.2 软件总体概述
3.2.1 目标
软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型
图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束
说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。3.3 详细需求
详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求
对系统中每一个功能，要详细描述（图示或文字）。
概述 叙述功能名称，目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求
定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：
3.3.2.1精度
说明系统的精度要求，如：
数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性
说明系统的时间特性要求，如：
解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性
说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量
包括系统的设计容量和理论（计算）容量。
3.3.3 输入和输出
解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.3.4 数据管理能力
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境
描述所开发软件运行所需的环境。
3.4.1 设备环境
描述运行软件系统所需的设备能力，如：
处理器的型号和内存容量。
存储媒体的数量。
通信网络（包括说明网络结构，线路速度及通讯协议等）。
3.4.2 支持软件环境
列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。
3.4.3 接口
说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他
说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
3. 用户需求说明书 与 需求规格说明书 有什么本质区别
1、用户需求说明书是用户的需求，需要和用户确认的；需求规格说明书是系统需求主要是对内的。你考虑了一个对外一个对内。而且需求管理的时候也需要用到用户需求
2、
优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、这要看你们的项目管理采用的规范。
如果是cmmi就需要，敏捷就取消
4、如果你非要省掉一个的话，我倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。要是用户需求就已经理解错了，软件规格让用户签字好哪里放什么文本框用什么布局有意义么？ 最后还不是给你翻掉
5、一个是给用户看的 ，一个给程序员看的
6、当然需要，需求管理不弄好，后期客户扯皮怎么办？
7、1、用户需求说明书是软件设计的根本，用户需要签字画押，详细设计基于这个写的，怎能不需要。
2、后期有扯皮的时候有依据，不至于什么都没有。
8、这个东西少不得， 做的详细点是对自己负责， 后期意义重大
需求阶段的工作主要分为两个方面，为“需求开发”和“需求管理”。
从我们的经验来讲
“需求管理”需要产出的文档大体上包含【需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件】
“需求开发”需要产出的文档大体上包含【需求规格说明书，需求规格说明书检查表，需求开发指南等】
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
4. 监理方如何审核《需求规格说明书》
君欲食坚果 必先破其壳需求范围控制是需求阶段控制的难点，如果处理不好，会导致业主方与承建方的纠纷，甚至项目没完没了，不能验收。
因为在项目验收时往往以招标文件、投标文件、开发合同、需求成果文档为依据来确定项目是否达到了范围的要求，往往是招投标文件对用户需求范围规定不细，合同没有规定，如果需求成果文档再写的很草，项目到了上线试运行时，业主方会认为所要的功能没有实现，承建方认为用户开始没有提出需求，后来不断改变和新增需求，项目不可控，永远没法验收。为解决这一难题监理方应从中起到重要作用。
建议的做法是：一是控制好软件开发方法利于需求获取：根据项目复杂度、业主方信息化基本情况，选好开发方法，如果复杂度高业主方信息化基础弱可能选用原型法，如果时间紧、承建方经验丰富可选用敏捷法。二是巧妙引导使用《用户需求说明书》，协调、建议业主方和承建方，需求调研时汇总“需求调研表”形成《用户需求说明书》对开发的范围和性能目标需求进行界定，并建议业主方业务部门对其业务需求签字确认，同时约定更的范围比如10%—15%为合理变更范围，如果在这个范围内，承建方应开发和调整不增加费用，如果超出这个范围或对系统架构有较大的变更，业主方要增加费用。
形成会议纪要或备忘录各方遵守。三是以《用户需求说明书》为依据对《需求规格说明书》的开发范围进行检查和审核。
金玉其外 秀慧其中要求《需求规格说明书》形式与内容并重，本节主要阐述形式要求和内容的完整性，只有形式与内容都达到要求才认为是合格的《需求规格说明书》。一是形式完美：包括封皮完美、版本控制信息清晰、章节分部合理、文字简练、准确、专业、无冗余、图文并茂等二是内容完整：包括引言（包括目的、范围、阅读对象、参考资料、缩写词、略语、相关法律法规等）；功能需求；非功能需求（包括可靠性、安全性、易用性、可用性、可扩展性、可维护性、可移植性等）；接口需求、约束条件等文档结构合理，其中要求运行环境、操作方式、故障处理、备份需求、反应速度、流量、频度等一应俱全，把握一个原则是：不能缺项。
慧眼点睛 更上层楼重点一：把握《需求规格说明书》的三要素是审核的第一关键，首先要了解软件开发中采用结构化方法、面向对象的方法、SOA架构对《需求规格说明书》的影响。《需求规格说明书》除了与用户沟通要用户理解、监理人员作为控制项目的依据、测试人员作为测试依据之外，也是开发设计人员的依据和工作指南，如果开发方法用的是结构化方法，那么《需求规格说明书》中“业务流”、“数据流”、“数据字典”成为其不可缺少的三要素，缺一不可，并且是环环相扣，相互对应，下面分别述之。
一是业务流程图：要与用户实际业务一致，要以用户容易理解的、标准的图形清晰表述，如果较复杂就用子图分层的方法表述，以简易和容易理解业务为原则。二是数据流程图：先是与业务流程图一一对应，再是涉及的输入或输出表应明确画出，表划分合理、无冗余。
注意处理好分层时的表达。三是数据字典：实际上是数据流程图中输入、输出表中对应的数据项，需要说明的是要标出数据项要求的类型或字长等属性。
如果是面向对象的方法，由于其迭代和无间隙的特点，需求和设计没有明显的界限，所以在审核《需求规格说明书》时至少要有用例图、顺序图、类图等，所要表述的要把握基本与结构化方法三要素相对等的信息，如果情况复杂时还要有状态图，以下简述之：用例图：能清晰反映出角色和用例，可以对应业务流中的主要功能项，通常用例将转化为程序菜单，主要用于审核检查业务范围。顺序图：审核检查顺序图的粒度，基本上能对应业务流程和数据流程就行了，它是以时间顺序描述流程的，也可以空间顺序的协作图来代替其描述流程。
类图：类图主要是描述数据项，可以将其对应为结构化方法的数据字典，但其更贴近自然，更能适应变化。重点二：把握接口和安全尤为重要，接口和安全是软件开发的重点和难点，处理不好，会给项目埋下定时炸弹，即使回避一时，但矛盾很快会暴露，根据项目实际情况对这两个方向的把握也是监理审核的重点。
啰啰嗦嗦 终要定格 写了这么多最终还是建议完成“关于对《需求规格说明书》的审核”监理报告，以下抛出一砖来，希望引来金凤凰。关于对《需求规格规格说明书》的审核审核报告项目名称XXXX信息管理系统建设项目业主方业主方全称监理方监理方全称承建方承建方全称XX监理公司于XXXX年X月X日对承建方提交的《需求规格说明书》（包括：《OA系统需求规格说明书》、《网站需求规格说明书》、《业务系统需求规格说明书》）进行审核，意见或建议如下：（如果不特指三个系统的某一个，就表示对三个系统共同的评审结果）一、需求目标：《OA系统需求规格说明书》中“需求目标”部分，对系统的性能有较充分的描述，系统的功能描述少，具体要“做什么”在目标中没有很明白的描述。
《网站需求规格说明书》中“需求目标”对功能和性能都有描述。《业务系统需求规格说明书》中“需求目标”。
5. 需求规格说明必须具备哪些条件
需求规格说明是指在一种产品开发之前，消费者希望从该产品中得到的所有需求的最终结果的阐述。
一份有效的规格说明必须满足以下几个条件：完整性，即每一项需求都必须将所要实现的功能描述清楚；正确性，即每一项需求都必须准确地陈述其要开发的功能；可行性，即每一项需求都必须是在一定条件或范围内可以实施的；必要性，即每一项需求都应把真正所需要的和最终所需遵从的标准记录下来；划分优先级，即给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量；无二义性，即对所有需要说明的读者都只能有一个明确统一的解释，即可验证性，即检查每项需求是否能通过设计测试用例或其他的验证方法，保证其客观性。
转载请注明出处育才学习网 » 需求规格说明书怎么写