IPD管理流程-系统功能需求说明书模板.docVIP

第PAGE2页, 共 NUMPAGES \* Arabic 15页 产品名称 密级 机密 产品版本 共 NUMPAGES 16页 XX系统YY功能需求说明书 目 录 TOC \o 1-3 \h \z 1 简介 4 1.1 背景 4 1.2 假设和约束 4 1.3 待确定问题 4 2 需求概述 4 2.1 需求之间的依赖和联系（可选） 4 2.2 应用场景 4 2.3 概要层用例（可选） 4 2.3.1 XX功能需求（含编写建议的模板、用例格式：动词+名词） 5 2.3.2 XX功能需求（含编写建议的模板、非用例格式） 10 2.3.3 XX功能需求（无编写建议的模板、用例格式：动词+名词） 11 2.3.4 XX功能需求（无编写建议的模板、非用例格式） 11 3 用户目标层用例 11 3.1 XX功能需求（无编写建议的模板、用例格式：动词+名词） 11 3.2 XX功能需求（无编写建议的模板、非用例格式） 12 4 子功能层用例（可选） 12 4.1 XX功能需求（无编写建议的模板、用例格式：动词+名词） 12 4.2 XX功能需求（无编写建议的模板、非用例格式） 12 5 非功能需求 12 6 备注和附录 12  表目录 TOC \t Table Description \c 表1 样表：用户角色定义 6 图目录 TOC \t Figure Description \c 错误！未找到图形项目表。关键词： 摘要： 缩略语清单： 缩略语 英文全名 中文解释 简介 背景 写作说明：本文档默认使用的Word格式是“正文缩进”。作者在写作文档主体时，请在菜单“样式和格式”中选择“正文缩进”样式。其它需要用到的表格、图、编号、列表等也已经预定义了样式，请尽量使用已有样式，不要自定义样式。 一个系统通常有多篇系统需求说明书。对于功能需求，写作为多篇文档：将分类到同一功能域或功能的所有功能需求写作在一篇功能需求说明书中，使用本模板。例如“XX产品计费功能需求说明书”、“XX产品话统功能需求说明书”。 功能需求的质量属性与此功能需求一起描述，不写作独立的章节。与本类需求整体相关的非功能需求，写作为独立的章节，即本文档的“非功能需求”章节。 对于其他没有必要独立交付的系统需求，合并成一篇系统需求说明书，使用“系统需求说明书模板”，不在本文档中描述。 本章节简要描述待开发系统的背景、希望完成的任务/目标，范围。 假设和约束 本章节罗列假设和约束，包括环境特征用户特征、软硬件约束、遵守的标准、已知的问题等。 待确定问题 本章节描述待确定的问题，包括问题影响范围、风险、责任人、计划解决日期、当前状态等。 需求概述 需求之间的依赖和联系（可选） 本章节描述多个需求之间的依赖和联系，包括本类需求内部和本类需求与它组需求的联系。 应用场景 本章节描述本类需求的应用场景，解释说明用户在什么情况下使用本类需求。如果待开发系统对外交互较多，建议分成多个场景描述，如正常运行场景、管理场景、维护场景、备份场景、升级场景等。 概要层用例（可选） 大多数功能需求都具有较多步骤、而且这些步骤之间有逻辑顺序联系，建议使用下面的用例格式描述这一类需求。而对于简单的的功能需求、人机交互界面功能需求、没有明显的系统交互行为的功能需求、适合表格/公式表达的功能需求，建议不使用用例格式进行描述，以非用例格式为模板写作。 本章节描述概要层用例，概要层用例包含的所有需求都已经体现在用户目标层用例中，所以可以不进行需求跟踪。 任何一个用例，都属于下面的三个层次之一：概要、用户目标、子功能。 1. 概要层：可能由多个主执行者，在多个地点，较长时间段内进行。通常由多个用户目标层的用例组成。概要层用例为用户目标层用例提供上下文。 2. 用户目标层：完成了主执行者某个特定的价值目标，通常由一个主执行者在一个位置，较短时间段内进行。特别说明，用例中的主执行者不仅仅包括人，也包括与系统交互的任何东西。 3. 子功能层：完成了用户目标层的部分细节。 写作概要层用例的目的是将多个相关用户目标层的用例组织起来，提供高层的理解。写作子功能层用例的目的是为了隐藏细节，在用户目标层的用例中突出主体。用户目标层的用例是功能需求文档的主体。在用户目标层的用例已经表达的足够清楚的情况下，不需要写作概要层或子功能层的用例。写作概要层用例和子功能层用例的目的是支撑用户目标层用例。 每一个用户目标层用例都必须是一个功能需求。概要层用例和子功能层用例可以不作为功能需求，在文档中只是为了更好的理解功能需求而存在。当然，将概要层用例和子功能层用例作为功能需求也是允许的，特别是概要层用