非功能性需求
非功能需求说明书示例
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、非功能性需求：用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望，包括：(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。
(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。
(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。
(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求。
(5) 运行环境约束：用户对软件系统运行环境的要求。
(6) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。
(7) 可保障性（supportable）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。
1。
7 非功能性需求
可行性研究 领域分析 需求分析
设计
编码
测试
交付
我们的进度，在这里
2016年双11当日 10大电商网站每个时间段的网站速度
双11当日网站平均速度(ms)
可行性研究 领域分析 需求分析
设计
编码
测试
交付
我们的进度，在这里
非 功 能 性 需 求 功能性需求
个性化
系统是业界领先的
系统要保持可扩展的接口， 要能与旧系统、外部系统、
安全性与用户业务内容相关。如果开发的软件是信 息安全级别很高的，如政府机构的办公文件，那么 相应的安全性需求也会很高；
另外，对于软件运行的环境来说，如果是一个运用 于广域网的软件，如淘宝网，那么相应的安全级别 就要高，反之，如果是仅仅运用与局域网，或者是 一个单机软件，那么安全性要求就比较低。
可行性研究 领域分析 需求分析
可行性研究 领域分析 需求分析
设计
编码
测试
交付
我们的进度，在这里
稳定性
稳定性由故障的频率、严重性、可恢复性、可预见 性、准确性和平均故障间隔时间等一些指标构成。
判断软件是否失效的判断依据有：系统死机、系统 无法启动、不能输入输出或显示记录、计算数据有 错等。
可行性研究 领域分析 需求分析
设计
我们的进度，在这里
可靠性 可用性 有效性 可移植性
安全性、事务性、稳 定性
容易学习，使用效率， 记忆性，错误恢复， 性能、可伸缩主性、观可满意度 扩展性
获取非功能性需求，由谁负责？
需求分析人员最容易忽略的部分就是非功能性需求。 非功能性需求更加靠近的是技术、是设计、是实现， 是架构师关注的内容，是需求人员最不擅长的方面， 这也是非功能性需求常常被忽略的重要原因。
关于非功能性需求说明书
非功能性需求1) 什么是非功能性需求非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
2) 重要吗？在设计解决方案的过程中满足功能性需求当然是很重要的。
但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
3) 非功能性需求要考虑那些方面非功能性的特性一般有这些：可靠性只显示系统可以做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：* 即使硬件出现故障，系统也可以可靠运行吗？* 复制和故障转移方案是什么？* 需要手动干预，还是系统可以自动进行故障转移？* 实现可靠性会对性能造成负面影响吗？* 实现可靠性的成本有多高？可靠性需要考虑的一些具体方面是：安全性：假设攻击者就在外面。
如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。
不要假设始终可以进行两阶段提交 (twophase commit)。
可用性如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？* 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？* 是否界面本来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
非功能需求工作量标准及量化计算过程
非功能需求工作量标准及量化计算过程一、引言在软件开发的过程中，我们通常将需求划分为功能需求和非功能需求。
功能需求指的是系统必须提供的功能或者服务，而非功能需求则指的是系统需要满足的性能、安全性、可靠性、易用性等方面的要求。
在本文中，我们将重点讨论非功能需求的工作量标准及量化计算过程。
二、什么是非功能需求？非功能需求，又称软件质量属性，指的是系统除了功能以外的方面的需求。
它们通常用来描述系统的性能、可靠性、安全性、可用性、可维护性等方面的特性。
非功能需求的重要性不言而喻，一个软件产品的成功与否往往取决于它是否满足了这些非功能需求。
三、非功能需求工作量标准1. 确定非功能需求的具体内容在开展非功能需求工作量标准之前，首先需要明确具体的非功能需求内容。
这通常需要与业务部门和用户进行充分的沟通和需求分析，以确定系统在性能、安全性、可靠性等方面的具体要求。
2. 划分非功能需求的权重为了更好地评估非功能需求的工作量，我们需要为不同的非功能需求划分权重。
这意味着我们需要确定哪些非功能需求在系统中的重要程度更高，以便更有针对性地进行评估和计量。
3. 量化非功能需求在明确了具体的非功能需求内容及其权重后，我们可以开始考虑如何对这些非功能需求进行量化。
这可能涉及到性能测试、安全性测试、可靠性测试等方面的具体指标和标准。
4. 制定工作量标准通过对非功能需求进行量化，我们可以更准确地评估出每个非功能需求的工作量。
这个工作量标准可以基于具体的指标和标准，也可以结合专业的评估方法和工具进行量化计算。
四、非功能需求工作量量化计算过程基于以上的非功能需求工作量标准，我们可以进行具体的量化计算。
这一过程可能包括以下步骤：1. 收集数据我们需要收集系统在不同非功能方面的数据，这可能包括性能测试数据、安全性测试数据、可靠性测试数据等。
2. 制定评估指标针对收集到的数据，我们需要制定相应的评估指标和标准，以便进行量化评估和计算。
3. 计算工作量通过对数据和评估指标的分析，我们可以计算出每个非功能需求的工作量，并根据之前划分的权重来综合评估整体的工作量。
关于非功能性需求说明书
关于非功能性需求说明书非功能性需求1) 什么是非功能性需求非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
2) 重要吗？在设计解决方案的过程中满足功能性需求当然是很重要的。
可是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
3) 非功能性需求要考虑那些方面非功能性的特性一般有这些：可靠性只显示系统能够做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：* 即使硬件出现故障，系统也能够可靠运行吗？* 复制和故障转移方案是什么？* 需要手动干预，还是系统能够自动进行故障转移？* 实现可靠性会对性能造成负面影响吗？* 实现可靠性的成本有多高？可靠性需要考虑的一些具体方面是：安全性：假设攻击者就在外面。
如何知道系统用户就是她们所声称的，并只让她们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。
不要假设始终能够进行两阶段提交 (two phase commit)。
可用性如果用户不能够从她们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，可是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？* 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？* 是否界面原来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
网站非功能需求分析报告
网站非功能需求分析报告一、引言随着互联网的迅速发展，越来越多的企业和组织开始意识到建立一个高质量的网站的重要性。
一个有效的网站不仅仅是一个展示产品和服务的平台，还应具备一系列的非功能需求，如可靠性、易用性、安全性等。
本报告将对一个网站的非功能需求进行分析和细化，旨在帮助企业和组织更好地了解和满足用户的期望和需求。
二、可靠性需求1. 可用性：网站应具有99%以上的可用性，即可在任何时间和地点访问，同时能够快速响应用户的请求。
2. 可靠性：网站应具备较高的稳定性和可靠性，能够在面对高并发访问和异常情况下依然正常运行，避免因系统故障导致的数据丢失和服务中断。
3. 容错性：网站应具备容错能力，能够在出现错误或异常情况时进行相应的错误处理和恢复机制，避免影响用户的正常使用。
三、易用性需求1. 界面简洁明了：网站的界面应简洁、清晰、直观，使用者能够迅速识别和理解其中的功能和内容。
2. 导航友好性：网站应具备良好的导航功能，提供明确的导航路径，让用户能够快速找到所需信息或功能。
3. 一致性：网站的各个页面应保持一致的设计风格和布局，使用户在不同页面之间的切换时能够有一种连续性的体验。
四、安全性需求1. 数据安全性：网站应采取适当的措施保护用户的个人数据和敏感信息，如用户账号、密码等。
2. 防止攻击：网站应具备防止各类网络攻击（如DDoS攻击、SQL注入攻击等）的能力，防止恶意用户入侵和对网站造成破坏。
3. 访问控制：网站应采用适当的权限管理措施，限制用户对敏感信息和功能的访问和操作权限，确保只授权的用户能够进行相应操作。
五、性能需求1. 响应时间：网站应具备较快的响应速度，用户的请求能够在短时间内得到相应和处理。
2. 并发性能：网站应具备较高的并发处理能力，能够同时处理多个用户的请求，避免因并发量大而导致的系统性能下降。
3. 资源利用率：网站应合理利用服务器资源，降低服务器的负载，在保证性能的前提下尽量减少资源消耗。
非功能性需求
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
安全性需求(Security Requirements) ：
1. 用户安全需求(User Security Requirements) 2. 数据安全需求(Data Security Requirements) 3. 其他安全需求(Others)
法务部门根据中国本地政策法规及知识产权及二次开发要求对相关内容进行审核 以合同方式确保上海通用的服务以及培训要求能得到充分满足
QA 文档评审
QA 团队根据前期非功能性需求报告描述，监督相关文档被正确、及时、恰当递交
技术方案评审 实施方案验收
测试方案评审 测试报告评审
验收测试
Operation 团队:参与技术方案评审和实施验收，保证系统维护性需求被正确贯彻 Info Structure 团队和 Dev. 团队:进行技术方案评审和实施方案验收，保证项目技 术方案能够囊括各类相关技术需求,并在项目中被正确贯彻实施
项目递交需求(Packaging Requirements)
© Copyright Shanghai GM Corporation 2005
Agenda
▪ 非功能性需求简介 ▪ 非功能性需求的验收策略 ▪ SGM非功能性需求的实施方案
© Copyright Shanghai GM Corporation 2005
test团队以及法务部门参与共同完成报告qaqa文档评审文档评审技术方案评审技术方案评审测试方案评审测试方案评审法务评审法务评审合同保证合同保证以合同方式确保上海通用的服务以及培训要求能得到充分满足法务评审法务评审合同保证合同保证服务服务培训培训验收测试验收测试测试报告评审测试报告评审qaqa文档评审文档评审qa团队根据前期非功能性需求报告描述监督相关文档被正确及时恰当递交测试方案评审测试方案评审测试报告评审测试报告评审验收测试验收测试test人员审核项目组提交的测试策略及测试方案test人员审核项目测试报告test人员进行有选择有针对的项目验收测试实施方案验收实施方案验收技术方案评审技术方案评审实施方案验收实施方案验收operation团队
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
© Copyright Shanghai GM Corporation 2005
Agenda
▪ 非功能性需求简介 ▪ 非功能性需求的验收策略 ▪ SGM非功能性需求的实施方案
© Copyright Shanghai GM Corporation 2005
非功能性需求的实施方案
Non-functional Standard Implement Solution
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
系统性能需求(Performance Requirements) ：
1. 系统扩展性(Scalability Requirements) 2. 系统可靠性需求(Reliability Requirements) 3. 系统可用性需求(Availability Requirements) 4. 系统容量需求及系统数据生命周期(Capacity Requirements & Data Life Cycle) 5. 系统响应 (Responsiveness Requirements) 6. 灾难恢复及业务支持(Disaster Recovery Requirements and Business Continuity
法务部门根据中国本地政策法规及知识产权及二次开发要求对相关内容进行审核 以合同方式确保上海通用的服务以及培训要求能得到充分满足
QA 文档评审
QA 团队根据前期非功能性需求报告描述，监督相关文档被正确、及时、恰当递交
技术方案评审 实施方案验收
测试方案评审 测试报告评审
验收测试
Operation 团队:参与技术方案评审和实施验收，保证系统维护性需求被正确贯彻 Info Structure 团队和 Dev. 团队:进行技术方案评审和实施方案验收，保证项目技 术方案能够囊括各类相关技术需求,并在项目中被正确贯彻实施
- 系统维护需求 - 系统易用性要求 - 系统软硬件平台及网络需求 - I18N
- 数据备份计划 - 数据维护需求
© Copyright Shanghai GM Corporation 2005
非功能性需求的验收策略
非功能性需求验收策略（续）：
▪ 应用系统 —— 验收测试
- 系统类型：SAP / J2EE / Package Solution: BS|CS|Others / Standard Alone App. / Others - 用户类型：<SGM: JQ/DY/SY/PATAC>/<GM> / <认证授权用户> / <普通用户> - 访问来源：<外网> / <内网> / <内外网>
非功能性需求的验收策略
非功能性需求验收策略：
▪ 国家政策及版权 —— 法务评审&合同保证
- 中国本地政策法规 - 知识产权及二次开发许可
▪ 文档递交件 —— QA Review
- 项目递交件清单 - 文档书写语言要求 - 递交时间、方式、介质和版权
▪ 服务承诺 —— 合同保证
- 项目实施过程中非技术要求 - 售后技术支持（远程/现场支持，5*8 / 7*24 / helpdesk，本地资源 / 中文支持）
非功能需求报告
法务评审& 合同保证(服务,培训)
技术方案评审 测试方案评审
QA 文档评审 测试报告评审
实施方案验收 验收测试
Non-Function Requirement Fulfillment Process
非功能需求 报告
法务评审、 合同保证
QA, Operation, Info Structure, Dev., Test 团队以及法务部门参与共同完成报告
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
系统运营需求(Operational Requirements) ：
1. 硬件平台需求(Hardware Requirements) 2. 软件平台需求(Software Requirements) 3. 网络需求(Network Requirements) 4. 可移植性需求(Portability Requirements) 5. 系统维护需求(System Maintenance Requirement) 6. 数据维护需求(Data Management Requirements) 7. 产品支持需求(Product Support Requirements) 8. 软件许可证需求(Software Licensing Requirements)
▪ 培训 —— 合同保证
- 培训及Knowledge Transfer计划及实施
© Copyright Shanghai GM Corporation 2005
非功能性需求的验收策略
非功能性需求验收策略（续）：
▪ 系统技术方案 —— 技术评审
- Horizon Scalability - Vertical Scalability - Failover - 安全性需求
项目递交需求(Packaging Requirements)
© Copyright Shanghai GM Corporation 2005
Agenda
▪ 非功能性需求简介 ▪ 非功能性需求的验收策略 ▪ SGM非功能性需求的实施方案
© Copyright Shanghai GM Corporation 2005
Java DEV (J2EE)
1 Stress Test
2 Volumn Test
3 Configuration Test
4 Installation Test
5 Disaster Recover Test
6 Duration Test
7 Dead Lock
8 Memory Leak
9 Coverage Report
Agenda
▪ 非功能性需求简介 ▪ 非功能性需求的验收策略 ▪ SGM非功能性需求的实施方案
© Copyright Shanghai GM Corporation 2005
非功能性需求简介
非功能性需求分类：
▪ 系统性能需求(Performance Requirements) ▪ 安全性需求(Security Requirements) ▪ 系统运营需求(Operational Requirements) ▪ 可用性需求(Usability Requirements) ▪ 国际化支持(Globalization Requirements) ▪ 项目递交需求(Packaging Requirements)
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
国际化支持(Globalization Requirements) ：
1. 中国文化及政策需求(Cultural and Political Requirements) 2. 本地化需求(Localization Requirements)
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
可用性需求(Usability Requirements) ：
1. 易操作性需求(Ease-of-Use Requirements) 2. 易用性需求(Ease-of-Learning Requirements) 3. 文档需求(Documentation Requirements) 4. 安全性需求(Safety Requirements)
Requirements)
© Copyright Shanghai GM Corporation 2005
非功能性需求简介(续)
安全性需求(Security Requirements) ：
1. 用户安全需求(User Security Requirements) 2. 数据安全需求(Data Security Requirements) 3. 其他安全需求(Others)
- 系统可移植性
ห้องสมุดไป่ตู้
- 数据时效估计 / 数据生命周期估计,数据Archive 计划 - 数据重处理要求 / 数据流完整性要求
© Copyright Shanghai GM Corporation 2005
非功能性需求的验收策略
非功能性需求验收策略（续）：
▪ 应用系统 (续) —— 验收测试
Test Type
- 系统最大可接受非正常连续停机时间：x.x working day - 系统最大可接受不可用频率：x次/year - 系统服务时间：5*8 / 7*24 - 系统数据量估计：上线时、1 年、2 年、5 年数据量估计 - 系统支持日常用户数 - 系统访问类型：平稳类 / 突发类 - 系统访问量分类估计 - 系统响应标准：既定用户数数据容量，针对不同访问操作的系统响应时间 - 系统崩溃后恢复服务的时间要求
10 Bug Trend Report
SAP PRD Line PKG BS PKG CS
系统恢复时间 < 1day 系统运行时间 7day*24h
? ?
PKG Else
Stand Alone APP
Other
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
Need Pass
Need Not Pass ? Undefined
Test 人员审核项目组提交的测试策略及测试方案 Test 人员审核项目测试报告 Test 人员进行有选择有针对的项目验收测试