[模板]系统需求说明书.doc

《[模板]系统需求说明书.doc》由会员分享，可在线阅读，更多相关《[模板]系统需求说明书.doc（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、系统需求说明书模板Version 0.1核准签名核准人项目经理日期核准人系统分析师日期核准人客户日期核准人日期核准人日期核准人日期修订历史日期版本描述作者2010-11-300.1草稿谭勇目 录1介绍41.1编写目的41.2适用范围41.3文档概述41.4定义、术语及缩写41.5参考42系统定位52.1问题说明52.2系统定位52.3涉众说明53系统概述53.1系统总体效果53.2假设与依赖关系53.3系统特性63.3.1系统特性163.3.2系统特性264其他系统需求64.1系统质量需求64.1.1性能64.1.2可靠性74.1.3可维护性74.1.4可用性74.1.5灵活性84.1.6可移

2、植性84.1.7可重用性84.1.8可测试性84.1.9易用性94.2安全性需求94.3保密性和私密性需求94.4环境需求104.5适用的标准101 介绍本文档应主要描述系统定位和系统特性，为后继的分析和软件需求规格说明书编制奠定基础。在正式编写文档时，请删除内容要求部分。1.1 编写目的说明编写这份文件的目的，并简要描述本文档的目的。1.2 适用范围说明这份文件的适用范围及其阅读对象，列举软件需求说明所针对的不同读者，例如项目负责人、开发人员、部门主管、对方项目负责人、用户、测试人员或文档的编写人员。提出最适合于每一类型读者阅读文档的建议。示范：仅供参考，不具备任何实质性的内容。本文档适用于

3、所有与本项目有关的软件开发阶段及其相关人员，其中：项目负责人、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。1.3 文档概述本文档主要描述了XXXXXXXXXX系统项目的系统需求。1.4 定义、术语及缩写列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个部门创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。术语/缩写定义1.5 参考列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。文档名称文档标题2

4、系统定位2.1 问题说明概要描述本系统正在解决的问题。2.2 系统定位概要描述本系统的目的和重要性。2.3 涉众说明概要描述本系统的涉众和用户，以及关键的涉众/用户的需要。名称描述职责涉众的名称涉众的简单描述列出涉众对所开发的系统负有的关键职责，即他们作为涉众的利益。3 系统概述本章节高度概括系统的功能、与其它应用程序的接口以及系统配置。3.1 系统总体效果应将该系统放在其他相关系统环境和用户环境中进行介绍。如果该系统自成一体，应在此处说明。如果该系统是较大系统的构件，此小节则应说明这些系统如何进行交互，并确定系统之间的相关接口。要显示较大系统的主要构件、互连情况和外部接口，一种简单的方法就是

5、通过框图来表示。3.2 假设与依赖关系列出会影响文档中所述特性的所有因素。列出其变更将引起文档随之变化的假设。例如，有这样一项假设：将为该软件系统指定的硬件提供特定的操作系统。但如果没有提供该操作系统，就将需要更改文档。3.3 系统特性列出并简述系统的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。例如，问题跟踪系统的特性是能够提供趋势报告。当用例模型成型后，更新这里的说明以指代用例。由于文档将由各种各样的相关人员来复审，所以不应太过详细，应让所有人对此都有大致的了解。但是，应该向团队提供他们创建用例模型所需的必要详细信息。

6、要有效地管理应用程序的复杂性，对于任何新系统或对现有系统的增量部分，我们建议将功能提炼到较高的程度，这样25到99项特性较为合理。这些特性为系统定义、规模管理和项目管理提供了基础。每项特性的详细程度都将在用例模型中得到较深入的扩展。贯穿此节的始终，都应能让用户、操作人员或其他外部系统从外部觉察到每项特性。这些特性应包括功能性的说明以及必须考虑的任何相关的可用性问题。注意要避免设计。使特性说明保持一定的概括程度。侧重于说明所需的功能以及为什么要（而不是如何）实现这些功能。3.3.1 系统特性13.3.2 系统特性24 其他系统需求4.1 系统质量需求本条应描述对系统或子系统质量方面的需求,例如包

