01系统需求规格说明书模板.docx

《01系统需求规格说明书模板.docx》由会员分享，可在线阅读，更多相关《01系统需求规格说明书模板.docx（16页珍藏版）》请在第一文库网上搜索。

1、文件编号项目编号-R1XXX文件版/次xx（请更新）生效日期请填写生效日期总页数3（请更新）模板编号模板版/次0.1靖锭人产品名称软件需求规格说明书留意.运用时清细致阅读蓝色斜梯提示部分,文档完成后请删除蓝色斜体部分,删除后请留意文档的格式。编写：本文档模板为双面打印设计,请采纳双面打印请爱护环境，留意纸张的回收利用版权信息本文件的版权属于XXXXXX有限公司，任何形式的散发都必需先得到XXXXXX有限公司的许可。以下标示属于XXXXXX有限公司的商标：COPYRIGHT2000-2023正文书目（请自己更新自动书目）1 修改说明72 项目概述82.1 项目背景82.2 项目愿景82.3 项目

2、目标82.4 项目干系人82.5 约束条件8需求限制条件8设计的约束8开发进度要求82.6 相关事实83 相关业务说明93.1 组织结构及职责说明93.2 功能框架图93.3 业务详述9业务目标9业务描述9业务用例9业务流程9功能描述9界面设计93.4 业务实体说明9业务实体图9业务实体属性93.5 系统边界103.6 待解决的问题113.7 业务解决方案114 用例具体描述124.1 用例模型概述124.2 用例清单124.3 用例具体描述125 非功能性需求155.1 系统接口需求15用户界面15硬件接口15软件接口15通讯接口155.2 系统性能需求155.3 系统平安性155.4 牢靠

3、性需求155.5 可维护性需求165.6 可移植性需求165.7 数据存储需求165.8 数据转入说明166 产品组件需求列表167 附件167.1 业务术语167.2 参考资料167.3 需求承诺16图表书目（请自己更新自动书目）文档正本每一章节请从奇数页起先1修改说明日期版本号修改摘要作者修改说明作为文档的正式章节,须要持续、良好的跟踪2项目概述2.1 项目背景(1)项目名称：安排开发的软件产品名称。(2)有关的项目状况。2.2 项目愿景2.3 项目目标对系统的目标作简要描述。2.4 项目干系人列举系统的顾客,系统的主要运用者、其他项目干系人,只要有可能,就给出他们的姓名和联系方法。2.5

4、 约束条件2.5.1 需求限制条件例如:系统将运行在Windows2000Professiona1之上。系统将与SCADA系统接口。2.5.2 设计的约束此节应列出所构建系统的全部设计约束。设计约束代表已经批准并必需遵循的设计确定,其中包括软件语言、软件标准、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。2.5.3 开发进度要求描述系统的建设进度要求。2.6 相关事实一些外部因素,它们对产品产生影响,但不属于规格说明书的其他部分。相关事实提示开发者一些需求要考虑的状况和因素。例如:杆式变压器常规每隔5年进行一次大修。3相关业务说明3.1 组织结构及职责说明用组织结构图说

5、明业务覆盖的组织及部门可以是整个组织,也可以是组织的一部分是须要改进的业务单元3.2 功能框架图3.3 业务详述3.3.1 业务目标把业务看成对外供应价值的价值流，分解识别多个业务目标,例如依据公司发展战略,加强公司发展规划的基础工作,制订公司的中长期发展规划和上海市电力发展规划（包括电网发展和电源发展规划）,为公司发展供应有力保障3.3.2 业务描述3.3.3 业务用例识别业务用例,描述业务用例的目标3.3.4 业务流程这个部分的内容特别关键,须要具体说明,是业务说明的核心内容这个业务目标下,识别业务执行者,即在业务之外和业务进行交互的人或组织;识别业务工人,业务实体统一运用Powerdis

6、igner工具建立业务活动图业务活动图可以业务实例说明3.3.5 功能描述33.6 界面设计33.7 务实体说明统一运用POWerd屈gn”工具绘制实体图,建立实体类及类之间的关系一般状况下依据业务分类或者业务主题建立多个业务实体类图,每张类图具有多个业务实体及实体间关系的描述对于每张业务实体类图,都须要附有对业务实体的说明,及对其关键属性的描述。33.7.1 务实体图33.7.2 务实体属性格式如下:实体名称1：说明:屈性为称示例备注说明示例如下:实体1：营销工程寿;不.皇jis。属性名称示例释义工程帐号3132I060A2工程帐号为该工程在SAP系统中的唯一身份号码,由SAP系统产生前四位

7、3132表示了该营销工程的类型,例为代工工程电压等级IOkV工程电压等级是指电压等级有如下三种:380V10kV35kV市东配套批复金额40万元单位（万元）OO0O。期限合同日期2006年10月H日期限合同日期为供电单位对用户承诺的工程完工后的送电日期,这一日期会在供电公司与客户签订的供电合同中说明33.8 统边界运用一个上下文范围图来描述要探讨的工作的边界,这个图展示了工作和它四周的相邻系统。（示例图待扩展）依据前文的业务说明,依据某个业务目标的活动、业务用例、业务执行者、业务工人等,建立业务用例与系统用例的对应,以此来说明系统的范围。本系统与外围系统的关系本系统为那些用户供应哪些功能33.

