XX公司IT项目用户需求确认书v1.0
CMMI-工程-RD-用户需求说明书模板-V1.0-备用
用户需求说明书模板前言客户需求书应从业务角度，用客户熟悉的语言来编写。
目录第一章引言 (1)1.1 编写目的 (1)1.2 项目概述 (1)1.3 组织结构 (1)第二章系统部门设置与人员职责 (2)第三章系统总体规范 (3)3.1 关键计算机资源 (3)3.2 子系统分布 (3)3.3 性能要求 (3)3.4 验收标准 (3)第四章业务流程及功能描述 (4)4.1 业务流程简要描述 (4)4.2 功能具体描述 (4)4.3 信息流向（输入、输出信息描述） (4)4.4 所用单据及报表 (4)第五章其他要求 (4)第一章引言1.1编写目的[阐明编写需求说明书的目的，指明读者对象。
可以用如下的列举方式进行描述。
]例如：1.本文档是[项目名称] [系统属性]客户需求说明书，供需求人员作需求分析时使用。
2.作为项目验收标准之一3.软件维护的参考资料……1.2项目概述[应包括：a.项目的委托单位；b.该软件系统与其他系统的关系；c.项目概述][可以用列举方式进行描述。
]例如：1.项目的委托单位[单位名称]2.比较委托单位原有系统与完整系统结构进行对比等，或进行详细的系统结构概述。
3.针对项目的特色进行基本概要描述……1.3组织结构[利用框图画出委托开发单位的组织结构图]第二章系统部门设置与人员职责[按业务组织结构划分成不同的组或机构，然后分别对每个组或机构进行描述。
描述的内容有：●用户组或机构名称●每个用户组或机构的描述，主要描述它们的职责，及用户组或机构的考核指标。
●每个用户组或机构中相关人员的职责描述，及考核指标。
可以使用下面的格式，也可以根据实际的需要选用其它的格式。
]例如：第三章系统总体规范3.1关键计算机资源[列出系统的软件、硬件环境、设备要求等]3.2子系统分布[列出具体的子系统和独立程序的分布]例如：门店：包括人员系统等3.3性能要求3.4验收标准[说明系统的验收标准]。
第四章业务流程及功能描述[可以运用流程图、文字说明等方式来描述业务流程]4.1业务流程简要描述4.2功能具体描述4.3信息流向（输入、输出信息描述）4.4所用单据及报表注：文档中[ ]里面的内容是对相应部分的说明，在写具体项目的需求说明书时，应去掉或更改为适当的内容第五章其他要求[说明系统其他要求]。
用户需求说明书模板(2)
用户需求说明书模板文档编号：用户需求说明书模板文档信息：公司级别模板文件文档名称：用户需求说明书模板文档类别：工程过程类密级：机密版本信息：1.0建立日期：创建人：审核者：批准人：批准日期：保管人：存放位置：文档修订记录目录1.引言 (4)1.1 编写目的 (4)1.2 范围 (4)1.3 项目背景 (4)1.4 主要业务名词和术语定义 (4)1.5 参考文献* (4)2.需求概述 (5)2.1 用户当前系统* (5)2.1.1 用户当前系统概述 (5)2.1.2 用户当前系统存在的问题 (5)2.2 目标系统 (5)2.2.1 目标系统概述 (5)2.3 与其他系统的关系* (5)2.4 边界定义 (5)2.5 基本业务规则 (5)2.6 系统功能模型概述 (5)2.7 安装或实施目标系统的策略 (6)2.8 目标系统运行环境要求 (6)3.详细需求 (6)3.1 功能名称（需求编号） (6)3.2 功能名称(需求编号) (7)4.主要界面说明 (7)4.1 界面共性说明 (7)4.2 主要界面说明 (7)5.与其他系统的接口说明* (7)6.运行环境 (8)7.性能要求 (8)7.1 运行性能 (8)7.2 可维护性 (8)7.3 可移植性 (8)7.4 故障处理要求 (8)7.5 不允许发生的事件 (8)8.附录 (9)8.1 附件1：业务表单 (9)8.2 附件2 ：字典代码 (9)8.3 附件3 ：外部接口格式 (9)8.4 附件5 ：主要业务流程 (10)8.5 附件6 ：查询信息 (10)8.6 附件7 ：业务单据 (11)8.7 附件8 ：统计报表 (11)1.引言引言部分应包括：1.1编写目的主要说明本文档的作用，除了作为需求规格说明书提供后续设计和测试工作的依据外，如果作为项目验收的依据或有其他特别作用，应特别声明。
1.2范围对于所有受到本文档影响或于影响这个文档的一切进行简明描述。
XX公司IT项目用户需求确认书v1.0
需求确认书工程名称：密级：文档编号：版本信息：创立人：创立日期：审察者：赞同人：赞同日期：北京 xxxx版权所有文档校正记录版本编号或*变化简要说明〔更正内容和变更正赞同者更正记录日期赞同日期*状态更范围〕人人编号*变化状态： A ——增加，M ——更正， D ——删除文档审批信息序号审批人角色审批日期签字备注主要内容1序言 (4)编写目的 (4)背景范围 (4)术语定义 (4)参照资料 (4)2调研情况介绍 (5)3整体需求 (5)系统组成 (5)系统业务流程 (5)4功能需求 (5)需求清单 (5)需求规格 (6)需求综合说明 (6)需求详细定义 (6)5系统接口描述 (7)用户界面 (7)硬件接口 (7)软件接口 (7)通信接口 (8)6非功能需求 (8)性能需求 (8)安全性要求 (8)对软硬件环境的要求 (8)其他需求 (9)7附录 2：需求确认表 (9)1序言1.1 编写目的说明：编写这份需求规格说明书的目的。
1.2 背景范围说明：a.待开发的软件系统的名称；b.本工程的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；c.该软件系统同其他系统或其他机构的根本的相互来往关系。
1.3 术语定义列出本文件中用到的特地术语的定义和外文的首字母组词的原词组。
1.4 参照资料列出用得着的参照资料，如：本工程的经赞同的方案任务书和合同、上级机关的批文；属于本工程的其他已公布的文件；本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、公布日期和初版单位，说明可以获取这些文件资料的本源。
2调研情况介绍序号调研对象调研时间调研内容调研人调研方式调研输出结果其中的调研输出结果可能包括两类文档资料：一是用户的原始资料，如报表样张也许用户的内部资料等；二是经过解析和整理的文件，如调研报告也许会议记录等。
一般把这些资料作为需求规格说明书的附件办理。
3整体需求3.1 系统组成说明整个系统的组成和系统运起色理；归纳每个子系统的功能，并说明子系统之间的关系。
软件需求确认单
工程名称：
文档编号：x
文档名称：
1.《xxxx需求分析》（或需求变更等），版本号：V1.0，文档编号：xxxxxx，总页数：xx页，文件大小：xxx；
2.《xxxx需求分析报告》（如只确认一篇文档，无需编号）。
需求变更控制：
1.系统需求范围以上述需求分析报告为准，不能随意变更。如有变更，必须在受控状态下进行；
2.建设单位或承建单位提出需求变更或功能增加时，须按照三方约定的需求变更控制办法执行，填写“变更控制报告”，明确变更所涉及的相关部分，经三方主管负责人确认；
3.对可能引起系统结构变化或工作量较大的变更，须经三方评审，承建单位不得擅自承诺，否则后果自负；
4.当变更发生频繁时，由三方协商定期提交变更内容；
5.承建单位需在适当的时机将变更部分的内容补充到需求分析报告中；
6.为保证系统稳定、质量可靠，请承建单位遵守此规定及XXX相关文件，并请建设单位积极配合工作。
（以下空白）
业主单位确认：
项目负责人
日 期
承建单位ห้องสมุดไป่ตู้认：
项目经理
日 期
监理机构确认：
总监理工程师/代表
日 期
用户需求说明书模板(3)
顾客需求阐明书模板文档编号：顾客需求阐明书模板文档信息：公司级别模板文献文档名称：顾客需求阐明书模板文档类别：工程过程类密级：机密版本信息：1.0建立日期：创建人：审核者：批准人：批准日期：保管人：寄存位置：目录1.引言 (4)1.1编写目旳 (4)1.2范畴 (4)1.3项目背景 (4)1.4重要业务名词和术语定义 (4)1.5参照文献 * (4)2.需求概述 (4)2.1顾客目前系统 * (4)2.1.1顾客目前系统概述 (4)2.1.2顾客目前系统存在旳问题 (4)2.2目旳系统 (5)2.2.1目旳系统概述 (5)2.3与其他系统旳关系 * (5)2.4边界定义 (5)2.5基本业务规则 (5)2.6系统功能模型概述 (5)2.7安装或实行目旳系统旳方略 (5)2.8目旳系统运营环境规定 (5)3.具体需求 (6)3.1功能名称（需求编号） (6)3.2功能名称(需求编号) (7)4.重要界面阐明 (7)4.1界面共性阐明 (7)4.2重要界面阐明 (7)5.与其他系统旳接口阐明 * (7)6.运营环境 (7)7.性能规定 (7)7.1运营性能 (8)7.2可维护性 (8)7.3可移植性 (8)7.4故障解决规定 (8)7.5不容许发生旳事件 (8)8.附录 (8)8.1附件1：业务表单 (8)8.2附件2 ：字典代码 (9)8.3附件3 ：外部接口格式 (9)8.4附件5 ：重要业务流程 (9)8.5附件6 ：查询信息 (10)8.6附件7 ：业务单据 (10)8.7附件8 ：记录报表 (11)1.引言引言部分应涉及：1.1编写目旳重要阐明本文档旳作用，除了作为需求规格阐明书提供后续设计和测试工作旳根据外，如果作为项目验收旳根据或有其他特别作用，应特别声明。
1.2范畴对于所有受到本文档影响或于影响这个文档旳一切进行简要描述。
1.3项目背景重要阐明项目旳来源，项目所波及领域旳现状，建设该项目旳意义等。
用户需求说明书模板
用户需求说明书模板文档编号：用户需求说明书模板文档信息：公司级别模板文件文档名称：用户需求说明书模板文档类别：工程过程类密级：机密版本信息：1.0建立日期：创建人：审核者：批准人：批准日期：保管人：存放位置：目录1.引言 (4)1.1编写目的 (4)1.2范围 (4)1.3项目背景 (4)1.4主要业务名词和术语定义 (4)1.5参考文献 * (4)2.需求概述 (4)2.1用户当前系统 * (4)2.1.1用户当前系统概述 (4)2.1.2用户当前系统存在的问题 (4)2.2目标系统 (5)2.2.1目标系统概述 (5)2.3与其他系统的关系 * (5)2.4边界定义 (5)2.5基本业务规则 (5)2.6系统功能模型概述 (5)2.7安装或实施目标系统的策略 (5)2.8目标系统运行环境要求 (5)3.详细需求 (6)3.1功能名称（需求编号） (6)3.2功能名称(需求编号) (7)4.主要界面说明 (7)4.1界面共性说明 (7)4.2主要界面说明 (7)5.与其他系统的接口说明 * (7)6.运行环境 (7)7.性能要求 (7)7.1运行性能 (8)7.2可维护性 (8)7.3可移植性 (8)7.4故障处理要求 (8)7.5不允许发生的事件 (8)8.附录 (8)8.1附件1：业务表单 (8)8.2附件2 ：字典代码 (9)8.3附件3 ：外部接口格式 (9)8.4附件5 ：主要业务流程 (9)8.5附件6 ：查询信息 (10)8.6附件7 ：业务单据 (10)8.7附件8 ：统计报表 (11)1.引言引言部分应包括：1.1编写目的主要说明本文档的作用，除了作为需求规格说明书提供后续设计和测试工作的依据外，如果作为项目验收的依据或有其他特别作用，应特别声明。
1.2范围对于所有受到本文档影响或于影响这个文档的一切进行简明描述。
1.3项目背景主要说明项目的来源，项目所涉及领域的现状，建设该项目的意义等。
需求确认书模板
<项目名称> [系统名称]需求确认书（版本号）修改记录目录1 目的 (1)2 任务概述 (1)2.1 目标 (1)2.2运行环境 (1)3 功能需求 (2)3.1功能划分 (2)3.2功能描述 (2)3.2.1 子模块1功能描述 (2)3.2.2 子模块2功能描述 (2)4 性能需求 (2)4.1时间特性 (2)4.2适应性 (2)5 运行需求 (3)5.1用户界面 (3)5.2硬件接口 (3)5.3软件接口 (3)5.4故障处理 (3)6 其它需求 (3)1目的本文档作为项目合同附件供双方确认需求，并指导后续设计开发工作。
2任务概述2.1目标对系统所实现的目标、功能和构架方面做出总体的概括性描述。
2.2运行环境服务器端：操作系统：××支持环境：××数据库：××客户端：操作系统：××适配浏览器：××适配分辨率：××3.1功能划分简述共分为哪几个模块。
3.2功能描述3.2.1 子模块1功能描述模块1功能描述[功能子项1：××子项描述：]3.2.2 子模块2功能描述……4性能需求4.1时间特性【如响应时间、更新处理时间、数据转换与传输时间、运行时间等。
】4.2适应性【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时，应具有的适应能力。
】5.1用户界面【如界面风格、排版要求、报表格式、菜单格式、输入输出时间等。
】5.2硬件接口5.3软件接口5.4故障处理6其它需求【如可使用性、安全保密、可维护性、可移植性等。
】双方确认以上需求正确无误，如需更改需重新商定交付日期，产生金额变动则需重新签订合同。
用户代表签字：公司代表签字：日期：日期：。
客户需求确认书模板
需求描述
营销人员 客户名称 联系人
需求阶段 客户需求：
客户需求确认书
一、基本信息：
申请日期：
时间 客户所属行业 联系方式
二、项目方案
三、项目其他需求 期望完成时间
产品部
研发部
1.需求开发难度 2.开发价值意义 3.风险评估 4.预计需求完成时间 5.是否立项
研发部
营销负责人签字 评估人签字： 评估人签字：
四、项目评估
评估意见
文东国
日期： 评估意见
五、需求评估结果
日期：
是□
否□
硬件部
六、负部
采购部
营销部
总经理
表单说明：该表单由产品部项目经理发起，经各部门和总监和总经理审批，用于项目立项申请。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求确认书
项目名称：
密级：
文档编号：
版本信息：V1.0
创建人：
创建日期：
审核者：
批准人：
批准日期：
北京xxxx有限公司
版权所有
文档修订记录
*变化状态：A——增加，M——修改，D——删除文档审批信息
主要内容
1引言 (4)
1.1编写目的 (4)
1.2背景范围 (4)
1.3术语定义 (4)
1.4参考资料 (4)
2调研情况介绍 (5)
3总体需求 (5)
3.1系统组成 (5)
3.2系统业务流程 (5)
4功能需求 (5)
4.1需求清单 (5)
4.2需求规格 (6)
4.2.1需求综合说明 (6)
4.2.2需求详细定义 (6)
5系统接口描述 (7)
5.1用户界面 (7)
5.2硬件接口 (7)
5.3软件接口 (7)
5.4通信接口 (8)
6非功能需求 (8)
6.1性能需求 (8)
6.2安全性要求 (8)
6.3对软硬件环境的要求 (8)
6.4其它需求 (9)
7附录2：需求确认表 (9)
1引言
1.1编写目的
说明：编写这份需求规格说明书的目的。
1.2背景范围
说明：
a.待开发的软件系统的名称；
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3术语定义
列出本文件中用到的专门术语的定义和外文的首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
本项目的经核准的计划任务书和合同、上级机关的批文；
属于本项目的其他已发表的文件；
本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2调研情况介绍
其中的调研输出结果可能包括两类文档资料：一是用户的原始资料，如报表样张或者用户的内部资料等；二是经过分析和整理的文件，如调研报告或者会议记录等。
一般把这些资料作为需求规格说明书的附件处理。
3总体需求
3.1系统组成
说明整个系统的组成和系统运行机理；概述每个子系统的功能，并说明子系统之间的关系。
3.2系统业务流程
在逻辑工作岗位及职责确定之后，需要进一步归纳用户的业务情况。
每一项业务都由一个或者多个岗位的人按照一定顺序来完成，可以采用业务流程图来描述每一项业务。
4功能需求
功能需求是描述一个产品或项目该做什么，该提供什么功能，该完成什么任务的总结、是整个需求规格说明书的核心。
对于功能需求的描述，通常要求下列内容：
4.1需求清单
采用列表形式列举产品的所有需求，每个需求均需标识，并需要确定每个功能的优先级，如
可能还应估计每个功能项所需开发时间（包括设计和编码时间）。
标识号采用层次化命名。
需求优先级建议分为1、2、3级，其中1级为最高级，表示必须实现的功能。
功能清单可以采用下面的表格表示：
4.2需求规格
编写需求规范之前应该先制定与当前开发的项目/产品相适用的模板，然后根据这个模板来对需求清单中的所有功能进行描述。
可以包含下列内容：
4.2.1需求综合说明
包含下列内容：
（1）使用者的逻辑岗位。
（2）业务背景。
即使用者在什么情况下使用该功能。
（3）业务规则。
比如算法
（4）后续描述中用到的术语解释
4.2.2需求详细定义
本部分的描述步骤如下：
（1）分析当前需求需要的用户界面。
一些功能可能需要多个用户界面；还有一些需求虽然都在一个用户界面中，但界面过于复杂，象这种情况需要拆分为几部分，每部分单独描述。
建议给每个界面（或者界面的一部分）按照一定规则编号。
（2）针对每个用户界面需要说明下列内容：
a)界面完成功能简介
b)界面数据描述。
对界面中的所有数据项详细定义，一般需要包含下列内容：数据项
名称、数据项说明、数据类型及限制规则、数据来源、缺省值等。
c)界面操作描述。
对界面中所有可能的用户操作详细定义，一般需要包含下列内容：
操作项名称、操作过程描述、操作过程中隐含的系统处理、操作的限制条件（即什
么情况下该操作失效）等。
5系统接口描述
规定应用程序必须支持的接口/界面。
它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口/界面需求开发并检验软件。
（仅指外部接口）
5.1用户界面
说明软件将实现的用户界面。
5.2硬件接口
指出软件所支持的所有硬件接口。
5.3软件接口
此节说明软件系统中与其他构件之间的软件接口。
这些构件可以是购入的构件、取自其他应用程序重新利用的构件。
5.4通信接口
说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。
6非功能需求
6.1性能需求
需要对软件静态和动态两个方面的性能作出定量规定。
可能包含如下内容：
●所支持的并发用户数。
●容错要求, 如异常操作后应如何处理，如编制预算过程中突然中断时应能自动恢复或保护上
一次编制状态。
●数据的处理能力要求，如可处理的文件和记录数,表及文件的大小规模, 数据增长情况。
●对数据存储的空间的要求。
●正常或极端情况下，对用户操作响应速度的要求。
6.2安全性要求
6.3对软硬件环境的要求
6.4其它需求
如：美化界面等；
7附录2：需求确认表
本需求文档建立在双方对需求的共同理解基础之上，是后续的开发的依据，是用户验收的依据。
经甲乙双方确认签字后，最终确定。
如果需求发生变化，请提出正式书面要求，并且双方协商成本、资源和进度等。