7、括性能（支持的用户数、操作响应速度、资源占用约束等）、可靠性(产生正确、一致结果的能力)、可维护性(易于更正的能力)、可用性(需要时进行访问和操作的能力)、灵活性(易于适应需求变化的能力)、可移植性(易于修改以适应新环境的能力)、可重用性(可被多个应用使用的能力)、可测试性(易于充分测试的能力)、易用性（易于学习和使用的能力）以及其它属性的定量需求。需求应尽可能具体、量化和能够验证。4.1.1 性能阐述不同的应用领域对系统性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。你还可以在这里定义容量需求，例如存储器和

8、磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。示范：仅供参考，不具备任何实质性的内容。系统容量：支持3万用户，支持GB级数据。数据库表行数不超过100万行，数据库最大容量不超过1000GB，磁盘空间至少需要40G以上.响应指标：运行速度取决于硬件配置和应用数据规模，在推荐配置环境下：登录响应时间在5秒内，刷新栏目响应时间在5秒内，刷新条目分页列表响应时间5秒内，打开信息条目响应时间3秒内，刷新部门、人员列表响应时间5秒内。4.1.2 可靠性阐述客户对系统的可靠性方面的要求。可靠性是软件无故

9、障运行一段时间的概率。示范：仅供参考，不具备任何实质性的内容。本系统的最终用户涉及面广，因此，整体系统运行要求稳定，有很强的防错、抗错能力，保证数据报送工作正常进行。可靠性指标：在连续运行情况下，系统可靠性99.9999%。提供应用服务器集群技术和组件技术支持高可靠性和伸缩性。4.1.3 可维护性阐述客户对系统的可维护性方面的要求。可维护性表明了自软件中纠正一个缺陷或做一次更改的简易程度。示范：仅供参考，不具备任何实质性的内容。从设计上尽量考虑大多数系统的建设都能使用本软件搭建而成，最少做二次开发或者不做二次开发，直接通过系统配置搭建系统，从功能上具有通用性，易修改和扩展。软件开发使用组件技术

10、，保证了可维护性高。系统具有开放性，是指统计、分析内容的可修改、可扩展性。例如，经过一定的授权，系统管理人员即可根据将来统计制度变动的需要对统计指标进行增、删等修改，无需经过软件开发技术人员。兼容性：系统应支持多种操作系统、数据库系统和、WEB服务器系统。采用JAVA、JNDI技术来保证较好的可移植性和可扩展性。4.1.4 可用性阐述客户对系统的可用性方面的要求。可用性表明了软件具备随时随地能够访问和操作的能力。示范：仅供参考，不具备任何实质性的内容。本系统采用B/S和C/S混合模式，支持脱机方式，因此能够保证用户随时随地访问系统。同时，系统采取容错技术，具备数据恢复功能，能够保证用户随时随地

11、操作系统。4.1.5 灵活性阐述客户对系统的灵活性方面的要求。灵活性表明了软件系统能够易于适应需求的变化的能力。示范：仅供参考，不具备任何实质性的内容。适应多种数据传输方式，能够提供灵活配置以适应业务需求的变化，如可自行定义业务规则、采集机构、采集指标、处理逻辑、反馈信息等等，通过多方面的定制以适应某个具体的业务系统。4.1.6 可移植性阐述客户对系统的可移植性方面的要求。可移植性表明了软件易于修改以适应多种环境的能力。示范：仅供参考，不具备任何实质性的内容。本系统支持多种网络环境，特别是互联网，能够实现跨平台操作。4.1.7 可重用性阐述客户对系统的可重用性方面的要求。可重用性表明了软件能够

