附录1-软件业务需求说明书(模板).docVIP

XXX项目业务需求说明书 文件编号： HY/CX-08.02 文件版次： 编写人/日期： 审核人/日期： 批准人/日期： 国网电力科学研究院 北京电研华源电力技术有限公司 文档变更记录 序号 修改条款 修改说明 修改人/日期 批准人/日期 备注 注：对本文档内容增加、删除或修改均需填写此变更记录，详细记载变更信息，以保证其可追溯性。 目 录 1 引言 1 1.1 编写目的 1 1.2 项目风险 1 1.3 预期读者和阅读建议 1 1.4 参考文献 2 2 综合描述 2 2.1 项目背景 3 2.2 业务功能 3 2.3 用户类和特性 4 2.4 运行环境 5 2.5 设计和实现上的限制 5 2.6 假设和约束(依赖) 5 3 业务需求 6 3.1 业务角色 6 3.2 业务实体 7 3.2.1 业务实体图 7 3.2.2 数据字典 7 3.3 业务需求1 7 3.3.1 业务场景 8 3.3.2 业务流程 8 3.3.3 关联 8 3.3.4 表卡单据 9 4 其它非功能需求 9 4.1 性能需求 9 4.2 安全性需求 9 4.3 软件质量属性 10 4.4 用户文档 10 5 外部接口需求 10 6 词汇表 10 7 待定问题列表 11 引言 　　引言是对本文档的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 编写目的 　　说明本文档是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过本文档详尽说明了该软件产品的业务需求，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 　　如果本文档只与整个系统的某一部分有关系，那么只定义软件产品业务需求说明书中说明的那个部分或子系统。 项目风险 　　具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ● 任务提出者； ● 软件开发者； ● 产品使用者。 预期读者和阅读建议 　　列举本文档所针对的各种不同的预期读者，例如，可能包括： ● 用户； ● 开发人员； ● 项目经理； ● 营销人员； ● 测试人员； ● 文档编写入员。 　　并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。 参考文献 　　列举编写本文档时所用到的参考文献及资料，可能包括： ● 本项目的合同书； ● 上级机关有关本项目的批文； ● 本项目已经批准的计划任务书； ● 用户界面风格指导； ● 开发本项目时所要用到的标淮； ● 系统规格需求说明； ● 使用实例文档； ● 属于本项目的其它己发表文件； ● 本软件产品需求分析报告中所引用的文件、资料； ● 相关软件产品需求分析报告； 　　为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出： ● 标题名称； ● 作者或者合同签约者； ● 文件编号或者版本号； ● 发表日期或者签约日期； ● 出版单位或者资料来源。 综合描述 　　这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。 项目背景 　　描述了在本文档中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况： ● 是否是产品系列中的下一成员； ● 是否是成熟产品所改进的下一代产品； ● 是否是现有应用软件的替代品(升级产品)； ● 是否是一个新型的、自主型的产品。 　　如果该软件产品需求分析报告定义的软件系统是： ● 大系统的一个组成部分； ● 与其它系统和其它机构之间存在基本的相互关系。 　　那么必须说明本文档定义的这部分软件是怎样与整个大系统相关联的，或者（同时）说明相互关系的存在形式，并且要定义出两者之间的全部接口。 业务功能 　　因为将在本文档的后面章节中详细描述软件产品的功能，所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利读者理解本软件产品。 　　为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。 参考用户当前管理组织构架，了解各个机构的主要职能，将有助于陈述软件产品的主要功能