非功能性需求很重要的原因

非功能性需求很重要的原因

不要脱离实际环境

有时,我们会因为读到一篇文章或一本书,或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下,人们只讨论一些技术、解决方案和选项的某些方面,而忽视了一个至关重要的问题:非功能性需求。

诚然,功能性是非常重要的。毕竟,如果您不能展示您构建的系统实现了您想要的功能,那么谁会有兴趣呢?采取一种新颖、巧妙、更简单、更漂亮或更得体的方法来解决某种问题固然很好,但是如果您没有考虑非功能性需求,则您的解决方案可能无法取得实效

我们都碰到过这样的情况,许多解决方案虽然合理,但是当真正考虑将它们用于大型系统的实际环境,而管理这些系统的人员又非常忙时,它们就变得很荒谬可笑了。造成这些灾难的原因是不重视或忽略了系统的非功能性需求。

非功能性需求是这样一种需求,它不一定解决“我想要我的系统实现这种功能”,而是解决“如何使这个系统能在实际环境中运行”。对于这些实际环境,您很少听到人们提及的一些问题是:

  • 对在线系统的请求过多:用户太多了,全都在一块了!

  • 部署应用程序的管理员负担过大:在实际环境中,管理员对每个应用程序都将部署多次,而在部署之后必须对每一个应用程序进行监视。

  • 管理员会犯错误:毕竟,我们大多数都是普通人!虽然无差错地执行 100 次手动部署步骤在理论上是可能的,但是实际环境中没有出现过。

  • 会有恼人的脚本小子 (script kiddy) 和真正的破解高手攻击我们的系统:安全是多么重要啊!

所以,什么是非功能性需求呢?我们可以找到许多很好的定义,不过,我们首先来看 Software Characteristics 的 ISO 9126 列表;除功能性(这是理所当然的)以外,这些特性包括:

  • 可靠性

    只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行(例如,在加载时,或者在系统故障时,等等),则它就不能满足客户的需要。

    有一些问题应该自问一下:

    • 即使硬件出现故障,系统也可以可靠运行吗?
    • 复制和故障转移方案是什么?
    • 需要手动干预,还是系统可以自动进行故障转移?
    • 实现可靠性会对性能造成负面影响吗?
    • 实现可靠性的成本有多高?

    可靠性需要考虑的一些具体方面是:

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

    • 事务性:如何设计系统来保存工作单元的 ACID 属性?如果在设计中涉及多个独立的子系统(Web 服务和 SOA 就是这种情况),则这一点就显得特别重要。不要假设始终可以进行两阶段提交 (two phase commit)。

  • 可用性

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

    • 您是否为用户带来不适当的负担(例如,需要特殊的浏览器版本)?
    • 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能?如果是这样,如何将它们绑定在一起?
    • 是否界面本来就有状态而功能无状态(反之亦然)?
  • 有效性

    如果没有有效地使用资源(例如处理器、内存和磁盘空间),功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的,这两个子范围都应该加以考虑:

    • 性能:这个系统的运行情况有多好?它只是平稳缓慢地运行吗?系统可以达到其响应时间目标吗?应用程序的设计是否符合性能要求?您利用缓存了吗?

    • 可伸缩性:如果系统在小范围内运行看起来相当快,那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢?它的设计是否达到吞吐量目标?可以复制系统来实现线性扩展吗?是否存在瓶颈(例如公共数据库)?

  • 可维护性

    这是一个极其重要的需求,因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题,则它在首次发布之前就会夭折。假设您是一位管理员,您承担了解决此问题的任务,那么您如何配置它?如何监视它?如果您一件事情需要执行很多次(例如,安装许多应用程序),那么会怎么做呢?您是否有一个可复制的部署流程呢?您是否可以使重复的任务自动化,使之在大范围内可行呢?

  • 可移植性

    虽然列在最后,但它并非最不重要。例如,如何采用标准来提供某种形式的平台中立性呢?是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢?如果不打算这样做,则当供应商撤消对该版本的支持时您要怎么做呢?如果您的项目基于开放源代码,则也有类似的问题。如果每当某人有个更好的捕鼠器 (mousetrap) 您就必须重写整个应用程序,则没有人会问津。

在完美的世界中,我们希望每篇文章、论文、红皮书、幻灯片和系统设计都率先解决这些重要问题。它们非常重要。差不多始终都要进行一些折衷,它们应该显式进行以便确定特定的设计是否符合您的需要。如果您阅读的文章没有解决这些问题,将这作为我们的警告——一些重要的东西往往会被忽视。如果您是一位作者,请考虑我们的恳求:不要忽视这些问题!

原文地址如下:
英文:http://www-128.ibm.com/developerworks/websphere/techjournal/0601_col_bobrha/0601_col_bobrha.html
中文:http://www-128.ibm.com/developerworks/cn/websphere/techjournal/0601_col_bobrha/0601_col_bobrha.html