12、被多个应用使用的能力。示范：仅供参考，不具备任何实质性的内容。本系统提供组件式服务，部分公用组件能够被其它系统所使用。同时，在将来后继升级系统时，能够使得部分组件被重用。4.1.8 可测试性阐述客户对系统的可测试性方面的要求。可测试性表明了软件能够在有限时间、人力资源限度内被充分测试的能力。示范：仅供参考，不具备任何实质性的内容。软件系统具有良好的可测试性，能够在4个工作周、3个人力的情况下顺利完成所有测试项目。具体测试项目如下：代码检查：程序开发人员除了调试外，还应进行重点检查程序代码语法错误。单元测试：对组成系统的每个组件进行数据结构测试和功能性测试，重点是组件的功能和程序逻辑。集成测试：

13、将组件组装成子系统后，应再次对组装后的子系统进行功能性测试，重点是组件与组件之间的接口测试。系统测试：经过测试后的各子系统组装成系统后，还应组织对整个系统进行全面的测试，包括功能、性能以及接口测试。性能测试：测试系统的操作相应速度以及资源占用效率。压力测试：测试系统的可靠性和伸缩性，以验证系统能承受多大的负载。鉴于本软件系统的特殊性，测试重点应放在功能和性能上，其它方面可略作测试。4.1.9 易用性阐述客户对系统的易用性方面的要求，易用性包括人机界面的友好性，新用户或不常使用系统的用户在学习使用系统时的简易程度等。示范：仅供参考，不具备任何实质性的内容。系统应操作简单、易学易用、符合标准浏览器

14、操作风格，丰富的联机帮助，人性化的操作界面，界面布局合理，节省操作时间提高生产效率。4.2 安全性需求详尽陈述与系统安全性、完整性或与私人问题相关的需求，包括用户身份确认或授权需求，数据库安全性需求，工作流程安全性需求等。这些问题将会影响到系统的使用和系统所创建或使用的数据的保护。定义用户身份确认或授权需求。明确系统必须满足的安全性或保密性策略。示范：仅供参考，不具备任何实质性的内容。网络安全：能经受来自互联网的一般性恶意攻击。如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等。因此，必须配备较强的网络安全防范、响应能力，为应用系统提供安全可靠的网络统计平台。数据库安全：数据库级备份和恢复。数据

15、库级用户进行角色和权限授权。使得在异常情况发生时，系统可以得以快速恢复，避免数据的丢失或将其影响降到最低限度。同样，要保证存储过程中数据不被非法访问和篡改。应用系统的安全：通过对用户的身份鉴别，并实施相应的访问控制策略后，使用户只能完成得到系统授权的数据访问功能操作。用户只有经授权后才可以更新程序，避免因错误程序更新而影响系统的正常运行。4.3 保密性和私密性需求本条应指明保密性和私密性的系统需求，包括：系统运行的保密性/私密性环境、提供的保密性或私密性的类型和程度、系统必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、系统必须遵循的保密性/私密性政策、必须提供的保密性/私密性审核、

16、保密性/私密性必须遵循的确证/认可准则。示范：仅供参考，不具备任何实质性的内容。数据保密：网络传递数据经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。4.4 环境需求以列表形式或分类方式描述有关系统或子系统必须运行的环境需求，例如包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。示范：仅供参考，不具备任何实质性的内容。项目硬件操作系统及其版本应用服务器软件及其版本应用软件及其部件服务器IBM RS6000AIX 4.3.3IBM HTTP Server、Apache、MS IIS5.0等；DB2（7.2 EE以上版本）WAS（4.0以上版本）、Web L

17、ogic(7.0以上版本)等；Oracle EE（9i EE以上版本）浏览客户端PII 800/64M/2GWin98及以上IE 5.0以上或Netscape同等版本以上特殊客户端PII 2G/64M/2G建议配置Win2000及以上IE 5.0以上或Netscape同等版本以上MicroStrategy7i客户端4.5 适用的标准列出系统必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix等）以及质量和安全标准（UL、ISO、CMM）。注：以上只是列出了在编写系统定义说明书时可能需要编写的内容，请根据实际编写需要进行增删。