软件需求说明书模板(软件适用).doc
- 文档编号:30578706
- 上传时间:2023-08-17
- 格式:DOC
- 页数:33
- 大小:1.18MB
软件需求说明书模板(软件适用).doc
《软件需求说明书模板(软件适用).doc》由会员分享,可在线阅读,更多相关《软件需求说明书模板(软件适用).doc(33页珍藏版)》请在冰豆网上搜索。
秘密▲
技术文件
技术文件名称:
技术文件编号:
<小四Arial及宋体>
版本:
<小四Arial及宋体Vm.n>
共[单击键入总页数]页
(包括封面)
拟制[单击此处键入作者]
审核[单击此处键入审核者]
会签[单击此处键入会签者1]
[单击此处键入会签者2]
[单击此处键入会签者3]
[单击此处键入会签者4]
标准化[单击此处键入标准化者]
批准[单击此处键入批准者]
江苏鸿信系统集成公司苏州分公司
本文中的所有信息均为江苏鸿信系统集成公司苏州分公司内部信息,不得向外传播。
【模板使用说明:
(1)模板内容供参考,可以根据实际情况删除或增加二级和三级标题要求的内容,但不能删除一级标题。
(2)对于模板中涉及数据的分析和统计,建议使用表格和图形表示,使数据更清晰直观。
(3)模板中有关流程图的绘制请使用VISIO,要求参见公司的规定。
(4)本文档编制请使用MicrosoftOffice2000。
(5)表的编号写在表的上面并居中位置,根据章编号,例:
表1.1(第1章中的第1个表格)。
表格转页时应有表头。
表的编号和名称用五号黑体。
表的编号需在正文中提到。
(6)图的编号写在图的下方并居中位置,根据章编号,例:
图3.4(第3章中的第4个图)。
图的编号和名称用五号黑体,图的编号需在正文中提到。
(7)术语中文名称、英文对应词均用五号黑体,中间空一个字,英文首字母大写,其它用小写,定义用五号宋体。
英文缩略语或其它特殊格式请咨询标准化人员。
(8)在编辑完整个文档后,点击鼠标右键,选择“更新域——更新整个目录”即可。
(9)在页眉右上角的密级键入文件密级,一般文档最低的密级为秘密,具体产品可以根据实际情况确定为更高的密级,如模板要求为“秘密▲”,可以根据产品的重要程度可以上升为“机密▲”,最高为“绝密▲”。
(10)请在完成整个文档的编写后,将模板中给出的说明删除,正式发布前应当接受对文档所做的全部修订。
】
修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
(写要点即可)
<
Vm.n
XXX
2003/05/06
XXX
XXXX>
注1:
每次更改归档文件(指归档到中研院或公司档案室的文件)时,需填写此表。
注2:
文件第一次归档时,“更改理由”、“主要更改内容”栏写“无”。
目录
1 引言 10
1.1 编写目的 10
1.2 预期的读者和阅读建议 10
1.3 文档约定 10
2 术语、定义和缩略语 11
2.1 术语、定义 11
2.2 缩略语 11
3 综合描述 11
3.1 背景 11
3.2 软件概述 13
3.3 运行环境 14
3.4 用户类及其要求 14
4 具体需求 16
4.1 功能需求 16
4.1.1.1 <需求组1标识-01+两个空格+需求组1的第1条子需求名称> 18
4.1.1.2 <需求组1标识-02+两个空格+需求组1的第2条子需求名称> 24
4.1.2 <需求编号2+两个空格+需求名称2(IPO例)> 24
4.2 性能需求 25
4.2.1 SR-P-0100FTP平均速率 26
4.2.1.1 SR-P-0100-01CS1编码、3时隙捆绑的FTP平均速率 26
4.2.1.2 SR-P-0100-02CS2编码、3时隙捆绑的FTP平均速率 26
4.2.2 SR-P-0102精度需求 26
4.3 质量属性需求 27
4.3.1 可靠性 29
4.3.1.1 SR-Q-0010无缺陷性需求 29
4.3.1.2 SR-Q-0020健壮性需求 29
4.3.1.3 SR-Q-0030可用性需求 29
4.3.1.4 SR-Q-0050平均故障间隔时间MTBF。
29
4.3.1.5 SR-Q-0060平均修复时间MTTR。
30
4.3.1.6 SR-Q-0070异常记录需求 30
4.3.2 安全性 30
4.3.2.1 SR-Q-1030数据一致性需求 30
4.3.2.2 SR-Q-1040反修改需求 30
4.3.3 可维护性 31
4.3.3.1 SR-Q-2010报表维护速度需求 31
4.3.3.2 SR-Q-2020代码可读性需求 31
4.3.4 可移植性 31
4.3.4.1 SR-Q-3010硬件独立性 31
4.3.4.2 SR-Q-3020软件独立性 32
4.3.5 扩展性 32
4.3.6 可测试性 32
4.3.6.1 SR-Q-5010日志输出控制 33
4.3.6.2 SR-Q-5020消息转向 33
4.4 外部接口需求 33
4.5 其它需求 34
4.5.1 通用化、系列化、模块化需求 34
4.5.1.1 SR-M-0020系列化需求 35
4.5.1.2 SR-M-0030模块化需求 35
4.5.2 设计和实现上的限制 35
4.5.2.1 设计和实现上的一般限制 36
4.5.2.1.1 SR-M-1010必须使用的技术。
36
4.5.2.1.2 SR-M-1020必须采用的专利 36
4.5.2.2 FR-M-2010设计和实现上的用户界面限制 37
4.5.3 执行标准 37
4.5.4 国际化需求 39
4.5.4.1 SR-M-3010协议相关的国际化需求 39
4.5.4.2 SR-M-3020语种相关的国际化需求 40
4.5.5 杂类需求 40
5 验收准则 40
6 参考文献 42
24
本文中的所有信息均为江苏鸿信系统集成公司苏州分公司内部信息,不得向外传播。
1引言
1.1编写目的
本文通过详细描述
1.2预期的读者和阅读建议
预期的读者和阅读建议参见表1.1。
表1.1
读者分类
阅读重点
备注
<项目经理
全文,并据此编制/修订项目(软件)开发计划等。
设计与开发工程师
需求的完整性、正确性、可行性、优先级、无二义性,为后续设计作准备。
售前、售后工程师/用户代表
需求的必要性、优先级,并据此准备市场资料。
测试工程师
需求的可验证性,并据此准备(软件)系统测试方案。
文档工程师
全文,为编写用户文档作准备。
>
1.3文档约定
<本节描述编写文档时所采用的排版约定(如正文风格、重要符号),说明需求优先级的取值及其含义等。
应将每一类内容用一段或若干段进行描述,即应避免在一段中描述所有这些内容。
>
<===ExampleBegin====================================================
例文档约定
本文使用了如下的文档约定:
1)表头文字使用了20%灰度背景;
2)插图一律使用MSVisio2002中文版绘制,并一律“嵌入”于需求描述正文中,而非“浮于文字上方”。
;
3)用同号、同体但加粗的文字来强调需要读者重视的内容。
另外,每个需求都有优先级属性。
优先级的可能取值为:
5、4、3、2、1,具体定义如下:
5:
是必须的,它规定了产品的必备需求。
没有这些需求,产品将不能完成用户的工作,从而也就无法达到市场的准入条件。
4:
是重要的,它规定了那些竞争对手已经实现且用户感觉很好的需求、本产品区别于其它同类产品的独特需求及其它一些需求。
只有完成这些需求,才能使本产品有市场竞争力。
3:
是应该的,它规定了当前版本可以不做,但必须在未来版本中实现的需求。
此种需求对产品的体系结构影响可能较大,因此必须在系统设计时予以考虑。
2:
是可能的,它规定了那些有了会更好但没有也没有什么关系的需求,如一些提高效率的小工具。
1:
是备忘的,它规定了我们想象的但目前无法或无需实现的需求。
====ExampleEnd====================================================>
2术语、定义和缩略语
<本节描述本文使用到的术语、定义和缩略语。
应尽可能早地在项目的早期就开始编写独立的、产品/项目通用的术语、定义与缩略语,其它文档直接引用该文档中的内容(而不是重新定义),以保持理解的正确性与一致性,避免冗余和误解。
对于那些专用的术语、定义和缩略语,则应放在使用这些内容的文档中描述。
>
2.1术语、定义
本文使用的专用术语、定义见表2.1。
表2.1
术语/定义
英文对应词
含义
<需求
requirement
指“被描述系统(SuD,SystemUnderDescription)“做什么”(功能需求)及“做什么”时的水平(非功能需求,如性能需求、质量属性需求、外部接口需求、其它需求)。
这个通俗定义是针对技术需求的,而非技术需求(如进度的限制)一般不在本文档中给出(一般放在研制任务书/项目计划中)。
>
2.2缩略语
本文使用的专用缩略语见表2.2。
<注意:
缩略语应按其第一个字母顺序排列>
表2.2
缩略语
英文原文
中文含义
RawRequirement 原始需求 UR UserRequirement 用户需求 > 3综合描述 3.1背景 <说明: 一般说来,SRS中应有项目范围的描述,而项目范围一般通过项目视图来体现。 我司不管哪种类型的项目,总要首先编写《研制任务书》,将项目视图、范围写在《研制任务书》中是最合适的。 因此,SRS中不反映这部分内容。 > <本节主要描述以下内容: a)项目的背景和起源。 对于在老版本之上升级的系统,则还应说明: 1)老版本出现的主要问题; 2)新版本需要增加或改进的主要内容。 此段内容可能来自于可行性研究报告等上游相关文档。 应该对相关内容进行概括而不是照抄。 b)本产品在整个系统或整个环境中的位置。 应使用上下文图(contextdiagram)或其它形式的图说明本产品(必须用文字及不同的颜色明确标识出来)与外界(可能包括整个系统外的实体)之间的联系,如图3.1。 图形应能清晰地表达产品与外部环境的边界,及产品与外部环境的关系,以帮助读者更好、更快地理解被描述的系统。 实践中经常犯的错误是 1)不画图; 2)画了产品内部组成图、协议栈或软件结构图(关于最后一点,正确的做法是: 应将软件结构图以SuD为中心,转化为上下文图,即去掉各个外部系统之间的联系,当然,各个外部系统与SuD的联系还得保留); 2)在上下文图中,还描述了外部系统之间关系。 图3.1“化学制品跟踪系统”上下文图 > <===ExampleBegin==================================================== SRS的背景样例: ====ExampleEnd====================================================> 3.2软件概述 <本节概述软件所具有的主要功能、性能指标、质量属性、外部接口等。 由于其详细内容将在“具体需求”中描述,因此此处需要以较高的层次(如需求组)对需求进行概括性的总结,直接罗列“4.1功能需求”中的所有需求(如用一个表格)并不是一个好主意,因为这会引起内容冗余以致引起维护问题,还会增大文档篇幅。 可以使用图形表示主要的需求组以及它们之间的关系。 本节示例中的规划大师PlanMaster(V2)共有上百个比较重要的功能,但在进行功能概述时只在功能组这一级罗列(只有8行),任何具体功能都可归结到这8个功能组中,因此满足了覆盖具体需求的要求。 同样,用户需求也未游离于这8个功能组之外,因此也覆盖了其上游文档《用户需求论证说明》(规划大师是纯软件项目)。 > 3.3运行环境 <本节描述软件的运行环境,包括硬件环境、操作系统及其版本,还有其它的软件组件或与其共存的应用程序。 如果有版本配合要求、补丁要求,则应明确列出(如使用Windows98,则Office可以使用97及其以上版本,如使用Windows2000,则应打上SP2,且Office只能使用2000版本且应打上SP1)。 如不存在某项,则填写“无”,不要留白。 如果对开发环境有要求,可以写在“4.5.2.设计与实现的限制”一节中。 > 运行环境见表3.2。 表3.2 名称 硬件(CPU/RAM/HD) 操作系统及其版本 其它软件环境 PIII700/1G/18G VxWorksX 无 MMLP PIII700/1G/18G VxWorksX 无 MMSP PIII700/1G/18G WindowsNT4Server Oracle8i DBServer SPARC/1G/18G SUNSolarisX Oracle8i BillServer SPARC/1G/18G SUNSolarisX Oracle8i> 3.4用户类及其要求 <本节描述产品的不同用户类及其特征。 应根据用户使用产品的频度、应用领域和计算机系统知识、需要完成的任务、地理上的布局以及访问优先级等对用户进行分类。 不同的用户类,其需求是不同的,某些用户类的需求可能更加重要,需要优先考虑。 每一个用户类都有自己的一系列功能和非功能需求。 如: 一个没有经验或偶尔使用电脑的用户关心产品是否简单易用,因此,菜单、提示符和向导是很重要的。 然而,对于那些一天使用几小时产品的用户,他们更关心产品的易用性和高效性,所以他们喜欢使用快捷键、宏。 有一些受产品影响的人并不一定是产品的直接使用者,而是通过相关的产品访问本产品的数据和服务。 这些非直接的或次级(secondary)的用户也有自己的需求,可以将这些人加入“附加的用户类”。 用户类不一定都指人,其它与本产品存在接口的产品(及其开发人员)也是比较重要的用户类,对于我司的产品更是如此。 实践中,应尽早为产品确定出用户类及其代表,以广泛、完整地收集需求。 > 4具体需求 <本章具体描述以下需求: 功能需求、性能需求、质量属性需求、外部接口需求、其它需求(如标准化相关需求、国际化需求等)。 可以采用分组描述(即“父-子需求描述”)的方式描述需求。 由于只有叶节点需求才是重要的,因此,组需求或父需求可以只有名称而没有标识及其它内容(如需求描述、优先级等)。 叶结点需求应该在产品范围内唯一标识。 一般采用分级的标识方式,具体规则为: 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中的需求属性: 实现版本。 > 4.1功能需求 <功能需求表示了产品的行为,或期望产品能够完成的工作。 这些需求通常是面向动作的,需要重点描述产品与外界的交互。 凡是功能需求,都是可以通过“激励、响应”模型(对应于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(代表处理) > 4.1.1<需求组1标识+两个空格+需求组1名称> <需求组标识不是必须的,可以只有“需求组名称”。 当然,如果有需求组标识则更好,可以从需求标识判断是否是叶节点需求,方便进行需求追踪。 > 4.1.1.1<需求组1标识-01+两个空格+需求组1的第1条子需求名称> <需求名称应当使用确定性的语句,建议采用动宾结构(如“建立小区”,而不是“小区建立”),应尽可能简短,使得标题能够写在一行。 > 需求描述: <对需求的正常过程、可选过程进行概述,以方便那些不需要知道需求细节的读者。 格式: 直接接在“需求描述: ”后写。 > 执行者: <又叫“参与者”、“角色”。 执行者是指同产品交互的所有事物,包括产品的用户、与产品拥有物理或逻辑连接的其它系统、外部事件(如满足特定日期或时间、满足特殊环境条件如涨潮/落潮、峰谷/峰顶等)。 描述执行者时,应注意: a)执行者一定存在于产品的外部,不可能是产品本身,但可能是产品的一个实例,如控制RNC。 b)执行者一定要在后续的过程描述中出现,否则,要么是此处多写了,要么是过程描述少写了。 实践中,后
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 说明书 模板 适用
![提示](https://static.bdocx.com/images/bang_tan.gif)