BR4：在多于三次从24小时服务窗口取款之后，账户将被冻结。
图四描述了在RequisitePro中这种假定的情节如何被捕获。
图四：在假定情节下，用RequisitePro描述需求到业务规则
由于业务规则是动态的而且受制于调整和结构性改变所带来的变化（新的产品、服务、绑定、合并、让产易股等等），所以它们能够在组织机构宽度的“规则驱动”中执行，这为 软件工程师提供了很多机会。这种规则驱动可以担当组织机构中警察的角色，并且监控组织机构中现有策略的变化。例如，正如图五所描述的，银行决定提高取款的限制。通过与软件需求的联结，产生了一个疑点，它清晰的向软件工程师指出哪一个软件需求受到了影响。
在面向对象的软件设计中，由于业务规则被分派给对象，所以这种想法可以很好的得到实现。图五展示了这是如何在RequisitePro中呈现的。
图五：描述业务规则到软件需求中的改变
非功能需求
非功能需求（NFRs）往往以“系统应该是……”这样的短语开始，紧接着使用“快速”、“易于使用”、“直观好学”等形容词，它们经常同其他需求类型混在一起。传统意义上，非功能需求适用于整个系统，例如“系统应该是用128位加密码保障安全性的”或者“系统应当提供两秒钟的反应时间”等等。但是，情况并非总是如此。
许多用户通过“系统”体验人机交互界面。图形用户界面因此成为一项颇受非技术涉众欢迎的条款。例如：
应该可以轻易地看到保险政策的历史。
在这个陈述中有两个问题使得需求变得复杂：
功能性（历史）同非功能性（易于使用）混杂在一起。
“易于”是一个主观的概念，是无法详细描述的。
非功能性需求的陈述经常是没有被明确定义的，这使得它们很难被估量和测试。在这个特定的例子中，我要通过问清楚“易于”这个词来确定这个需求是对于整个系统都有效，还是仅仅同例子中政策的历史这一功能结合在一起。
细节中的可用性需求表现了个人的风格和品位；并不是所有的需求都会吸引所有的涉众。细心筛选那些适用于大多数用户以及你的赞助商的需求。有时，可看可感的 标准和规范可以避免关于颜色、字体以及导航等问题的长时间的争论。你是如何看待下面这份需求陈述的呢？它是用于控制一台核能设备还是一种单人纸牌游戏呢？
系统应该是可靠的。
在系统中将功能性和非功能性分离是很重要的，同样，像下面这个例子中那样给予非功能性适当的范围也很重要。
SR1：系统应当捕获所有政策变化的历史信息。
NFR1: 政策的历史应当很容易被找回。品质（鼠标点击数）：
容易 - 0次
可以 - 1次
不容易 - 2次或者更多
约束
当非功能性需求的陈述包含词语“必须”时，通常是表明一个或更多的约束适用于整个系统；例如，遵守指导方针、法律或者行业规范。约束应当被从其他需求类型中分离出来，同其他类型的非功能需求一样被来区别对待。例如：
C1： 系统必须遵守某某管理法令。
C2： 系统必须能够容忍故障发生。
（品质：系统崩溃次数/星期）
非常好：0-1
可以接受：2-5
不可接受：>5
用例设计
关于用例的书已经出了不少，它们论述了用例的风格、深度以及细节。我不打算再介绍这些题目，而是要阐明如何将业务用例同系统用例分开记录。
我们来考虑一个实际的例子。假设我们要为旅馆搭建一个前台终端设备。这家旅馆起初都是通过手工流程操作。钥匙、日历本、擦除器和钢笔都是前台需要用到的工具。在我们开始规划未来的前台应用程序之前，首先来看一看当前已经存在的用例，也被称作当前场景。这个业务用例的程序“顾客登记”是这样的：
文章来源于领测软件测试网 https://www.ltesting.net/
