将业务信息从软件需求中剥离[3]

　　BR4：在多于三次从24小时服务窗口取款之后，账户将被冻结。

　　图四描述了在RequisitePro中这种假定的情节如何被捕获。
　　
　　

　　图四：在假定情节下，用RequisitePro描述需求到业务规则

　　由于业务规则是动态的而且受制于调整和结构性改变所带来的变化（新的产品、服务、绑定、合并、让产易股等等），所以它们能够在组织机构宽度的“规则驱动”中执行，这为 软件工程师提供了很多机会。这种规则驱动可以担当组织机构中警察的角色，并且监控组织机构中现有策略的变化。例如，正如图五所描述的，银行决定提高取款的限制。通过与软件需求的联结，产生了一个疑点，它清晰的向软件工程师指出哪一个软件需求受到了影响。

　　在面向对象的软件设计中，由于业务规则被分派给对象，所以这种想法可以很好的得到实现。图五展示了这是如何在RequisitePro中呈现的。
 
　　
　　　　图五：描述业务规则到软件需求中的改变

　　非功能需求

　　非功能需求（NFRs）往往以“系统应该是……”这样的短语开始，紧接着使用“快速”、“易于使用”、“直观好学”等形容词，它们经常同其他需求类型混在一起。传统意义上，非功能需求适用于整个系统，例如“系统应该是用128位加密码保障安全性的”或者“系统应当提供两秒钟的反应时间”等等。但是，情况并非总是如此。

　　许多用户通过“系统”体验人机交互界面。图形用户界面因此成为一项颇受非技术涉众欢迎的条款。例如：

　　应该可以轻易地看到保险政策的历史。

　　在这个陈述中有两个问题使得需求变得复杂：

　　功能性（历史）同非功能性（易于使用）混杂在一起。

　　“易于”是一个主观的概念，是无法详细描述的。
　　非功能性需求的陈述经常是没有被明确定义的，这使得它们很难被估量和测试。在这个特定的例子中，我要通过问清楚“易于”这个词来确定这个需求是对于整个系统都有效，还是仅仅同例子中政策的历史这一功能结合在一起。

　　细节中的可用性需求表现了个人的风格和品位；并不是所有的需求都会吸引所有的涉众。细心筛选那些适用于大多数用户以及你的赞助商的需求。有时，可看可感的 标准和规范可以避免关于颜色、字体以及导航等问题的长时间的争论。你是如何看待下面这份需求陈述的呢？它是用于控制一台核能设备还是一种单人纸牌游戏呢？

　　系统应该是可靠的。

　　在系统中将功能性和非功能性分离是很重要的，同样，像下面这个例子中那样给予非功能性适当的范围也很重要。

　　SR1：系统应当捕获所有政策变化的历史信息。

　　NFR1: 政策的历史应当很容易被找回。品质（鼠标点击数）：

　　容易 - 0次
　　可以 - 1次
　　不容易 - 2次或者更多

　　约束

　　当非功能性需求的陈述包含词语“必须”时，通常是表明一个或更多的约束适用于整个系统；例如，遵守指导方针、法律或者行业规范。约束应当被从其他需求类型中分离出来，同其他类型的非功能需求一样被来区别对待。例如：

　　C1： 系统必须遵守某某管理法令。
　　C2： 系统必须能够容忍故障发生。
　　（品质：系统崩溃次数/星期）
　　非常好：0-1
　　可以接受：2-5
　　不可接受：>5

　　用例设计

　　关于用例的书已经出了不少，它们论述了用例的风格、深度以及细节。我不打算再介绍这些题目，而是要阐明如何将业务用例同系统用例分开记录。

　　我们来考虑一个实际的例子。假设我们要为旅馆搭建一个前台终端设备。这家旅馆起初都是通过手工流程操作。钥匙、日历本、擦除器和钢笔都是前台需要用到的工具。在我们开始规划未来的前台应用程序之前，首先来看一看当前已经存在的用例，也被称作当前场景。这个业务用例的程序“顾客登记”是这样的：

原文转自：http://www.ltesting.net