软件开发需求说明书模板.docx
- 文档编号:11253116
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:40
- 大小:70.42KB
软件开发需求说明书模板.docx
《软件开发需求说明书模板.docx》由会员分享,可在线阅读,更多相关《软件开发需求说明书模板.docx(40页珍藏版)》请在冰豆网上搜索。
软件开发需求说明书模板
XX软件需求说明书
技术文件名称:
技术文件编号:
<小四Arial及宋体>
版本:
<小四Arial及宋体Vm.n>
共页
(包括封面)
拟制
审核
会签
标准化
批准
【模板使用说明:
(1)模板内容供参考,可以根据实际情况删除或增加二级和三级标题要求的内容,但不能删除一级标题。
(2)对于模板中涉及数据的分析和统计,建议使用表格和图形表示,使数据更清晰直观。
(3)模板中有关流程图的绘制请使用VISIO。
(4)本文档编制请使用MicrosoftOffice2007。
(5)表的编号写在表的上面并居中位置,根据章编号,例:
表1.1(第1章中的第1个表格)。
表格转页时应有表头。
表的编号和名称用五号黑体。
表的编号需在正文中提到。
(6)图的编号写在图的下方并居中位置,根据章编号,例:
图3.4(第3章中的第4个图)。
图的编号和名称用五号黑体,图的编号需在正文中提到。
(7)术语中文名称、英文对应词均用五号黑体,中间空一个字,英文首字母大写,其它用小写,定义用五号宋体。
英文缩略语或其它特殊格式请咨询标准化人员。
(8)在编辑完整个文档后,点击鼠标右键,选择“更新域——更新整个目录”即可。
(9)请在完成整个文档的编写后,将模板中给出的说明删除,正式发布前应当接受对文档所做的全部修订。
】
修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
(写要点即可)
<
Vm.n
XXX
2015/05/06
XXX
XXXX>
注1:
每次更改归档文件(指归档到中研院或公司档案室的文件)时,需填写此表。
注2:
文件第一次归档时,“更改理由”、“主要更改内容”栏写“无”。
目录
1引言1
1.1编写目的1
1.2预期的读者和阅读建议1
1.3文档约定1
2术语、定义和缩略语1
2.1术语、定义1
2.2缩略语2
3综合描述2
3.1背景2
3.2软件概述3
3.3运行环境3
4具体需求1
4.1功能需求1
4.1.1<需求组1标识+两个空格+需求组1名称>3
4.1.1.1<需求组1标识-01+两个空格+需求组1的第1条子需求名称>3
4.1.1.2<需求组1标识-02+两个空格+需求组1的第2条子需求名称>6
4.1.2<需求编号2+两个空格+需求名称2(IPO例)>6
4.2外部接口需求7
4.3性能需求7
4.4质量属性需求8
4.4.1可靠性10
4.4.2安全性11
4.4.3可维护性11
4.4.4可移植性11
4.4.5扩展性12
4.4.6可测试性12
4.5其它需求13
4.5.1通用化、系列化、模块化需求13
4.5.2设计和实现上的限制14
4.5.3执行标准15
4.5.4国际化需求15
4.5.5杂类需求16
5参考文献16
引言
编写目的
本文通过详细描述
预期的读者和阅读建议
预期的读者和阅读建议参见表1.1。
表1.1
读者分类
阅读重点
备注
<项目经理
全文,并据此编制/修订项目(软件)开发计划等。
设计与开发工程师
需求的完整性、正确性、可行性、优先级、无二义性,为概要设计作准备。
售前、售后工程师/用户代表
需求的必要性、优先级,并据此准备市场资料。
测试工程师
需求的可验证性,并据此准备(软件)系统测试方案。
文档工程师
全文,为编写用户文档作准备。
>
文档约定
<本节描述编写文档时所采用的排版约定(如正文风格、重要符号),说明需求优先级的取值及其含义等。
应将每一类内容用一段或若干段进行描述,即应避免在一段中描述所有这些内容。
>
术语、定义和缩略语
<本节描述本文使用到的术语、定义和缩略语。
应尽可能早地在项目的早期就开始编写独立的、产品/项目通用的术语、定义与缩略语,其它文档直接引用该文档中的内容(而不是重新定义),以保持理解的正确性与一致性,避免冗余和误解。
对于那些专用的术语、定义和缩略语,则应放在使用这些内容的文档中描述。
>
术语、定义
本文使用的专用术语、定义见表2.1,通用术语、定义见<文件编号>《
表2.1
术语/定义
英文对应词
含义
<需求
requirement
指“被描述系统(SuD,SystemUnderDescription)“做什么”(功能需求)及“做什么”时的水平(非功能需求,如性能需求、质量属性需求、外部接口需求、其它需求)。
这个通俗定义是针对技术需求的,而非技术需求(如进度的限制)一般不在本文档中给出(一般放在研制任务书/项目计划中)。
>
缩略语
本文使用的专用缩略语见表2.2,通用缩略语见<文件编号>《
缩略语已按其第1个字母顺序排列。
<注意:
缩略语应按其第一个字母顺序排列>
表2.2
缩略语
英文原文
中文含义
RawRequirement 原始需求 UR UserRequirement 用户需求 > 综合描述 背景 <说明: 一般说来,SRS中应有项目范围的描述,而项目范围一般通过项目视图来体现。 我司不管哪种类型的项目,总要首先编写《研制任务书》,将项目视图、范围写在《研制任务书》中是最合适的。 因此,SRS中不反映这部分内容。 > <本节主要描述以下内容: a)项目的背景和起源。 对于在老版本之上升级的系统,则还应说明: 1)老版本出现的主要问题; 2)新版本需要增加或改进的主要内容。 此段内容可能来自于可行性研究报告等上游相关文档。 应该对相关内容进行概括而不是照抄。 b)本产品在整个系统或整个环境中的位置。 应使用上下文图(contextdiagram)或其它形式的图说明本产品(必须用文字及不同的颜色明确标识出来)与外界(可能包括整个系统外的实体)之间的联系,如图3.1。 图形应能清晰地表达产品与外部环境的边界,及产品与外部环境的关系,以帮助读者更好、更快地理解被描述的系统。 实践中经常犯的错误是 1)不画图; 2)画了产品内部组成图、协议栈或软件结构图(关于最后一点,正确的做法是: 应将软件结构图以SuD为中心,转化为上下文图,即去掉各个外部系统之间的联系,当然,各个外部系统与SuD的联系还得保留); 2)在上下文图中,还描述了外部系统之间关系。 图3.1“化学制品跟踪系统”上下文图 > 软件概述 <本节概述软件所具有的主要功能、性能指标、质量属性、外部接口等。 由于其详细内容将在“具体需求”中描述,因此此处需要以较高的层次(如需求组)对需求进行概括性的总结,直接罗列“4.1功能需求”中的所有需求(如用一个表格)并不是一个好主意,因为这会引起内容冗余以致引起维护问题,还会增大文档篇幅。 可以使用图形表示主要的需求组以及它们之间的关系。 本节示例中的规划大师PlanMaster(V2)共有上百个比较重要的功能,但在进行功能概述时只在功能组这一级罗列(只有8行),任何具体功能都可归结到这8个功能组中,因此满足了覆盖具体需求的要求。 同样,用户需求也未游离于这8个功能组之外,因此也覆盖了其上游文档《用户需求论证说明》(规划大师是纯软件项目)。 > 运行环境 <本节描述软件的运行环境,包括硬件环境、操作系统及其版本,还有其它的软件组件或与其共存的应用程序。 如果有版本配合要求、补丁要求,则应明确列出(如使用Windows98,则Office可以使用97及其以上版本,如使用Windows2000,则应打上SP2,且Office只能使用2000版本且应打上SP1)。 如不存在某项,则填写“无”,不要留白。 如果对开发环境有要求,可以写在“4.5.2.设计与实现的限制”一节中。 > 运行环境见表3.2。 表3.2 名称 硬件(CPU/RAM/HD) 操作系统及其版本 其它软件环境 PIII700/1G/18G VxWorksX 无 Xx PIII700/1G/18G VxWorksX 无 Xx PIII700/1G/18G WindowsNT4Server Oracle8i xxServer SPARC/1G/18G SUNSolarisX Oracle8i xxServer SPARC/1G/18G SUNSolarisX Oracle8i> 具体需求 <本章具体描述以下需求: 功能需求、性能需求、质量属性需求、外部接口需求、其它需求(如标准化相关需求、国际化需求等)。 可以采用分组描述(即“父-子需求描述”)的方式描述需求。 由于只有叶节点需求才是重要的,因此,组需求或父需求可以只有名称而没有标识及其它内容(如需求描述、优先级等)。 叶结点需求应该在产品范围内唯一标识。 一般采用分级的标识方式,具体规则为: SR-X-YYYYY-nnnn。 a)半角大写的“SR”为前缀(SR代表软件需求),半角减号“-”为连接符。 nnnn为流水号,具体位数不统一规定,但对于某篇具体的SRS,应为固定值(如固定为4位)。 XXXXX为0到多种分类符(各分类符间以连接符连接)。 如果不存在分类符,则标识规则为: SR-X-nnnn。 X为需求种类标识符,可取F(功能)、P(性能)、Q(质量属性)、I(外部接口)、M(其它需求,如执行标准、设计和实现上的限制、国际化需求等)。 b)需求标识中的流水号不要求连续、顺序。 但为了方便读者阅读,从前到后应尽可能地顺序编号。 c)需求标识中的流水号的最后一位应尽可能为“0”,这样可方便产生新的、顺序的需求标识,以方便读者阅读。 如,已有两个需求标识: SR-F-0010、SR-F-0020,插入新的相关的功能需求时,其标识可以为SR-F-0015。 d)文档基线化后,不允许修改其中使用到的需求标识。 在具体描述需求时,还应注意以下问题: a)如果项目被要求编写数据字典,则应在项目的早期(如项目论证阶段)就应编写数据字典,以定义相关的数据元素和结构(如输入、输出、存储或数据表字段等,一般与功能、内外部接口等相关)的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围。 需求描述中的输入项可以直接引用数据字典的数据项。 数据字典应独立维护。 b)无论是需求标识还是需求内部描述的步骤号,都应手工编号,而不要使用编辑器的自动编号。 因为如果采用自动编号,一旦增加或删除中间的某个编号,将会引起其后所有需求的RP记录的变更,并影响处理过程中的引用关系。 c)需求优先级的设置应基于上游文档(如《用户需求说明书》、《用户需求论证说明》、系统方案)中相关内容的优先级,一般应不比上游的低。 一般情况下,不在本文档中描述需求的实现版本的信息。 最佳的体现需求实现的版本信息的地方有两处: 一是项目计划;二是需求追踪工具RP中的需求属性: 实现版本。 > 功能需求 <功能需求表示了产品的行为,或期望产品能够完成的工作。 这些需求通常是面向动作的,需要重点描述产品与外界的交互。 凡是功能需求,都是可以通过“激励、响应”模型(对应于usecase描述方式)或“输入、处理、输出”模型(对应于IPO描述方式)来描述的。 反之,如果某条需求不能通过这两个模型描述出来,则这条需求不可能是功能需求。 需要强调的是: a)外部接口相关的功能应在此处描述(而不是在“4.4外部接口需求”中描述)。 b)应确认是否有某些容易被忽略的功能,如环境监控相关的(如温度、湿度、烟雾等)、透明传输相关的功能。 应逐一描述每一个具体的功能需求,包括需求标识、需求名称、需求描述、优先级、使用频度等。 可以采用usecase、IPO(输入/处理/输出)、规范化的模型或其它适当的方式进行描述。 规范化的模型,包括实体-关系图、状态转换图、数据流图、对话图等。 本模板要求优先使用usecase文本描述方式,在特殊情况下才可使用IPO等其它方法(如,对于平台类API需求,如果处理流程是顺序的,则使用IPO方法比较有效)。 由于不同的功能需求可能有不同的性能、质量属性等需求,为了避免冗余及阅读方便,在描述功能需求时可在“特殊需求”一栏中同时描述其独有的性能、质量属性等需求。 4.1.1描述了usecase的使用。 4.1.2描述了IPO的使用。 为了能唯一标识、并进而引用功能需求描述中的各子项,我们进行了如表4.1所示的定义。 表4.1 序号 功能需求 描述子项 前缀 编号及格式说明 示例 1 前置条件 C a)使用缩进两格的正文。 b)行首应加编号及两个空格,编号以大写的C(代表条件)引导,编号的位数应相等(即不允许出现C90,C100,可为C0090,C0100),如只有一个条件,也应编号,且应换一行开始条件的描述。 由于不是一般的“列项”,因此无须遵守“凡是列项都应连续编号且对齐”的标准化要求。 建议: 编号以0结尾(如C0090,C0100),这样可方便在C0090后插入C0095。 为了方便,建议编号统一使用5位。 c)前置条件的引用规则: 需求标识+“.”+前置条件编号 C0050XXXX 引用某个前置条件的例子: SR-F-0010.C0050 2 后置条件 R 格式同上。 编号的前缀为大写的R(代表结果) 3 触发条件 T 格式同上。 编号的前缀为大写的T(代表触发) 4 正常过程 N a)接着“正常过程: ”后描述正常过程编号,编号以大写的N(代表正常)引导。 一般只有一个正常过程。 b)过程编号的引用规则: 需求标识+“.”+正常过程编号 正常过程: N1XX 引用正常过程的例子: SR-F-0010.N1 5 正常过程步骤 N a)格式同“前置条件”。 编号的前缀为大写的N b)正常过程、可选过程、异常过程的步骤可以放在一起编号,如N01、A02、E03,也可以独立编号。 c)正常过程步骤的引用规则: 需求标识+“.”+正常过程编号+“.”+正常过程步骤编号 N0010XXXX 引用正常过程步骤的例子: SR-F-0010.N1. N0010 6 可选过程 A a)接着“可选过程: ”后描述可选过程编号,空两格后描述可选过程名称。 编号以大写的A(代表可选)引导,编号的位数可以等于最大位数+1,不足用0补齐 b)过程编号的引用规则: 需求标识+“.”+正常过程编号 可选过程: A1XX 引用可选过程的例子: SR-F-0010.A1 7 可选过程步骤 A 格式同“正常过程步骤”。 编号的前缀为大写的A A0050XXXX 引用可选过程步骤的例子: SR-F-0010.A1. A0050 8 异常过程 E 格式同“可选过程”。 编号的前缀为大写的E 9 异常过程步骤 E 格式同“可选过程步骤”。 编号的前缀为大写的E 10 特殊需求 S 格式同“前置条件”。 编号的前缀为大写的S(代表特殊) 11 输入 I 格式同“前置条件”。 编号的前缀为大写的I(代表输入) 12 输出 O 格式同“前置条件”。 编号的前缀为大写的O(代表输出) 13 处理 P 格式同“前置条件”。 编号的前缀为大写的P(代表处理) > <需求组1标识+两个空格+需求组1名称> <需求组标识不是必须的,可以只有“需求组名称”。 当然,如果有需求组标识则更好,可以从需求标识判断是否是叶节点需求,方便进行需求追踪。 > <需求组1标识-01+两个空格+需求组1的第1条子需求名称> <需求名称应当使用确定性的语句,建议采用动宾结构(如“建立小区”,而不是“小区建立”),应尽可能简短,使得标题能够写在一行。 > 需求描述: <对需求的正常过程、可选过程进行概述,以方便那些不需要知道需求细节的读者。 格式: 直接接在“需求描述: ”后写。 > 执行者: <又叫“参与者”、“角色”。 执行者是指同产品交互的所有事物,包括产品的用户、与产品拥有物理或逻辑连接的其它系统、外部事件(如满足特定日期或时间、满足特殊环境条件如涨潮/落潮、峰谷/峰顶等)。 描述执行者时,应注意: a)执行者一定存在于产品的外部,不可能是产品本身,但可能是产品的一个实例,如控制RNC。 b)执行者一定要在后续的过程描述中出现,否则,要么是此处多写了,要么是过程描述少写了。 实践中,后者占绝大部分: 活动描述中经常只出现“系统”,而没有任何执行者。 没有执行者,怎么能体现“交互”呢? 格式: 直接接在“执行者: ”后写。 > 优先级: <5、4、3、2、1。 具体取值依据请见本模板1.3。 格式: 直接接在“优先级: ”后写。 > 使用频度: <可根据项目的实际情况取值,如“经常”、“偶尔”、“不关心”或“高”、“中”、“低”、“不关心”等。 一般应在1.3中统一定义。 格式: 直接接在“使用频度”后写。 > 前置条件: <只有具备该条件(即前置条件应为真)才可执行该功能,即必要条件。 描述前置条件时,应注意以下问题: a)一般由其它产品或其它需求负责设置前置条件。 b)不能将触发条件当成前置条件。 如“收到XX消息”,正确的前置条件可能是“XX与系统间已经建立XX链路”。 c)不能将应在异常过程中捕获的条件作为前置条件。 如“通信正常”,由于前置条件是必须为真的,因此在实现时无需验证,而“通信正常”则是谁也不能保证的,在实现时需要采用某种机制保证。 格式: 如无需填写,则直接接在“前置条件: ”后写“无”;否则应换行,按正文格式(即行首空两格,换行后顶格): 前置条件编号+两个空格+具体的前置条件。 对于“无”的编写要求,同样适用于“后置条件”、“可选过程”、“异常过程”、“特殊需求”。 > 后置条件: <描述用例执行后状态的改变、输出等。 又叫“请求结果”、“最小保证及成功保证”。 一般只包括正常过程、可选过程的结果,异常过程的结果在异常过程中描述。 通过前置、后置条件可以将功能需求有机地联系起来: 某个功能需求的前置条件是由另一个功能需求通过其后置条件设置的。 事实上,我们在开发用例时,经常可以从某些基本的、常见的功能需求的前置条件中发现更多的用例。 描述后置条件时,应注意以下问题: a)正确理解“状态的改变”、“输出”。 如,“XX与YY间建立了ZZ链路”(注意: 不要画蛇添足地加上“建立了正确的ZZ链路”,因为这样一来,就需要定义“正确”)、“文件被保存”、“系统为客户创建了一个订单,收到付款信息,并将订单请求记入日志”。 b)后置条件一般不为空,因为系统总得处于某个状态。 但如果用例执行前后,系统状态没有变化,则可以没有后置条件。 格式: “后置条件: ”后换行,按正文格式(即行首空两格,换行后顶格书写): 后置条件编号+两个空格+具体的后置条件。 > 正常过程: <当一切运转正常时就得到了正常过程。 没有故障、没有错误。 每一个用例都必须有一个正常过程。 格式为: 正常过程编号+两个空格+正常过程名称。 如果只有一个正常过程,其名称可以省略。 描述正常过程时,应注意以下问题: a)正常过程步骤的第一步,通常是描述用例由于“触发条件”被触发而执行,如“XX(指执行者)收到XX消息,用例开始”。 b)正常过程的最后一步,通常为“用例结束”。 c)过程描述中应出现“执行者”中所列的所有的执行者,否则,要么是本处写错了,要么是“执行者”处少写了。 后者占绝大多数。 d)不要将一个以上的活动放在一个步骤中描述。 如“系统收到XX消息,并检查其是否合法”。 应拆成两个步骤: N0020系统收到XX消息。 XX见《YY数据字典》中的同名数据。 N0030系统确认XX消息是合法的。 e)不应该使用“如果...那么...否则”一类的句式。 要记住,正常过程是没有必要处理分支、异常的! 用户输入数据后,一般应检查其合法性。 关于合法性,正确的描述为: “N0030系统确认数据是合法的。 ”,这样N0040就很自然地沿着正确的路径往下走了。 正常过程步骤的格式为: 正常过程步骤编号+两个空格+正常过程步骤描述。 > 可选过程: <可选过程也可促进功能的成功完成,但它们代表了功能的细节或用于完成功能的途径的变化部分。 一个用例有0到多个可选过程。 格式为: 可选过程编号+两个空格+可选过程名称(XXXX<指正常过程步骤编号>后的分支)。 如,“A1处理网上支付(N1.0070之后)。 ” 描述可选过程步骤时,应注意以下问题: a)可选过程的第一步,一般应描述具体的分支条件。 可以采用类似的句式: “A0010在N1.0070处,如果客户使用网上支付支付货款,则进行以下处理。 ” b)可选过程结束后,一般应回到正常过程的下一步继续执行,但这也不是绝对的,可视情回到正常过程的合适的地方继续执行。 应显式说明这一点。 如: “A0080回到N1.0080处继续执行。 ” c)为了避免阅读困难,在可选过程中可以直接处理条件判断,而无需再编写独立的可选过程。 d)可选过程中的异常,应放在用例的异常过程中统一描述。 可选过程步骤的格式为: 可选过程步骤编号+两个空格+可选过程步骤描述。 > 异常过程: <描述引起功能不能顺利完成的情况。 正常过程、可选过程都会引起异常。 一个用例有0到多个异常过程。 格式为: 异常过程编号+两个空格+异常过程名称(XXXX<指正常/可选过程步骤编号>后的分支)。 如,“E1处理客户输入非法数据。 ” 描述可选过程步骤时,应注意以下问题: a)异常过程的第一步,一般应描述此异常过程对应的出错条件。 可以采用类似的句式: “在N1.0030处,如果客户输入的数据是非法的,则进行以下处理。 ” b)异常过程一般会结束整个用例的执行,但这也不是绝对的,可视情回到正常过程、可选过程的合适的地方继续执行。 应显式说明这一点。 如: “E0050回到N1.0080处继续执行。 ” c)为了避免阅读困难,在异常过程中可以直接处理可选和异常,而无需再编写独立的可选或异常过程。 异常过程步骤的格式为: 异常过程步骤编号+两个空格+异常过程步骤描述。 > 特殊需求: <描述不可见的、或很难在用例中表示的需求,如性能需求、质量属性需求等。 格式: 如无需填写,则直接接在“特殊需求: ”后写“无”;否则应换行,按正文格式(即行首空两格,换行后顶格): 特殊需求标识+两个空格+特殊需求名称。 > <说明: 这里列出的仅是最小要求,模板使用者可以根据实际需要进行扩充。 另外,尽管没有强调,usecase图、合并描述正常、可选、异常过程的流程图也是十分鼓励使用的。 > <需求组1标识-02+两个空格+需求组1的第2条子需求名称> <具体要求与格式同4.1.1.1。 > <需求编号2+两个空格+需求名称2(IPO例)> 需求描述: <需求详细描述。 格式: 直接接在“需求描述: ”后写> 优
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 需求 说明书 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)