关于非功能性需求说明书.pdf

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