文档介绍：非功能性需求1)什么是非功能性需求非功能性需求是这样一种需求,它解决“如何使这个系统能在实际环境中运行”。2)重要吗?在设计解决方案的过程中满足功能性需求当然是很重要的。但是,如果没有考虑非功能性需求,那么这个解决方案则很难取得实效,因为用户可能难以甚至无法使用系统的功能。很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。3)非功能性需求要考虑那些方面非功能性的特性一般有这些:可靠性只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行(例如,在加载时,或者在系统故障时,等等),则它就不能满足客户的需要。有一些问题应该自问一下:*即使硬件出现故障,系统也可以可靠运行吗?*复制和故障转移方案是什么?*需要手动干预,还是系统可以自动进行故障转移?*实现可靠性会对性能造成负面影响吗?*实现可靠性的成本有多高?可靠性需要考虑的一些具体方面是:安全性:假设攻击者就在外面。如何知道系统用户就是他们所声称的,并只让他们访问经过授权的功能?如何保护我的系统不受攻击?考虑到网络攻击、机器攻击,甚至从您自己的系统内部发起的攻击。事务性:如何设计系统来保存工作单元的ACID属性?如果在设计中涉及多个独立的子系统(Web服务和SOA就是这种情况),则这一点就显得特别重要。不要假设始终可以进行两阶段提交(mit)。可用性如果用户不能够从他们可用的渠道(例如Web)方便地访问您的产品,那么它的好处何在呢?这有时是作为功能性的一部分一起考虑(或者应该在理想的环境下)的,但是常常被忽视,以致于整个项目处于危险之中。这里需要考虑的一些问题是:*您是否为用户带来不适当的负担(例如,需要特殊的浏览器版本)?*系统是否根据模型-视图-控制器(Model-View-Controller)体系结构设计以使多用户界面成为可能?如果是这样,如何将它们绑定在一起?*是否界面本来就有状态而功能无状态(反之亦然)?有效性如果没有有效地使用资源(例如处理器、内存和磁盘空间),功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的,这两个子范围都应该加以考虑:性能:这个系统的运行情况有多好?它只是平稳缓慢地运行吗?系统可以达到其响应时间目标吗?应用程序的设计是否符合性能要求?您利用缓存了吗可伸缩性:如果系统在小范围内运行看起来相当快,那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢?它的设计是否达到吞吐量目标?可以复制系统来实现线性扩展吗?是否存在瓶颈(例如公共数据库)可维护性这是一个极其重要的需求,因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题,则它在首次发布之前就会夭折。假设您是一位管理员,您承担了解决此问题的任务,那么您如何配置它?如何监视它?如果您一件事情需要执行很多次(例如,安装许多应用程序),那么会怎么做呢?您是否有一个可复制的部署流程呢?您是否可以使重复的任务自动化,使之在大范围内可行呢?可移植性虽然列在最后,但它并非最不重要。例如,如何采用标准来提供某种形式的平台中立性呢?是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢?如果不打算这样做,则当供应商撤消对该版本的支持时您要怎么做呢?如果您的项目基于开放源代码,则也有类似的问题。如果每当某人有个更好的捕鼠器(mousetrap)您就必须重写整个应用