关于非功能性需求说明书
非功能需求文档
易宝电脑系统(中国)有限公司<项目名称>非功能需求文档版本 <1.0>版权所有, 未经双方许可不得复制或允许第三方传阅修订历史记录审批记录目录1.简介51.1目的51.2范围51.3定义、首字母缩写词和缩略语51.4参考资料52.非功能需求52.1运行环境52.2可用性52.2.1<可用性需求一> 62.2.2 (6)2.3安全性62.3.1<安全性需求一> 62.3.2 (6)2.4可靠性62.4.1<可靠性需求一> 72.4.2 (7)2.5性能72.5.1<性能需求一> 72.5.2 (7)2.6可支持性72.6.1<可支持性需求一> 72.6.2 (7)2.7设计约束72.7.1<设计约束一> 82.7.2 (8)2.8联机用户文档和帮助系统需求82.9购买的构件82.10接口82.10.1用户界面82.10.2硬件接口82.10.3软件接口82.10.4通信接口8非功能需求文档1.简介1.1目的说明编写这份说明书的目的，指出预期的读者。
1.2范围说明本文档所描述的范围和受其影响的事物和文档。
1.3定义、首字母缩写词和缩略语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料列出用得着的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2.非功能需求2.1运行环境说明产品需要的运行环境，例如：硬件、软件、通讯等的配置。
（这部分内容必须有。
）2.2可用性此节应包括所有影响可用性的需求。
例如，指出普通用户和高级用户要高效地执行特定操作所需的培训时间指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求（这部分内容必须有。
非功能需求说明书示例
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.1文档目的为了明确客户的基本需求，更好地完成对客户需求的了解，并量化和明晰本系统的工作量和工作进度，特编写此说明书。
1.2文档范围该文档包括产品售后服务系统项目的介绍、面向的用户群体、系统的功能性需求及非功能性需求。
1.3读者对象本手册适用于与客户进行需求的沟通与确认，及所有《产品售后服务跟踪系统》的设计开发人员。
2系统介绍2.1背景随着信息技术的日益发展，产品售后服务的信息化已成为产品售后服务跟踪系统的必然趋势。
产品售后服务系统的核心部分是对客户进行回访问卷调查，以确定客户对产品的评价，服务的满意度。
为了更详细的了解产品售后服务过程中各项管理业务，调研人员和最终用户进行了多次讨论，并提出了双方认可的解决方案。
2.2系统说明产品售后服务跟踪系统主要为公司解决售后服务管理的需求，协助回访工作人员对客户进行日常回访调查和客户管理，提高管理效率，降低运作成本，增强企业长期竞争力。
经由过程该系统，公司系统管理人员能实现对回访用户、客户的静态管理；系统管理人员能随时了解回访用户的回访情况；回访用户能记录客户的回访记录；3.系统面向的用户群体系统面向产品公司的售后效劳管理员，回访用户。
3.1用户的特征用户多数具有以下特征：●有IE使用经验●了解网络●了解办公主动化3.2用户环境用户的计算机环境大致如下：●XXX Windows XP●XXX Internet Explorer 6或更高版本●MS Office办公软件●Outlook或Foxmail邮件管理●Microsoft Windows。
NET Framework 2.04.系统的功能性需求系统包含的功能概括如下表：功能子功能功能细化录入回访用户信息查询回访用户信息用户中心回访用户管理修改回访用户信息删除回访用户信息修改回访用户密码录入问卷信息修改问卷信息删除问卷信息查询问卷信息填写问卷信息问卷管理问卷调查回访情况记录修改问卷提交信息查看问卷提交信息录入客户信息修改客户信息删除客户信息查询客户信息查询所有回访情况信息查询成功回访情况信息查询未成功回访情况信息客户资料中心客户资料管理回访情况查询客户数据分配查看自动分配信息查询回访情况统计信息打印回访情况统计信息报表统计4.1用户中心4.1.1用例用户中心检察回访用户信息修改回访用户密码回访用户查看回访用户信息用户录入回访用户信息修改回访用户信息系统管理用户删除用户信息4.1.2用例描绘用例名称：录入回访用户信息用例简述：系统管理员录入回访用户信息主参与者：系统管理员主要场景：1、系统管理员输入回访用户信息2、系统管理员提交回访用户息其他场景：如果回访用户已存在，系统提示回访用户已存在用例名称：修改回访用户信息用例简述：系统管理员修改回访用户信息主参与者：系统管理员主要场景：1、系统管理员查询回访用户信息列表，选择需要修改的具体回访用户信息2、系统管理员修改局部信息，提交修改信息其他场景：如果回访用户已存在，系统提示回访用户已存在用例名称：查询回访用户信息用例简述：系统管理员查询回访用户信息主参与者：系统管理员主要场景：1、系统管理员输入查询条件2、系统管理员查询回访用户信息用例称号：删除回访用户信息用例简述：系统管理员删除回访用户信息主参与者：系统管理员主要场景：1、系统管理员挑选要删除的回访用户信息，删除回访用户信息其他场景：如果回访用户另有客户未回访，系统提示因回访用户另有客户未回访删除失败用例称号:检察个人信息用例简述：回访用户查看回访用户个人信息主参与者：回访用户主要场景：1、回访用户检察回访用户个人信息用例称号：修改用户密码用例简述：回访用户修改回访个人密码主参与者：回访用户主要场景：1、回访用户密码泄露或者安全性不高需要修改密码4.2客户资料中心4.2.1用例4.2.2用例描述用例名称：添加客户信息用例简述：系统管理员录入客户信息主参与者：系统管理员主要场景：1、系统管理员输入客户信息2、有新客户购买产品需要录入信息用例称号：修改客户信息用例简述：系统管理员修改客户信息主参与者：系统管理员主要场景：1、客户信息有误需要修改客户信息2、客户信息变更需要修改客户信息用例名称：查询客户信息用例简述：系统管理员查询客户信息主参与者：系统管理员主要场景：1、系统管理员挑选查询前提查询客户信息用例称号：删除客户信息用例简述：系统管理员删除客户信息主参与者：系统管理员主要场景：1、客户不配合回访用户售后服务2、把售后服务已经过期的客户信息删除3、客户填写不精确信息用例称号：查询回访情况用例简述：回访用户查询回访情况主参与者：回访用户主要场景：1、回访用户选择查询条件2、回访用户查询回访情况信息4.3问卷调查4.3.1用例问卷调查问卷管理录入问卷信息修改问卷信息删除问卷信息系统管理员查询问卷信息回访情况记录用户填写问卷信息修改问卷提交信息回访用户检察问卷提交信息4.2.2用例描绘用例称号：录入问卷信息用例简述：系统管理员录入问卷信息主参与者：系统管理员主要场景：1、系统管理员输入问卷信息2、系统管理员提交问卷信息用例名称：修改问卷信息用例简述：系统管理员修改问卷信息主参与者：系统管理员主要场景：1、系统管理员查询问卷信息列表，挑选需要修改的详细问卷信息2、系统管理员修改问卷信息，提交修改信息3、根据市场需求修改问卷信息用例名称：查询问卷信息用例简述：系统管理员查询问卷信息主参与者：系统管理员主要场景：1、系统管理员输入查询条件2、系统管理员查询问卷信息用例名称：删除问卷信息用例简述：系统管理员删除问卷信息主参与者：系统管理员主要场景：1、系统管理员挑选要删除的问卷信息，删除问卷信息用例名称：提交问卷用例简述：回访用户根据对的客户调查填写提交问卷主参与者：回访用户主要场景：1、回访用户填写问卷信息2、回访用户提交问卷信息用例称号：修改问卷提交信息用例简述：回访用户修改问卷提交信息主参与者：回访用户主要场景：1、回访用户填写的问卷信息有误需要修改用例称号：检察问卷提交信息用例简述：回访用户检察提交的问卷信息主参与者：回访用户主要场景：1、回访用户需要检察问卷的提交情况4.4客户数据分配4.4.1用例4.2.2用例描述用例称号：检察主动分配信息用例简述：回访用户检察所分配的客户数主参与者：回访用户主要场景：1、回访用户需要知道自己分配的客户数及客户信息4.5报表统计4.5.1用例4.2.2用例描绘用例名称：查询回访情况统计信息用例简述：系统管理员可以查询在一定时间内回访总数及各种情况数量主参与者：系统管理员主要场景：1、系统管理员输入查询前提检察回访情况统计信息用例称号：打印回访情况统计信息用例简述：系统管理员打印回访情况统计信息主参与者：系统管理员。
业务需求—03非功能性需求模版
业务需求—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.软件兼容性：系统或软件需要适配不同操作系统、不同浏览器等软件环境。
需求文档中-非功能性需求
安全性数据库存储密码，业务敏感信息加密。
日志内容不包含密码和业务敏感数据。
敏感业务接口报文加密。
防止重复提交。
程序防范脚本注入,DDOS，权限控制。
数据完整。
性能吞吐量：系统在并发用户300时，系统表现稳定。
系统响应时间不超过10s；支持同时在线人数10万。
在95％的情况下，排除第三方接口问题，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。
在推荐配置环境下页面刷新时间在2秒内。
CPU平均占用率<70%。
内存平均占用率<70%。
容量日志保留时间至少30天。
日志总容量最大20G。
数据库最大容量支持25G 。
可访问性APP兼容机型。
浏览器兼容版本。
可操作性要求客户端页面无明显卡顿现象，页面美观，界面风格保持一致，界面元素排列整齐，界面元素保持一致性，合理运用页面空白区域，页面字体及颜色清晰、简约明了；页面界面简单明了，菜单指示明确，用户操作变得舒适、简单、自由、充分体现软件的定位和特点。
可靠性故障恢复要求:系统日间本地RTO(复原时间目标): 12小时。
系统批量期间本地RTO(复原时间目标): 12小时。
系统日间本地RPO(复原点目标): 1分钟。
系统批量期间本地RPO(复原点目标)： 1分钟。
容错性：系统出错。
不影响功能清单。
系统故障：每日不超过10次，故障总时间不超过5分钟。
故障重启时间不超过1分钟。
合法性软件遵循相关法律，无侵权行为。
关于非功能性需求说明书
非功能性需求1) 什么是非功能性需求非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
2) 重要吗？在设计解决方案的过程中满足功能性需求当然是很重要的。
但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
3) 非功能性需求要考虑那些方面非功能性的特性一般有这些：可靠性只显示系统可以做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：* 即使硬件出现故障，系统也可以可靠运行吗？* 复制和故障转移方案是什么？* 需要手动干预，还是系统可以自动进行故障转移？* 实现可靠性会对性能造成负面影响吗？* 实现可靠性的成本有多高？可靠性需要考虑的一些具体方面是：安全性：假设攻击者就在外面。
如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。
不要假设始终可以进行两阶段提交 (twophase commit)。
可用性如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？* 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？* 是否界面本来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
关于非功能性需求说明书
关于非功能性需求说明书非功能性需求1) 什么是非功能性需求非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
2) 重要吗？在设计解决方案的过程中满足功能性需求当然是很重要的。
可是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
3) 非功能性需求要考虑那些方面非功能性的特性一般有这些：可靠性只显示系统能够做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：* 即使硬件出现故障，系统也能够可靠运行吗？* 复制和故障转移方案是什么？* 需要手动干预，还是系统能够自动进行故障转移？* 实现可靠性会对性能造成负面影响吗？* 实现可靠性的成本有多高？可靠性需要考虑的一些具体方面是：安全性：假设攻击者就在外面。
如何知道系统用户就是她们所声称的，并只让她们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。
不要假设始终能够进行两阶段提交 (two phase commit)。
可用性如果用户不能够从她们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，可是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？* 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？* 是否界面原来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
非功能性需求
© 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团队
业务需求说明书_非功能性需求
业务需求说明书_非功能性需求业务需求说明书非功能性需求文档标识项目名称文档名称文档存放位置版本号文档状态文档更改记录版本日期描述修改人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。
非功能性需求
模块级安全保证是第三层保护。它保证授权用户在进入某一功能模块后，只能做其用户级别所允许的操作。用户安全性列表中的用户级别（ULV）是用户拥有的某一具体权力属性的使用级别。使用级别由低到高，用户对该模块的操作权力也就由小变大，随着级别的变化，用户所面对的操作界面也会自动裁剪变化。譬如说，该用户对本职业务功能是高级使用者，但对相关业务功能则可能只是普通使用者，对这些模块的修改与删除功能就会对他屏蔽，相应控件会不可见。
设计要求
先进实用性：采用先进的思想、成熟的技术与设计方法，符合当前潮流与未来发展趋势，以便跟上信息技术的发展，具有较强的生命力，具有长期使用价值。XXXX建设的核心目的就是“沟通”，同时须坚持实用的设计原则，紧紧围绕学校的实际需求。在能够满足XXXX建设要求的前提下，以尽可能以少的投入，取得尽可能大的效益。
数字图书馆主要优点
网络管理轻松便捷：
传统的C/S架构系统中，管理员对系统的管理操作是非常麻烦的，必须要求管理员坐到服务器前，通过专门的软件，才能完成系统维护。如果管理员一时不在服务器附近，无法操作服务器计算机，则无法进行系统维护。 电子图书馆系统采用真正桌面虚拟化架构， 这就解脱了这种维护上的麻烦。管理员不必固守服务器前，他只需要维护主机，仅通过桌面整理即可完成整套系统的管理工作。电子图书馆系统实际上是三套产品的集合体，其一是电子图书的管理和浏览系统；其二则是纸质图书的预借和借阅系统；其三则是纸质图书的在线预售系统。 由于系统采用桌面虚拟化架构，客户端的所有的操作都可以通过浏览 器完成，无需安装其它的应用程序。这样管理员再也不用随身附带必要的工具软件，在主机上即可完成所有的操作。
数字图书馆具有以下五大主要特点：（1）、信息资源数字化： 数字图书馆利用现代信息技术和网络通讯技术，将分散在不同地域的各类传统介质的文献信息进行压缩处理并转化为数字信息。
非功能性需求范例
1、性能需求描述案例：响应时间：在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。
定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。
在网络畅通时，拨号连接GPRS网络所需时间不得超过5秒。
在网络畅通时，电子地图刷新时间不超过10秒。
在推荐配置环境下：登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。
在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。
业务量：每日最大成交数3000笔业务。
平均交易并发数为20，最大交易并发数为50。
估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。
系统可以同时满足10,000个用户请求，并为25,000个并发用户提供浏览功能。
系统容量：支持3万用户，支持GB级数据。
数据库表行数不超过100万行，数据库最大容量不超过1000GB，磁盘空间至少需要40G以上。
精度：定位精度误差不超过80米。
当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。
计算的精确性到小数点后7位。
资源使用率：CPU占用率<=50%。
内存占用率<=50%。
2、安全需求描述案例：严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。
不同的用户具有不同的身份和权限，需要在用户身份真实可信的前提下，提供可信的授权管理服务，保护数据不被非法/越权访问和篡改，要确保数据的机密性和完整性。
提供运行日志管理及安全审计功能，可追踪系统的历史使用情况。
能经受来自互联网的一般性恶意攻击。
如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等。
至少99%的攻击需要在10秒内检测到。
3、可靠性需求描述案例：对输入有提示，数据有检查，防止数据异常。
系统健壮性强，应该能处理系统运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统应该能正确的处理，恰当的回避。
非功能性需求
非功能性需求
1.易用性
本系统是人机交互的系统，要求系统在操作上方便简单，并力求达到界面上的美观，避免和以往那些一板一眼的老式教学平台雷同，争取做到界面上的新颖，一改之前的呆板，注入一些活力，实现用户界面友好。
2.可靠性
由于系统需要有较高的可靠性，在系统出现错误时，要求应用系统能报告相应的详细错误信息或原因给操作员，或者老师或学生给管理员留言，提示错误和问题，以便理解与分析。
最好能够给出一个解决方案。
3.性能
要求并发访问用户数最多只能达到500个（需要Web服务器的配置支持）。
可查询数据应在系统能够承受的范围内尽可能保持实时。
4.可维护性
系统的基本维护必须简单，不要求需专业技术人员进行维护，通过一般的技术维护人员操作系统的维护功能，即可达到基本的维护目的，例如：数据备份、恢复；数据导入/导出等维护性操作。
5.安全性
在硬件方面可考虑采用性能优异的防火墙，根据规则过滤或代理应用数据包，防止非法网络活动。
系统方面对访问系统的用户分权限管理，系统管理员拥有对系统所有的权限，用户只能进行某些特定的功能的操作。
防止未授权用户的非法登陆，并对用
户对系统的操作做好记录，有利于在发现系统故障时快速查找原因。
6.可扩展性
系统在软、硬件方面应具有良好的可扩展性，这样，在系统需要升级或者二次开发时，才能较好地保护投资。
产品的非功能性需求
6.产品的非功能性需求
6.1软硬件环境需求
硬件：
我们是用小组成员电脑做成的，做该系统最多用了100M的空间，包括资料的存储、系统资料的存储以及系统的存储等。
我们主要都是用VF软件编写代码，其余的也要用word、photoshop、excel 做一些文字、图表和表格的制作。
该系统采用现代流行WINDOWS操作界面。
是标准的WIN32应用程序，可运行在WIN95\WIN98\WinMe\WIN2000\WINXP\WINNT等系统平台上的多任务应用程序。
6.2产品质量需求
6.3参考资料
《软件工程》清华大学出版社钱乐秋编著
《数据库系统概论(第三版)》高等教育出版社萨师煊王珊《计算机网络(第二版)》清华大学出版社吴功宜编著。
关于非功能性需求说明书
非功能性需求1) 什么是非功能性需求非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
2) 重要吗？在设计解决方案的过程中满足功能性需求当然是很重要的。
但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
3) 非功能性需求要考虑那些方面非功能性的特性一般有这些：可靠性只显示系统可以做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：* 即使硬件出现故障，系统也可以可靠运行吗？* 复制和故障转移方案是什么？* 需要手动干预，还是系统可以自动进行故障转移？* 实现可靠性会对性能造成负面影响吗？* 实现可靠性的成本有多高？可靠性需要考虑的一些具体方面是：安全性：假设攻击者就在外面。
如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。
不要假设始终可以进行两阶段提交 (two phase commit)。
可用性如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？* 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？* 是否界面本来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
非功能性方案
非功能性方案摘要：本文将讨论非功能性方案的重要性，并提供一些实施非功能性方案的案例。
非功能性方案是指在软件开发和系统设计过程中，针对系统整体的性能、可用性、安全性等方面的需求进行规划和实施的解决方案。
通过合理的非功能性方案设计，能够保证系统在实际运行中的稳定性和性能表现。
在本文中，我们将探讨几个重要的非功能性方案，并介绍一些实际案例，以帮助读者更好地理解和应用这些方案。
1. 引言非功能性方案是指在软件开发和系统设计过程中，为了满足系统整体的性能、可用性、安全性等方面的需求而进行的规划和实施。
相比于功能性需求，非功能性需求通常更加抽象和宽泛，不容易直接定义和衡量。
然而，合理的非功能性方案设计对于系统的稳定性和性能表现至关重要。
本文将重点讨论几个常见的非功能性需求，并提供一些实际案例。
2. 性能性能是指系统在特定环境下对任务执行的效率和速度。
为了确保系统的性能表现，我们需要考虑以下几个方面：2.1 硬件资源规划系统的性能往往受限于硬件资源的配置。
我们需要评估并规划合适的硬件资源，以满足系统的性能需求。
例如，如果系统需要处理大量的数据，我们可能需要考虑使用更高性能的服务器和存储设备。
2.2 软件优化除了硬件资源之外，软件的编写和设计也对系统的性能有重要影响。
我们需要注意避免不必要的计算和数据访问，优化算法和代码结构，以提高系统的性能。
2.3 性能监控与调优性能监控和调优是确保系统持续高效运行的关键。
我们可以使用性能监控工具来收集系统的关键指标，并分析和优化系统的性能。
实际案例：某电商网站在大促期间的用户访问量激增，为了保证系统的性能表现，他们对服务器进行了水平扩展，并对数据库进行了优化，最终成功应对了高并发的访问压力。
3. 可用性可用性是指系统在特定条件下的可访问性和稳定性。
以下是一些提高系统可用性的方案：3.1 高可用架构设计高可用性架构设计可以保证系统的容错能力和故障恢复能力。
常见的高可用性方案包括多服务器冗余、负载均衡和故障转移等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
非功能性需求
) 什么是非功能性需求
非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。
) 重要吗？
在设计解决方案的过程中满足功能性需求当然是很重要的。
但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。
很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。
) 非功能性需求要考虑那些方面
非功能性的特性一般有这些：
可靠性
只显示系统可以做某些事情是不够的。
如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。
有一些问题应该自问一下：
* 即使硬件出现故障，系统也可以可靠运行吗？
* 复制和故障转移方案是什么？
* 需要手动干预，还是系统可以自动进行故障转移？
* 实现可靠性会对性能造成负面影响吗？
* 实现可靠性的成本有多高？
可靠性需要考虑的一些具体方面是：
安全性：假设攻击者就在外面。
如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
事务性：如何设计系统来保存工作单元的属性？如果在设计中涉及多个独立的子系统（服务和就是这种情况），则这一点就显得特别重要。
不要假设始终可以进行两阶段提交 ( )。
可用性
如果用户不能够从他们可用的渠道（例如）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。
这里需要考虑的一些问题是：
* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？
* 系统是否根据模型视图控制器 () 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？
* 是否界面本来就有状态而功能无状态（反之亦然）？
有效性
如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。
我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加
以考虑：
性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗
可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）
可维护性
这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。
假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？
可移植性
虽然列在最后，但它并非最不重要。
例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。
如果
每当某人有个更好的捕鼠器 () 您就必须重写整个应用程序，则没有人会问津。
作为一个公司，就有一定的工作量存在，而员工的工作效率与公司的任务完成量息息相关。
而员工的个人信息、通讯薄，它的工作量可能是其它信息工作量的几倍，会议的增加、会议室的查询、个人信息的修改；工作管理；统计等等，每个信息的数据都在不断地变化着，如果采用人工的方式进行操作，那么，一天的工作量，足以让人觉得比较繁琐，吃不消。
针对这样的情况，采用让数据的查询变得简单化，数据变的更让每个人都在任何时刻都可以了解到。
旋风协同办公系统是为公司开发的，本系统所采用的语言是，用数据库完成。
该系统总体有五个部分组成，包括个人信息、通讯薄、共作管理、会议室管理、会议管理。
通过本系统，把公司内部查询员信息、会议信息、会议信息各个环节进行有效地计划、组织和控制。
通过收集的相关信息，依据统一数据信息进行管理，把任何一块信息所产生的数据变动及时地反映给其它相关信息，做到数据共享。
本系统主要信息流程为：系统信息维护接受管理员的登陆信息，员工信息查询根据管理员信息维护的员工信息做出对所接收的信息合理性进行判断，并交于信息维护进行相应的修改，再把信息存入数据库中。
采用本系统，能够使整个系统内部所有信息的工作简化，提高工作效益。
由于采用统一的数据信息，使相关资料能够快速地查询所需的数据、资料及其它信息的，使信息快速高效运行。
游云芳
软件产品的非功能性需求定义
软件产品的需求可以分为功能性需求和非功能性需求，其中非功能性需求是常常被轻视，甚至被忽视的一个重要方面。
其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。
如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。