业务需求03非功能性需求模版
- 格式:doc
- 大小:87.63 KB
- 文档页数:10
xxx系统非功能性需求说明书版本历史修改类型定义:A - ADDED M - MODIFIED D – DELETED目录1.1 非功能性需求 (4)1.2 性能需求 (4)1.2.1 系统处理能力 (4)1.2.2 系统运行时间需求 (4)1.2.3 精度 (4)1.2.4 开放性 (4)1.2.5 安全可靠性 (5)1.2.6 易操作性 (5)1.2.7 易维护性 (5)1.2.8 实用性 (5)1.3 环境需求 (5)1.4 开发标准 (6)1.5 安全需求 (6)1.5.1 主机安全 (6)1.5.2 网络安全 (6)1.5.3 信息安全 (7)1.5.4 传输安全性 (7)1.5.5 数据安全 (7)1.5.6 数据备份恢复 (7)1.5.7 个人密码安全 (7)1.5.8 操作用户安全控制 (8)1.5.9 业务安全 (8)1.6 界面需求 (8)1.6.1 操作一致性 (8)1.6.2 提示信息恰当而规范 (8)1.6.3 功能统一 (8)1.6.4 支持默认功能 (9)1.1非功能性需求1.2性能需求1.2.1系统处理能力页面请求响应时间是指从客户端(浏览器)发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所消耗的时间。
由于页面包含的业务逻辑的差异,参考国内外对web应用性能评测常用的3/5/10原则,定义该指标如下:➢业务逻辑比较简单的页面,响应时间在3秒之内;➢业务逻辑中等复杂的页面,相应时间在3到5秒之内;➢业务逻辑比较复杂的页面,响应时间在5到10秒内;并发用户数是指同一时刻系统能支撑的最大用户数量,基于推荐的硬件平台,电商平台软件最多可以支持3000用户同时在线1.2.2系统运行时间需求系统应支持7*24小时连续运行。
所有主机设备、网络设备和通讯线路均采用热备的方式。
一旦发生故障系统自动切换到备份设备或备份线路上,最大程度降低系统当机时间。
1.2.3精度严格按照金融系统规范给出的交易数据的精确度进行系统设计,保证交易金额的精确性。
软件开发需求说明书模板1. 引言本文档旨在明确软件开发项目的需求和目标,以便开发团队能够理解和满足客户的需求。
2. 项目背景描述软件开发项目的背景和目的,包括项目的业务背景、市场需求和预期的效益。
3. 项目范围明确软件开发项目的范围,包括功能性和非功能性需求。
具体包括以下内容:功能需求:列出软件开发项目需要实现的具体功能。
非功能需求:列出软件开发项目需要满足的性能、安全、可用性等方面的要求。
4. 用户需求描述软件的用户需求,包括用户的角色、用户需求的业务流程、用户界面的要求等。
5. 系统需求详细描述软件系统的功能需求和性能需求,包括系统的输入、输出、处理逻辑等。
可以使用用例图、流程图等工具进行说明。
6. 数据需求描述软件系统需要处理的数据,包括数据的类型、结构、存储和管理方式等。
7. 界面需求描述软件系统的用户界面需求,包括界面设计原则、界面布局、色彩和字体等要求。
8. 安全需求描述软件系统的安全需求,包括用户身份验证、数据加密、访问控制等方面的要求。
9. 性能需求描述软件系统的性能需求,包括响应时间、并发用户数、系统容量等方面的要求。
10. 可用性需求描述软件系统的可用性需求,包括易学性、易用性、可访问性等方面的要求。
11. 维护需求描述软件系统的维护需求,包括可维护性、可测试性、文档要求等方面的要求。
12. 部署需求描述软件系统的部署需求,包括硬件环境、操作系统、数据库等方面的要求。
13. 项目进度安排描述软件开发项目的进度安排,包括里程碑、交付时间等。
14. 项目团队描述软件开发项目的团队组成和角色分工。
15. 项目风险描述软件开发项目可能面临的风险,并提供相应的风险管理措施。
16. 项目交付物列出软件开发项目的交付物,包括需求文档、设计文档、测试报告等。
17. 参考资料列出本文档编写过程中参考的资料和文献。
以上是一个软件开发需求说明书的模板,根据实际项目需求进行相应的调整和补充。
业务需求文档怎么写范文示例1:标题:业务需求文档的写作范例引言:业务需求文档是一份详细描述特定业务需求的文件,它在整个项目的开发过程中起到了至关重要的作用。
本篇文章将为读者提供一个业务需求文档的写作范例,以帮助他们更好地理解和应用。
一、项目概述:在这一部分,我们将对项目进行简要的介绍和概述,包括项目的目的、背景和范围。
我们将明确项目的目标,并对所需的业务功能进行简要概述。
二、业务需求:在这一部分,我们将详细介绍项目的业务需求。
我们将使用以下格式来描述每个需求:1. 需求编号:为每个需求分配一个唯一的编号,以便于跟踪和引用。
2. 需求描述:清晰、简洁地描述需求。
3. 优先级:为每个需求分配一个优先级,以便在开发过程中进行合理的分配和排序。
4. 附件:附上相关的文件、图片或其他资料,以更好地说明需求。
5. 验收标准:明确需求被满足的验收标准。
三、功能需求:在这一部分,我们将具体描述每个业务需求所对应的功能需求。
我们将使用以下格式来描述每个功能需求:1. 需求编号:同样为每个功能需求分配一个唯一的编号。
2. 需求描述:清晰、简洁地描述功能需求。
3. 功能详细说明:详细说明每个功能的实现细节,如界面设计、输入输出、系统流程等。
4. 数据要求:描述所需的输入数据和输出数据的格式、结构和要求。
5. 错误处理:描述系统在遇到错误或异常情况时的处理方式。
四、非功能性需求:在这一部分,我们将描述项目所需的非功能性需求,例如性能要求、安全性要求、用户体验要求等。
我们将使用以下格式来描述每个非功能性需求:1. 需求编号:同样为每个非功能性需求分配一个唯一的编号。
2. 需求描述:清晰、简洁地描述非功能性需求。
3. 实现方式:描述如何满足该需求,例如采用何种技术或方法。
4. 验证方式:描述如何验证需求是否满足,例如使用何种性能测试工具或方法。
五、项目交付标准:在这一部分,我们将定义项目的交付标准,明确在项目完成后客户对交付物的要求和期望。
业务需求—03非功能性需求模版非功能性需求是指系统或软件产品在使用过程中的性能、稳定性、安全性、可靠性等方面的要求。
非功能性需求对系统的操作、管理、维护都有一定的影响,它们是系统或软件产品功能的补充和扩展。
模板一:1.性能需求(1)响应时间:系统或软件在用户发出指令后的响应时间需控制在X秒以内。
(2)吞吐量:系统或软件每秒能够处理的请求数量需达到X个。
(3)并发用户数:系统或软件能够支持同时登陆的用户数需达到X 个。
2.可靠性需求(1)可用性:系统或软件的可用时间需达到X%以上。
(2)容错性:系统或软件在遇到异常情况时能够正确处理,并继续提供服务,不导致数据丢失或系统崩溃。
(3)恢复性:系统或软件在发生故障或崩溃后能够自动恢复或者提供快速的恢复功能。
3.安全性需求(1)数据安全:系统或软件需要有一定的安全措施,防止数据泄露、篡改或丢失。
(2)访问控制:系统或软件需要实现不同用户的权限管理,保证只有授权用户能够进行相关操作。
4.易用性需求(1)界面友好性:系统或软件的界面要简洁明了、易于操作,不让用户感到困惑或迷失。
(2)操作方便性:系统或软件的操作流程应该简单明了,用户能够快速上手,减少误操作的发生。
(3)帮助文档:系统或软件需要提供详尽的帮助文档,以便用户在使用过程中能够解决问题或获取帮助。
5.可拓展性需求(1)系统或软件需要能够支持未来的业务拓展和功能扩展,具备良好的可扩展性。
(2)系统或软件需要能够与其他系统进行接口对接,实现跨系统的协同工作。
(3)系统或软件需要能够灵活调整配置参数和优化性能,以适应不同的业务需求。
6.兼容性需求(1)硬件兼容性:系统或软件需要适配不同类型、不同规格的硬件设备。
(2)软件兼容性:系统或软件需要适配不同操作系统、不同浏览器、不同数据库等软件环境。
(3)数据兼容性:系统或软件需要能够兼容不同格式的数据输入和输出。
(以上为示例,可以根据实际项目需求调整。
)模板二:一、性能需求1.响应时间:系统或软件的响应时间在X秒内2.吞吐量:系统或软件的吞吐量需要达到每秒处理X个请求的能力3.并发用户数:系统或软件能够同时支持X个用户登录和使用二、可靠性需求1.可用性:系统或软件需要保证每月X天X小时的可用时间2.容错性:系统或软件在发生异常情况时需要能够自动恢复或提供备份措施3.故障恢复:系统或软件在发生故障后需要能够快速恢复并保证数据不丢失三、安全性需求1.数据安全:系统或软件需要采取相应的安全措施,保证数据不被泄露、篡改或丢失2.访问控制:系统或软件需要具备用户身份验证和权限管理功能,保证只有授权用户能够进行相关操作3.安全审计:系统或软件需要记录相关操作日志和安全事件,并支持审计四、易用性需求1.界面友好性:系统或软件的界面设计应简洁明了、易于操作2.操作方便性:系统或软件的操作流程应简单明了,用户能够快速上手3.帮助文档:系统或软件需要提供详细而易懂的帮助文档,供用户查阅和解决问题五、可拓展性需求1.系统扩展性:系统或软件需要能够方便地进行功能扩展和业务拓展2.接口对接:系统或软件需要能够与其他系统进行接口对接,实现数据共享和业务协同六、兼容性需求1.硬件兼容性:系统或软件需要适配不同型号、不同规格的硬件设备2.软件兼容性:系统或软件需要适配不同操作系统、不同浏览器等软件环境。
软件项目用户需求之非功能需求(范文1)第1章非功能需求1.1 用户界面需求用户界面直接面向用户,是后端程序与前端交互的展示页面,一个好界面设计,对用户的感观是非常重要的,本系统将为用户提供美观、大方、直观、操作简单的具备WINDOW风格的用户界面,用户界面的整体标准包括以下三个方面:1.规范性;2.合理性;3.一致性。
1.1.1规范性遵循一致的准则,确立标准并遵循,是软件界面设计中必不可必的环节。
确立界面标准的好处:1.便于用户操作:户使用起来能够建立起精确的心里模型,使用熟练了一个界面后,切换到另外一个界面能够很轻松的推测出各种功能。
2.使用户感觉到统一、规范,在使用软件的过程中愉快轻松的完成操作,提高对软件的认知。
3.降低培训、支持成本,不必花费较多的人力对客户进行逐个指导。
1.1.2合理性界面的合理性是指界面是否与软件功能相融洽,界面的颜色和布局是否协调等。
例如:1.界面布局(1)屏幕不能拥挤Mayhew在1992年的试验结果表明屏幕总体覆盖度不应该超过40%,而分组覆盖度不应该超过62%。
整个项目,采用统一的控件间距,通过调整窗体大小达到一致,即使在窗体大小不变的情况下,宁可留空部分区域,也不要破坏控件间的行间距。
(2)控件按区域排列一行控件纵向中对齐,控件间距基本保持一致,行与行之间间距相同,靠窗体的控件距窗体边缘的距离应大于行间距。
当屏幕有多个编辑区域,要以视觉效果和效率来组织这些区域。
(3)有效组合逻辑上相关联的控件应当加以组合以表示其关联性,反之,任何不相关的项目应当分隔开。
在项目集合间用间隔对其进行分组,或者使用方框划分各自区域。
(4)窗口缩放时,控件位置、布局固定窗口大小,不允许改变尺寸。
改变尺寸的窗口,在窗口尺寸发生变化时控件的位置、大小做出相应的改变。
改变尺寸的窗口,在窗口改变尺寸时增加相应在的纵向、横向滚动条,以方便用户使用窗体上的控件。
2.界面颜色搭配使用恰当的颜色,可以使软件的界面看起来更加规范。
业务需求说明书_非功能性需求业务需求说明书非功能性需求文档标识项目名称文档名称文档存放位置版本号文档状态文档更改记录版本日期描述修改人V0.9 2004-6-29 初始版本V0.9 2004-7-1 修改稿I目录1 引言 ..................................................................... ........................................................................ ............... 2 1.1 文档目的...................................................................... .......................................................................2 1.2 文档范围.............................................................................................................................................2 1.3 目标读者...................................................................... .......................................................................3 1.4 文档输入...................................................................... .......................................................................3 2 需求说明 ..................................................................... ........................................................................ ....... 4 2.1 性能需求...................................................................... .......................................................................4 2.2 安全性需求 ..................................................................... .. (5)2.3 易用性需求 ..................................................................... .. (7)2.4 可用性需求 ..................................................................... .. (8)2.5 可靠性需求 ..................................................................... (8)2.6 可扩展性需求 ..................................................................... ................................................................ 9 2.7 可伸缩性需求 ..................................................................... .............................................................. 10 2.8 可移植性需求 ..................................................................... .............................................................. 10 2.9 可管理性需求 ..................................................................... .. (10)2.9.1 日志管理 ..................................................................... .. (11)2.9.2 版本管理 ..................................................................... .. (12)2.9.3 公告管理 ..................................................................... .. (12)2.9.4 系统监控 ................................................................................................................................... 12 3 遗留问题 ..................................................................... ........................................................................ .. (14)II11.1 文档目的本文档是业务江苏BSS1。
业务需求模板标题:业务需求模板一、引言在进行业务需求分析之前,制定一个明确的业务需求模板是非常重要的。
本文将介绍一个基本的业务需求模板,旨在帮助您更好地了解并规划您的业务需求。
二、背景这一部分主要描述有关业务需求的背景信息,包括但不限于行业情况、竞争对手分析等。
根据具体情况填写。
三、业务需求概述在这一部分,您需要简要概述您的业务需求,包括您希望实现的目标、解决的问题以及您期望得到的具体结果。
四、详细业务需求1. 业务流程描述在这一部分,您需要描述您的业务流程,并标明各个步骤或环节所需的功能和要求。
可以使用流程图或文字描述。
2. 功能需求这一部分主要列出您对系统或产品所需的具体功能。
请尽量详细地描述每个功能,并标明其优先级和必要性。
3. 数据需求在这一部分,您需要描述您对数据的需求,包括数据类型、数据量、数据来源、数据存储和数据安全等要求。
4. 接口需求如果您的业务需求涉及多个系统或产品的集成,那么您需要明确说明所需的接口类型、接口规范和数据传输方式等。
5. 性能需求在这一部分,您需要具体说明对系统或产品性能的要求,如响应时间、吞吐量、并发用户数等。
6. 安全需求如果安全性对您的业务需求非常重要,您需要详细说明对数据和系统的安全要求,如数据加密、身份认证等。
7. 其他需求如果有其他与业务需求相关的要求,如可扩展性、可维护性等,请在这一部分进行说明。
五、用户故事/用例为了更好地理解和验证业务需求,您可以编写一些用户故事或用例,描述具体用户在使用系统或产品时的场景和行为。
六、验收标准在这一部分,您需要定义一些具体的验收标准,用于确认系统或产品已经满足了业务需求。
这些标准可以是定量的或定性的。
七、结论通过制定一个业务需求模板,您可以更好地规划和管理您的业务需求,确保系统或产品的开发或采购可以顺利进行。
以上是一个探讨业务需求的基本模板,您可以根据具体情况进行调整和修改,以满足实际需求。
在实际应用中,还可以根据项目团队的要求增加或修改一些内容,以便更好地适应特定的业务环境。
系统报告需求分析模板需求分析是软件开发过程中的关键环节,它用于明确客户的需求并将其转化为可执行的开发任务。
在需求分析中,系统报告是一个重要的文档,它详细描述了系统的功能、目标、需求和约束等信息。
下面是一个系统报告需求分析模板的示例,供参考:1. 引言在引言部分,应提供系统报告的背景信息和目的。
说明该报告的编写目的是为了分析并满足客户的需求,以便于开展软件开发工作。
2. 项目概述项目概述部分应对整个系统进行简要的描述,包括系统的名称、目标、用户群体和关键功能等。
这里可以简要介绍系统的整体架构和核心特性。
3. 需求规定在需求规定部分,需要详细定义系统的需求,包括功能性需求和非功能性需求等。
以下是一些可能的需求规定条目:3.1 功能性需求- 描述系统的关键功能和子功能,以及各个功能之间的关系- 基于用户需求和业务流程,定义系统的用例和场景- 确定系统的输入、输出和处理要求,包括数据格式和验证规则等3.2 非功能性需求- 描述系统的性能要求,如响应时间、处理吞吐量等- 确定系统的可用性要求,如可靠性、灵活性和可扩展性等- 定义系统的安全要求,如身份验证、数据保护和访问控制等4. 系统架构设计在系统架构设计部分,需要详细说明系统的整体架构和模块设计。
以下是一些可能的系统架构设计条目:4.1 系统架构概述- 描述系统的整体结构和模块间的关系- 定义系统的层次结构和组件划分4.2 数据架构- 定义系统的数据模型和数据字典- 描述数据的组织和存储方式4.3 技术架构- 简要描述系统的技术选择和使用的开发工具- 定义系统的软件和硬件要求5. 风险评估和管理风险评估和管理部分需要对系统开发过程中可能出现的风险进行评估和管理。
以下是一些可能的风险评估和管理条目:5.1 风险识别- 识别系统开发中可能出现的风险和问题- 分析风险的原因和影响5.2 风险评估- 对每个风险进行评估和优先级排序- 确定各个风险的概率和影响程度5.3 风险管理- 制定相应的风险管理计划,包括控制措施和应对策略- 定期跟踪和监控风险的实施情况6. 开发计划开发计划部分需要详细描述系统的开发计划和时间表。
业务需求分析模板明确项目需求与目标业务需求分析模板一、背景信息在进行业务需求分析之前,首先需要了解项目的背景信息,包括但不限于以下几个方面:1. 公司基本信息:公司名称、规模、行业等;2. 项目背景:项目的起因、目的以及相关的背景资料;3. 相关方介绍:与项目相关的各方,包括项目团队、外部合作伙伴等。
二、项目目标明确定义项目的目标是非常重要的,目标应该具备以下特点:1. 可衡量:目标需要能够按照一定的指标进行度量和评估;2. 可实现:目标需要根据现有的资源和技术条件具备可行性;3. 与业务一致:目标需要与业务战略和业务需求保持一致;4. 具体而明确:目标需要清晰地描述预期的成果或结果。
三、项目需求在明确项目目标的基础上,需要具体列举项目的需求,可按以下方式进行组织和描述:1. 功能需求:列举项目需要实现的功能,可以按照模块或者模块内部的功能进行划分;2. 非功能需求:列举项目对于性能、安全性、可靠性等非功能方面的需求;3. 数据需求:描述项目对于数据的需求,包括数据源、数据存储和数据处理等;4. 用户需求:从用户角度出发,描述用户的期望和需求;5. 系统接口需求:描述项目需要与其他系统进行交互或集成的接口要求。
四、需求分析方法为了更好地明确项目需求,可以采用以下一些常用的需求分析方法:1. 需求调研:通过与业务相关方的沟通和调研,获取详细的需求信息;2. 需求访谈:与项目干系人进行面对面的访谈,深入了解他们的需求和期望;3. 需求文档分析:对于已有的需求文档进行详细的分析和研究;4. 原型设计:基于需求进行简要的原型设计,以便更好地理解和沟通需求;5. 业务流程分析:通过分析业务流程,找出其中的问题和改进点。
五、需求确认与验证需求确认与验证是确保需求准确性和可行性的重要环节,包括以下几个步骤:1. 需求评审:邀请项目干系人对需求进行评审,确保需求的完整性和合理性;2. 需求优先级排定:根据项目目标和紧急程度确定需求的优先级;3. 需求追踪:建立需求追踪机制,跟踪需求的变化和进展;4. 需求验证:通过测试和验收等方式,验证需求的实现情况。
〈项目名称〉业务需求-非功能性需求
版本 <1.0>
文档编号:
当前版本: 1.0
修改日期:
修订文档历史记录
目录
1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4
1.4参考资料4
2.性能4 2.1交易响应时间4 2.2用户数5 2.3吞吐量需求5
2.4数据存储容量6
3.可扩展性6
4.伸缩性6
5.安全性7 5.1应用安全性需求7
5.1.1认证与授权服务7
5.1.2资源访问控制服务7
5.1.3应用日志7 5.2基础级安全需求7
5.2.1防火墙保护7
5.2.2防病毒服务7
5.2.3数据安全7
5.2.4入侵检测及漏洞扫描7
5.2.5数据传输服务7
6.可用性7
7.易用性8
8.可靠性8 8.1计划维护服务时间8 8.2单点故障对系统的影响程度8 8.3可恢复性8
8.3.1停机恢复8
8.3.2程序和数据的备份8
8.3.3灾难恢复8
9.业务约束9 9.1<业务约束-001>业务组织架构9
9.2<业务约束-002>语言要求9
10.技术约束9 10.1<技术约束-001>客户端规范9 10.2<技术约束-002>服务器规范9 10.3<技术约束-003>网络环境规范10 10.4<技术约束-004>外设规范10 10.5<技术约束-005>开发规范10
[说明:文档模板中蓝字部分为模板说明和示例,黑字部分为内容要求。
黑字部分不允许删除,对于对项目不适用的部分,在相应的章节中进行说明。
]
1.简介
1.1目的
[阐明业务需求文档中,非功能性需求文档的目的。
]
1.2范围
[包括所有的非功能性需求。
]
1.3定义、首字母缩写词和缩略语
[本小节应提供正确理解此非功能性需求文档所需的全部术语、首字母缩写词和缩略语的定义。
这
些信息可以通过引用项目词汇表来提供。
]
1.4参考资料
[列出与本业务有关的一些参考资料,以备出现业务疑问时,可以方便地追根溯源。
每个文档应标
有标题、报告号(如果适用),如需要,列出文档的日期和发布组织。
列出可从中获取这些引用的来
源。
这些信息可以通过引用附录或其他文档来提供。
]
2.性能
[与性能有关的非功能需求由以下几个单独的子需求组成:]
2.1交易响应时间
[交易可以定义为:一个交易是指一个单一角色跨越系统边界触发一个事件并执行一定数量的处
理和数据库访问。
交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。
根据业务处理类型的不同,本规范把交易划分为三类:交互类业务、查询类业务和大数据量批
处理类业务,并根据交易类别分别给出响应时间要求的参考值,包括峰值响应时间、平均响应时间。
]
●交互类业务
[交互类业务的响应需求。
]
●查询类业务
[查询类业务的响应需求,可以包括一些对信息进行分析的需求。
]
●大数据量、批处理业务
[大数据量、批处理业务的响应需求。
]
2.2用户数
[用户数指标反映了不同情况下的使用系统的用户规模,包括总用户数、在线用户数、并发用户数。
考虑到系统峰值时刻和非峰值时刻的区别,在线用户数、并发用户数又分别考虑峰值和平均的数量情况。
以下是各种用户数量的说明:
总用户数:拥有合法身份,能够使用系统的用户数量
峰值在线用户数:系统峰值天/峰值小时的平均在线用户数量(登录系统的用户)
峰值并发用户数:系统峰值天/峰值小时的平均并发用户数量(同时提交业务请求的用户)
平均在线用户数:系统的平均在线用户数量(登录系统的用户)
平均并发用户数:系统的平均并发用户数量(同时提交业务请求的用户)]
2.3吞吐量需求
[峰值时刻每分钟交易数及未来n年该数量的预期(增长)值。
每年的总交易笔数及未来n年该数量的预期(增长)值。
交易量指标如下:]
2.4数据存储容量
[每年的数据存储容量(GB)及未来n年该数量的预期(增长)值。
当前存储容量如下:]
说明:[对数据量具体情况做描述]
数据存储容量估算:
[估算未来n年的数据增长量和累计存储容量。
]
3.可扩展性
[描述系统在可扩展性方面的要求。
]
4.伸缩性
[描述系统在伸缩性方面的要求。
]
5.1应用安全性需求
5.1.1认证与授权服务
[描述系统对认证和授权方面的要求。
]
5.1.2资源访问控制服务
[描述系统对资源被访问权限的控制要求。
]
5.1.3应用日志
[描述系统对运行中的操作记录轨迹的要求。
]
5.2基础级安全需求
5.2.1防火墙保护
[描述了系统对防火墙的保护能力的要求。
]
5.2.2防病毒服务
[描述了系统在防病毒服务方面的要求。
]
5.2.3数据安全
[描述了系统对数据安全的要求。
]
5.2.4入侵检测及漏洞扫描
[描述了对系统防范入侵能力的要求。
]
5.2.5数据传输服务
[描述了系统进行数据传输的要求。
]
6.可用性
[系统可用性定义了系统在什么时间段对用户是可使用的,以及是如何被用户使用的。
]
[描述系统在界面、功能等方面人性化设计的考虑。
]
8.可靠性
8.1计划维护服务时间
[描述系统可以进行升级、维护的时间和升级周期等。
]
8.2单点故障对系统的影响程度
[描述系统发生单点故障时对系统的影响程度方面的要求。
] 8.3可恢复性
[描述系统崩溃后的可恢复性要求。
]
8.3.1停机恢复
[描述系统崩溃后到恢复重新使用的时间要求。
]
[系统应能够在 X小时内从停机中恢复。
]
8.3.2程序和数据的备份
8.3.3灾难恢复
[描述系统处理灾难的能力要求。
]
[当灾难发生后,系统应在X小时内恢复。
]
9.业务约束
9.1<业务约束-001>业务组织架构
[描述业务组织架构。
]
9.2<业务约束-002>语言要求
[描述业务系统中对语言的支持。
]
10.技术约束
10.1<技术约束-001>客户端规范
[本部分描述客户端的最低硬件配置和系统软件规范。
]
10.2<技术约束-002>服务器规范
[描述系统对服务器的最低配置要求。
]
表10-2
10.3<技术约束-003>网络环境规范
[描述对网络环境如:带宽等方面的要求。
]
10.4<技术约束-004>外设规范
[描述系统对接入外部设备的要求。
]
10.5<技术约束-005>开发规范
[描述目标系统开发过程中应该遵守的原则和标准。
]。