关于非功能性需求说明书

合集下载

非功能需求文档

非功能需求文档

易宝电脑系统(中国)有限公司<项目名称>非功能需求文档版本 <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非功能性需求模版

业务需求—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) 体系结构设计以使多用户界面成为可能?如果是这样,如何将它们绑定在一起?* 是否界面原来就有状态而功能无状态(反之亦然)?有效性如果没有有效地使用资源(例如处理器、内存和磁盘空间),功能性、可靠性和可用性再好的系统最后都会失败。

非功能性需求

非功能性需求
Requirements)
© 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. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

非功能性需求
) 什么是非功能性需求
非功能性需求是这样一种需求,它解决“如何使这个系统能在实际环境中运行”。

) 重要吗?
在设计解决方案的过程中满足功能性需求当然是很重要的。

但是,如果没有考虑非功能性需求,那么这个解决方案则很难取得实效,因为用户可能难以甚至无法使用系统的功能。

很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。

) 非功能性需求要考虑那些方面
非功能性的特性一般有这些:
可靠性
只显示系统可以做某些事情是不够的。

如果一个系统不能可靠地运行(例如,在加载时,或者在系统故障时,等等),则它就不能满足客户的需要。

有一些问题应该自问一下:
* 即使硬件出现故障,系统也可以可靠运行吗?
* 复制和故障转移方案是什么?
* 需要手动干预,还是系统可以自动进行故障转移?
* 实现可靠性会对性能造成负面影响吗?
* 实现可靠性的成本有多高?
可靠性需要考虑的一些具体方面是:
安全性:假设攻击者就在外面。

如何知道系统用户就是他们所声称的,并只让他们访问经过授权的功能?如何保护我的系统不受攻击?考虑到网络攻击、机器攻击,甚至从您自己的系统内部发起的攻击。

事务性:如何设计系统来保存工作单元的属性?如果在设计中涉及多个独立的子系统(服务和就是这种情况),则这一点就显得特别重要。

不要假设始终可以进行两阶段提交 ( )。

可用性
如果用户不能够从他们可用的渠道(例如)方便地访问您的产品,那么它的好处何在呢?这有时是作为功能性的一部分一起考虑(或者应该在理想的环境下)的,但是常常被忽视,以致于整个项目处于危险之中。

这里需要考虑的一些问题是:
* 您是否为用户带来不适当的负担(例如,需要特殊的浏览器版本)?
* 系统是否根据模型视图控制器 () 体系结构设计以使多用户界面成为可能?如果是这样,如何将它们绑定在一起?
* 是否界面本来就有状态而功能无状态(反之亦然)?
有效性
如果没有有效地使用资源(例如处理器、内存和磁盘空间),功能性、可靠性和可用性再好的系统最后都会失败。

我们经常发现将有效性划分成两个子范围是很有用的,这两个子范围都应该加
以考虑:
性能:这个系统的运行情况有多好?它只是平稳缓慢地运行吗?系统可以达到其响应时间目标吗?应用程序的设计是否符合性能要求?您利用缓存了吗
可伸缩性:如果系统在小范围内运行看起来相当快,那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢?它的设计是否达到吞吐量目标?可以复制系统来实现线性扩展吗?是否存在瓶颈(例如公共数据库)
可维护性
这是一个极其重要的需求,因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题,则它在首次发布之前就会夭折。

假设您是一位管理员,您承担了解决此问题的任务,那么您如何配置它?如何监视它?如果您一件事情需要执行很多次(例如,安装许多应用程序),那么会怎么做呢?您是否有一个可复制的部署流程呢?您是否可以使重复的任务自动化,使之在大范围内可行呢?
可移植性
虽然列在最后,但它并非最不重要。

例如,如何采用标准来提供某种形式的平台中立性呢?是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢?如果不打算这样做,则当供应商撤消对该版本的支持时您要怎么做呢?如果您的项目基于开放源代码,则也有类似的问题。

如果
每当某人有个更好的捕鼠器 () 您就必须重写整个应用程序,则没有人会问津。

作为一个公司,就有一定的工作量存在,而员工的工作效率与公司的任务完成量息息相关。

而员工的个人信息、通讯薄,它的工作量可能是其它信息工作量的几倍,会议的增加、会议室的查询、个人信息的修改;工作管理;统计等等,每个信息的数据都在不断地变化着,如果采用人工的方式进行操作,那么,一天的工作量,足以让人觉得比较繁琐,吃不消。

针对这样的情况,采用让数据的查询变得简单化,数据变的更让每个人都在任何时刻都可以了解到。

旋风协同办公系统是为公司开发的,本系统所采用的语言是,用数据库完成。

该系统总体有五个部分组成,包括个人信息、通讯薄、共作管理、会议室管理、会议管理。

通过本系统,把公司内部查询员信息、会议信息、会议信息各个环节进行有效地计划、组织和控制。

通过收集的相关信息,依据统一数据信息进行管理,把任何一块信息所产生的数据变动及时地反映给其它相关信息,做到数据共享。

本系统主要信息流程为:系统信息维护接受管理员的登陆信息,员工信息查询根据管理员信息维护的员工信息做出对所接收的信息合理性进行判断,并交于信息维护进行相应的修改,再把信息存入数据库中。

采用本系统,能够使整个系统内部所有信息的工作简化,提高工作效益。

由于采用统一的数据信息,使相关资料能够快速地查询所需的数据、资料及其它信息的,使信息快速高效运行。

游云芳
软件产品的非功能性需求定义
软件产品的需求可以分为功能性需求和非功能性需求,其中非功能性需求是常常被轻视,甚至被忽视的一个重要方面。

其实,软件产品非功能性定义不仅决定产品的质量,还在很大程度上影响产品的功能需求定义。

如果事先缺乏很好的非功能性需求定义,结果往往是使产品在非功能性需求面前捉襟见肘,甚至淹没功能性需求给用户带来的价值。

相关文档
最新文档