8、9 解决的问题描述现有业务活动中存在的问题,客户的困惑,或者客户急需想变更的现状。33.10 解决方案说明清晰实施完成后和实施前的区分这个部分特别重要,是业务如何演化为系统的说明业务解决方案在售前方案中一般会有描述,可参照售前方案中的业务解决方案,描述在项目需求阶段调整或者变更的业务解决方案内容。4用例具体描述4.1 用例模型概述运用用例包图概述产品的功能结构。4.2 用例清单格式如下:用例包次级包用例编号用例名称优先级别优先级别说明:该优先级指考虑系统目标，需重点、优先实现的用例共定义三级:5：表示其为系统核心功能用例,无论从用例说明还是系统实现角度,都须要重点对待3：表示其为系统主要功能用

9、例,1：表示其为系统一般功能用例,一些通用用例,如系统管理、系统配置等都可作为一般用例4.3 用例具体描述用例具体描述可由BA视用例困难程度、文档可阅读性、文档整体长度考虑,可将每个用例的具体描述形成单独文件,也可多个用例具体描述依据类别自组成单独文件。总之,用例具体描述可已敏捷的从整体需求文档中独立出来,增加可读性。可以运用下列两风格之一描述用例，以适应不同的项目状况：模版一（短期、高强度项目模版编号：用例的唯一标识符,建议格式:模块标识-流水号级别：概要、用户目标、子功能之一用例目标：概述产生该用例的缘由以及实现后能够带来的价值主角：主角名或主角的描述前置条件：用例起先前必需的达到的状态完

10、成后状态（后置条件）：在用例完成后的业务上所处的状态 胜利完成 失败后状态触发事务：任何启动用例的事务主胜利场景：一段描述描述主角在主胜利场景中完成目标的文字扩展：一段描述全部可选路径的文字发生频率：用例多久发生一次业务规则及算法说明：一段描述业务规则的文字非功能需求：引用已经定义的非功能性需求其他说明：一些好的想法或者是其他特殊要求,例如各种系统提示信息,需统一描述模版二（长期、大型项目正式的模版）：编号：用例的唯标识符,建议格式:模块标识-流水号级别：概要、用户目标、子功能之一用例目标：概述产生该用例的缘由以及实现后能够带来的价值主角：主角名或主角的描述前置条件：用例起先前必需的达到的状态

11、触发事务：任何启动用例的事务主胜利场景：1 .动作步骤2 .扩展：Ia.扩展条件:Ia1.动作步骤1a2.发生频率：用例多久发生一次业务规则及算法说明：段描述业务规则的文字非功能需求：引用已经定义的非功能性需求其他说明：一些好的想法或者是其他特殊要求页面原型：将页面原型文件嵌入该位置或者超链接即可对描述用例的提示:1 .不是仅关注主胜利场景就够了,对于扩展用例往往是系统实现的重点。扩展用例不仅仅是新增用例下的修改、删除,更多的须要考虑当用户输入内容不满意系统要求、当用户干脆取消当前操作、当用户查询数据不存在时等等用例结果失败的状况下,系统应当的行为如何2 .尽量在个用例书目下将该用例实现的全部

12、必需信息描述完成，便于用户阅读3 .对于页面原型,统一将原型文档嵌入到用例之后,干脆阅读即可,削减文档长度4 .对于用例描述中的一些内容,假如无具体内容,请删除5 .关于页面原型:举荐两种工具,VISIOfPEXCE1.假如有大量的结果列表须要显示，建议运用EXCE1另附EXCE1的页面原型模版。其中数据项的内容为必填内容。5非功能性需求5.1 系统接口需求描述系统与其他计算机系统的接口关系。5.1.1 用户界面描述系统的操作界面要求。5.1.2 硬件接口此节指出软件所支持的全部硬件接口,其中包括逻辑结构、物理地址、预期行为等。5.1.3 软件接口排列通过软件接Q的数据内容,描述每项数据内容的

13、名称,格式,最好有示例此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取自其他应用程序重新利用的构件,是应用程序必需与之交互的构件。5.1.4 通讯接口说明与其他系统或设备(如局域网、远程串行设备等)的全部通信接口。5.2 系统性能需求(1)数据精度(2)时间特性描述对本软件的时间特性要求,包括:响应时间、处理时间、数据转换时间、数据传输时间、系统初始化时间、日终批处理时间。(3)敏捷性描述当需求发生某些变更时,本软件产品对这些变更的适应实力,包括:操作方式的变更、运行环境的变更、同其他应用系统的接口的变更、精度的变更、安排的变更。5.3 系统平安性指明本软件应具有的平安

14、及保密功能,包括防止非授权用户登录等。假如须要特殊指定的加密或者平安结构也在此指明。5.4 牢靠性需求列明系统要求的具体指标,依据具体项目或者产品的要求确定I)建议如下:平均故障间隔时间(MTBF)一通常为小时书,也可以为天数、月数和年数平均修复时间(MTTR)系统在发生故障后可以暂停运行的时间5.5 可维护性需求指明本软件的可维护性要求,确保软件系统是可以维护的5.6 可移植性需求指明本软件在移植性方面的需求,须要列举出移植的目的运行环境。确保软件在各个系统上的兼容性需求5.7 数据存储需求指明本软件应具有的数据备份和更原功能,包括:数据备份时间、数据保留期限、数据复原时间要求等。5.8 数据转入说明如有老系统,写明原有系统的描述,及其数据转入新系统的需求。6产品组件需求列表描述选择的