2013系统需求分析规格说明书格式.docVIP

系统需求分析规格说明书 变更记录 序号 变更内容 提出人 修改人 修改日期 版本 目录 一、 前言 4 §1. 目的 4 §2. 背景 4 §3. 范围 4 §4. 术语 4 二、 概述 4 §1. 假定 4 §2. 约束 4 §3. 主要功能 5 三、 用例 5 §1. 用例一 5 §2. 用例二 6 §3. …… 6 四、 报表与查询 6 五、 非功能需求 6 六、 规则 6 七、 数据字典 7 八、 待定 7  前言 目的 【开发本系统的主要目的。注意措辞既不要假大空，也不要表现太多细节。】 背景 【本系统所牵涉的业务当前的处理方法，所遇到的困难或所希望的收益】 范围 【在《范围》中需要明确描述本系统的边界，本系统的一切开发活动都限制在这些范围中。】 术语 【本文档使用的术语。既可能是来自业务上的，也可能是来自IT的。只要是有可能让阅读者费解或误解的词语，都应该在《术语》中解释。】 概述 假定 【本系统开发或使用过程中一些必需满足的条件，有时需要指出如果某条件不成立时会引起什么后果。有些可能会引起双方理解分歧的需求也需要在此明确，例如，调研时用户指出不需要记录录入人，而系统处理的数据又对用户访问权限敏感，那可能需要在《假定》中明确指出“不需要按所属用户对每条记录进行权限控制”】 约束 【系统开发应该满足的约束条件，如性能、时间、成本等，这与需求不同，如果不能满足这些条件系统可能就无法开发或开发出来也不值得；系统不能完成的功能（特别是那些用户可能认为可以做但实际上系统却不能做的事情）也可以这此写明】 主要功能 【对本系统实现的功能作简要描述，让阅读者可以根据这些描述快速了解本系统的功能概貌。】 用例 【《用例》是需求分析文档中最重要的章节。用例强调用户与系统的交互，是一种记录用户需求的工具。】 【“用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。一个用例是多个不同场景的集合。”——《编写有效用例》】 用例一 用例编号 【参见需求编号规则】 用例级别 【包括三种级别：概要级、用户级、子功能级。用户级用例是用户可以直接使用的用例，往往对应一个窗体或命令,例如“按生产单入库”；概要级用例级别高于用户级，从系统性的角度描述了用户的需求，一般包括若干用户级用例的联合操作，例如“库存出入库”；子功能级用例级别低于用户级，用户不会直接使用子功能级用例，子功能级用例可能被若干用户级用例调用。】 功能概述 【对本用例的功能进行概括描述，力求用精炼的语言让阅读者在较短时间内大致了解本用例的功能】 用户 【谁是使用本用例的人，不得使用个人姓名，可使用岗位等】 触发条件 【什么情况会导致本用例运行】 主场景 步骤一 步骤二 …… 【主场景中描写主要操作步骤，最后的结果应该是用例运行成功。通过主场景的描述，可以让阅读者了解用例执行的主流程。主场景中只描述一种本用例中最常用的能执行成功的流程，不包括流程分支。句型推荐使用主谓宾结构；每一句都必需有主语，主语一般包括“用户”、“系统”（指本用例所在的软件系统）、“XX系统”（其他软件系统）；句子需要精炼，尽量避免使用复合句。 如果打印报表或查询，需要另外提供报表或查询的格式，格式参见《港联公司IT部报表需求说明书模板》，并在此注明“报表格式见《XX报表需求说明书》”。】 扩展场景 【当主场景中某一步骤可能有分支流程时，需要在扩展场景中描述，一般使用这种句型：“第X步，如果……，那么……”】 前置条件 【只有前置条件满足时，才允许本用例运行】 后置条件 【用例执行成功会怎么样，用例执行失败会怎么样】 特殊要求 【用户的一些特别需求点往往在这里描述，句子一般包括情态动词，如“可以”、“能够”、“应该”、“必须”等。如“显示出来的库存物料清单应该按第3键排序”，“编号规则必须符合业务规则一”。】 关联系统 【本用例会使用其它什么系统的什么信息。如“TIM系统。使用其中的库存结存数量”】 用例二 …… 报表与查询 【各种报表及查询需求，这里只要列出清单及主要功能，具体格式及生成方式等在文档《报表需求说明书》中描述。】 非功能需求 【程序性能等方面的需求，如响应速度、磁盘空间等。】 规则 规则一 规则二 …… 【本系统在开发中所使用到的各种业务规则。】 数据字典 数据集 数据项（字段） 英