《01需求规格说明书模版.doc》由会员分享，可在线阅读，更多相关《01需求规格说明书模版.doc（31页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、（XX子系统）需 求 规 格 说 明 书文件状态： 征求意见稿 正式发布拟制日期文件编号审核日期批准日期版本号 需求规格说明书版 本 历 史版本/状态作者参与者起止日期修改内容签字页单位名称代表人日期（承建单位）（设计单位）（监理单位）（用户单位）（建设单位）（总集成单位）目 录第一章、概述- 1 -1.1总体要求- 1 -1.2文档编写约定- 1 -1.3系统介绍- 2 -1.4系统用户- 2 -1.5任务描述- 2 -1.5.1任务1- 3 -1.5.2任务n- 3 -1.6系统运行环境- 3 -1.6.1系统拓扑结构图- 3 -1.6.2硬件环境要求- 3 -1.6.3软件环境要求- 3
2、 -1.7系统总体设计要求- 4 -1.7.1结构设计要求- 4 -1.7.2硬件设计要求- 5 -1.7.3软件设计要求- 5 -1.7.4其他设计要求- 6 -1.8词汇表- 6 -1.9参考资料- 6 -第二章、功能性需求- 7 -2.1需求一览表- 7 -2.1.1子系统1- 7 -2.1.2子系统N- 8 -2.2模块关系图功能结构图- 9 -2.2.1XXX系统模块关系图- 9 -2.2.2销售系统模块关系图- 10 -2.3关键数据元素描述- 10 -2.3.1关键数据元素流图（DFD）- 11 -2.3.2关键数据状态转移图- 12 -2.4子系统1- 13 -2.4.1功能模
3、块1- 13 -2.4.2功能模块n- 16 -2.5子系统n- 16 -2.5.1功能模块1- 16 -2.5.2功能模块n- 16 -第三章、性能需求- 17 -3.1系统容量要求- 17 -3.2系统响应时间要求- 17 -3.3系统健壮性要求- 17 -第四章、用户界面需求及界面原型- 18 -4.1用户界面设计原则要求- 18 -4.2易用性、易操作性要求- 18 -4.3界面原型- 18 -4.3.1车辆新增- 18 -第五章、安全性需求- 21 -5.1系统安全性需求- 21 -5.2数据安全性需求- 21 -5.3权限需求- 21 -第六章、接口需求- 22 -6.1内部接口需
4、求- 22 -6.2外部接口需求- 22 -第七章、需求可追踪性- 23 -第八章、尚未解决的问题- 24 -第九章、注解- 25 -第十章、附录- 26 -第一章 概述1.1 总体要求（1） 需求规格说明书必须完整、准确描述业务需求及其环境要求（2） 需求规格说明书作为一种契约，界定了系统的范围及内容；（3） 通过该说明书，即使没有软件系统，按其内容而不需其它材料的情况下，手工处理也可实现；（4） 通过培训讲解，软件开发人员、系统测试人员可以依此设计或测试系统，而不需要再去了解业务（5） 子系统、功能模块和功能项的划分（即2.1部分）及其相互关系（即2.2部分）必须清晰、合理（6） 对于功能
5、项，特别是关键业务功能项（即2.X）的流程、输入输出必须清楚、完备；（7） 对于关键数据元素的描述（即2.3部分）必须完备、准确。1.2 文档编写约定l 句子简短完整，具有正确的语法、拼写和标点；l 使用的术语与词汇表（参见 1.7）中所定义的一致；l 需求陈述应该有一致的样式，例如“系统必须.”或者“用户必须.”，并紧跟一个行为动作和可观察的结果；l 避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”；l 避免使用比较性词语，如“提高”，应定量说明提高程度。1.3 系统介绍简单介绍系统的开发背景，系统开发目的，为了解决什么样的问题而开发1.4 系统用户用户类别工作任务相关经验优
6、先级备注用户类别：用户的类别名称，例如，系统管理员、纳税人、税务干部、社会公众、领导干部等。工作任务：该类用户使用系统的哪些功能、完成哪些任务相关经验：该类用户的技术和业务经验水平概述优先级：系统对该类用户的重要性和优先程度。如关键用户、次关键用户、一般用户备注：其它说明1.5 任务描述对于本次系统实现来讲，主要完成哪些任务，分3号标题描述1.5.1 任务11.5.2 任务n1.6 系统运行环境1.6.1 系统拓扑结构图系统运行时的网络环境、各种设备、及其相互连接关系用Visio画出其结构图。1.6.2 硬件环境要求详细列出本系统运行时所必须的最低硬件配置、推荐的硬件配置（主机、显示器、环境设
7、备等）以及其它特殊设备。硬件设备包括：（） 服务器、客户端的配置；（） 安全、存储备份设备；（） 防火墙、UPS等。项目设备名称设备型号特性配置列表1 21.6.3 软件环境要求详细列出本系统运行时所必须（除公司研发以外）的软件，包括外包开发、系统软件、数据库软件等。项目软件名称软件型号特性1 21.7 系统总体设计要求本章的目的在于：从总体上描述产品的设计要求，为结构设计、硬件设计、软件设计等奠定基础。1.7.1 结构设计要求前提：如果没有结构设计工作，则不需要本节。本节的内容：分析外观结构的物理特性需求，为产品的结构设计提供依据。1.7.1.1 相关要求和标准提示：逐个罗列相关的要求（国家
8、法律、政府主管部门有效规定、业主方有效文件、公司相关制度等）和标准（行业标准、国家标准、国际标准），并说明该要求、规范或标准的引用办法（参考、依据）及引用章节。说明：参考指不是强制性要求，引用指必须遵守。1.7.1.2 外观、组装及包装设计要求提示：描述产品的外观、组装、包装等设计要求，举例如下：表面应无明显划痕、变形、锈蚀，应具有防水措施，有明显接地标志；组装上固定零部件不应松动，可动部件（开关、按钮、旋钮、键等）应控制灵活可靠；包装上应有商标、名称、型号、生产厂商、运输要求等信息。1.7.2 硬件设计要求前提：如果没有硬件设计工作，则不需要本节。本节的内容：分析产品的硬件设计需求，为产品的
9、硬件设计提供依据。1.7.2.1 相关要求和标准提示：逐个罗列相关的要求（国家法律、政府主管部门有效规定、业主方有效文件、公司相关制度等）和标准（行业标准、国家标准、国际标准），并说明该要求、规范或标准的引用办法（参考、依据）及引用章节。说明：参考指不是强制性要求，引用指必须遵守。1.7.2.2 硬件设计总体要求提示：描述产品的硬件设计总体要求，如硬件总体结构、主要构成部分性能指标等设计要求。1.7.3 软件设计要求前提：如果是没有软件产品开发部分，则不需要本节。本节的内容：分析软件设计的总体需求，为软件的概要设计提供依据。1.7.3.1 相关要求和标准提示：逐个罗列相关的要求（国家法律、政府
10、主管部门有效规定、业主方有效文件、公司相关制度等）和标准（行业标准、国家标准、国际标准），并说明该要求、规范或标准的引用办法（参考、依据）及引用章节。说明：参考指不是强制性要求，引用指必须遵守。1.7.3.2 软件总体设计要求提示：描述软件的总体设计要求，如结构、性能、安全、可靠性、工具等要求。1.7.4 其他设计要求描述不在以上设计要求之内的其他要求1.8 词汇表相当于名词解释，对文中的缩写、专业术语进行简要阐述1.9 参考资料列出主要参考资料，如需求资料、会议纪要等第二章 功能性需求2.1 需求一览表从粒度从大到小分，需求可以分为子系统(SS：Sub System)、功能模块(FM：Fun
11、ction Module、功能项（FI：Function Item）3个层次。如果系统规模较小，可以省去子系统一级，分为功能模块、功能项两个层次如果功能项还包括若干个子功能项，则在备注中并列列出并解释。此处仅仅列出汇总表格，应对每个子系统用2号标题展开描述2.1.1 子系统12.1.1.1 子系统1需求一览表重要度选用类型：请描述功能重要度区分的方法，详细说明参看表下文字说明功能模块功能项重要度描述功能模块Function A.1功能模块Function B.1重要度：功能重要度分为A/B/C；例如：A级：系统必须具备的功能（类）。B级：适应行业特殊需求的功能（类）。C级：可提高基本功能（类）
12、应用效果的功能（类）。以上分类方法仅仅提供参考，也可以按照功能实施周期、用户对系统的期望值进行划分，视情况而定。按照实施周期区分功能A/B/C：A级：为项目1期系统必须具备的功能（类）。B级：期外围系统接口需要实现的的功能（类）。C级：待完善的扩展功能（类）；按照用户对系统的期望值区分功能A/B/C：A级：为项目必须要求实现的功能（类）。B级：客户期望实现的功能（类）。C级：根据项目实施可实现和可以压缩的需求功能（类）；2.1.1.2 子系统1功能拓扑图用Visio图的方式画出子系统内功能之间、各功能项之间的接口关系、数据流转关系。2.1.2 子系统N2.1.2.1 子系统n需求一览表重要度选
13、用类型：请描述功能重要度区分的方法，详细说明参看表下文字说明功能模块功能项重要度描述功能模块Function A.1功能模块Function B.1重要度：功能重要度分为A/B/C；例如：A级：系统必须具备的功能（类）。B级：适应行业特殊需求的功能（类）。C级：可提高基本功能（类）应用效果的功能（类）。以上分类方法仅仅提供参考，也可以按照功能实施周期、用户对系统的期望值进行划分，视情况而定。按照实施周期区分功能A/B/C：A级：为项目1期系统必须具备的功能（类）。B级：期外围系统接口需要实现的的功能（类）。C级：待完善的扩展功能（类）；按照用户对系统的期望值区分功能A/B/C：A级：为项目必须
14、要求实现的功能（类）。B级：客户期望实现的功能（类）。C级：根据项目实施可实现和可以压缩的需求功能（类）；2.1.2.2 子系统功能拓扑图用Visio图的方式画出子系统内功能之间、各功能项之间的接口关系、数据流转关系。2.2 模块关系图功能结构图用Visio图的方式画出各子系统之间、各功能模块之间、接口关系。并且定义接口编号，描述接口关系。2.2.1 XXX系统模块关系图例子：2.2.2 销售系统模块关系图2.2.2.1 销售系统模块关系图2.2.2.2 销售系统模块接口描述：序号产品A产品B接口模式触发条件约束条件SO00销售订单合同管理双向1 订单参照合同录入传递参数：合同ID反馈参数：合
15、同ID、客户、业务员、销售部门、存货ID、价格、数量、2 合同推式生成订单。2.3 关键数据元素描述功能模块常见的数据元素，如单据编号/ID等公共数据元素序号输入项名称详细含义数据类型数据长度是否为空输入限制备注序号：从1开始的整数输入项名称：汉字描述，如纳税人识别号详细含义：该项的具体表示内容，如纳税人在系统中的唯一标识号数据类型：分字符、整数、浮点数、货币、日期、选择项等输入限制：除数据长度以外的其他限制，如果是必填，必须注明；如果是计算字段，必须注明数据长度：数据项目输入的长度，如日期：8。是否为空：该项表示数据是否必须填写，一般是指：是、否、视情况进行约束。备注：其它说明关键数据元素使
16、用说明：（）该处描述的关键数据元素是常见的处理规则，如果在需求分析过程有的模块出现与上表描述有不一致的，请在该功能处进行另外说明。如：纳税人识别号是否为空的操作，在系统中绝大部分引用关键元素，在其中有一个功能，系统允许输入为空，那么在该功能的输入输出进行描述。（）在功能模块描述关键元素时，只需要引用关键元素的名称，其他项目可以不必输入。2.3.1 关键数据元素流图（DFD）数据流图描述数据逻辑模型，只描述数据流程和处理情况，,用Visio图的方式画出系统关键数据流图一般而言，一个系统中会有多个关键数据流，请分别给出。2.3.1.1 XXX数据元素例子：2.3.1.2 数据元素IC卡医院采用病人
17、持IC卡就医，其中负责管理IC卡的业务包括：发卡、维护、对帐及错误处理、发票打印、病人主索引信息建设和查询、入账结算；发卡管理需要写卡信息：维护是指对卡的查询、修复、初始化、读取；对帐及错误处理：IC卡主记录信息和交易流水帐信息进行核对，发现错误并进行错误处理；发票打印是指打印卡当前发生业务的发票；病人主索引是需要挂号员输入病人信息；入账结算是指当前IC卡操作员对当天发生的业务进行结算。2.3.1.3 关键数据元素流图N2.3.2 关键数据状态转移图数据状态转移图是根据系统分析勾画出关于关键数据在每个子系统的处理流程，通常用于描述关键信息信息在系统内部的流动、转换、存储和处理情况。用Visio
18、图的方式画出系统关键数据状态转移图，参见“状态图绘制规范”。2.3.2.1 关键数据元素状态例子：2.3.2.2 关键数据元素状态IC卡2.3.2.3 关键数据元素状态N2.4 子系统12.4.1 功能模块12.4.1.1 功能项12.4.1.1.1 使用用户哪些用户（用户定义参见1.3）有权限操作该项功能？该用户2.4.1.1.2 功能概述2.4.1.1.3 输入数据项详细描述序号输入项名称详细含义数据类型数据长度是否为空输入限制备注序号：从1开始的整数输入项名称：汉字描述，如纳税人识别号详细含义：该项的具体表示内容，如纳税人在系统中的唯一标识号数据类型：分字符、整数、浮点数、货币、日期、选
19、择项等输入限制：除数据长度以外的其他限制，如果是必填，必须注明；如果是计算字段，必须注明数据长度：数据项目输入的长度，如日期：8。是否为空：该项表示数据是否必须填写，一般是指：是、否、视情况进行约束。备注：其它说明2.4.1.1.4 业务处理流程描述用文字描述加活动图方式描述业务处理流程。对于较简单的情况可只用文字描述。对于较复杂的业务流程，必须用活动图描述，较复杂的情况包括：n 有分支或条件情况较多；n 处理步骤在3步以上；n 牵涉到的用户、模块在两个以上活动图的绘制参见活动图绘制规范2.4.1.1.5 输出结果详细描述序号输出项名称详细含义数据类型备注序号：从1开始的整数输出项名称：汉字描
20、述，如纳税人识别号详细含义：该项的具体表示内容，如纳税人在系统中的唯一标识号数据类型：分字符、整数、浮点数、货币、日期、选择项等备注：其它说明2.4.1.1.6 与其他模块的相关性序号关联模块（或功能项）关系2.4.1.1.7 备注其它说明2.4.1.2 功能项n2.4.2 功能模块n2.5 子系统n2.5.1 功能模块12.5.2 功能模块n第三章 性能需求3.1 系统容量要求系统各类用户数；并发访问的用户数；数据存储的要求3.2 系统响应时间要求3.3 系统健壮性要求第四章 用户界面需求及界面原型4.1 用户界面设计原则要求4.2 易用性、易操作性要求4.3 界面原型按照新规范要求，详细需
21、求规格说明书提交，必须同时完成界面原型的制作；如果本系统界面原型相对较少，那么直接将界面原型的图片粘贴在“界面原型”下，并且对该界面原型进行说明；如果本系统界面原型较多，请另附文件，并进行说明，可采用超链接方式指向该文件。例子：4.3.1 车辆新增4.3.1.1 界面描述页面名称：车辆新增简要描述：对车辆的基本信息和车辆的征费信息进行登记，登记车辆基本信息和车辆征费信息。4.3.1.2 界面元素说明界面字段限制条件说明车辆号牌输入车辆号牌用户自己输入车牌颜色选择条件选择下拉框厂牌型号选择条件选择下拉框车身颜色选择条件选择下拉框车架号码选择条件选择下拉框第五章 安全性需求5.1 系统安全性需求5
22、.2 数据安全性需求5.3 权限需求第六章 接口需求6.1 内部接口需求6.2 外部接口需求外部接口需求，应分别说明：a.用户接口；b.硬件接口；c.软件接口；d.通信接口的需求。第七章 需求可追踪性本章应包括：a.从本规格说明中每个计算机软件配置项的需求到其所涉及的系统(或子系统)需求的可追踪性。(该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述).注：每一层次的系统细化可能导致对更高层次的需求不能直接进行追踪。例如：建立多个计算机软件配置项的系统体系结构设计可能会产生有关计算机软件配置项之间接口的需求，而这些接口需求在系统需求中并没有被覆盖，这样的需求可以被追踪到诸如“系统实
23、现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上。b.从分配到被本规格说明中的计算机软件配置项的每个系统(或子系统)需求到涉及它的计算机软件配置项需求的可追踪性。分配到计算机软件配置项的所有系统(或子系统)需求应加以说明。追踪到接口需求中所包含的计算机软件配置项.第八章 尚未解决的问题如需要，可说明软件需求中的尚未解决的遗留问题。第九章 注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。第十章 附录附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A，B等)编排。- 26 -