BR4：在多于三次從24小時服務窗口取款之后，賬戶將被凍結。
圖四描述了在RequisitePro中這種假定的情節如何被捕獲。
圖四：在假定情節下，用RequisitePro描述需求到業務規則
由于業務規則是動態的而且受制于調整和結構性改變所帶來的變化（新的產品、服務、綁定、合并、讓產易股等等），所以它們能夠在組織機構寬度的“規則驅動”中執行，這為 軟件工程師提供了很多機會。這種規則驅動可以擔當組織機構中警察的角色，并且監控組織機構中現有策略的變化。例如，正如圖五所描述的，銀行決定提高取款的限制。通過與軟件需求的聯結，產生了一個疑點，它清晰的向軟件工程師指出哪一個軟件需求受到了影響。
在面向對象的軟件設計中，由于業務規則被分派給對象，所以這種想法可以很好的得到實現。圖五展示了這是如何在RequisitePro中呈現的。
圖五：描述業務規則到軟件需求中的改變
非功能需求
非功能需求（NFRs）往往以“系統應該是……”這樣的短語開始，緊接著使用“快速”、“易于使用”、“直觀好學”等形容詞，它們經常同其他需求類型混在一起。傳統意義上，非功能需求適用于整個系統，例如“系統應該是用128位加密碼保障安全性的”或者“系統應當提供兩秒鐘的反應時間”等等。但是，情況并非總是如此。
許多用戶通過“系統”體驗人機交互界面。圖形用戶界面因此成為一項頗受非技術涉眾歡迎的條款。例如：
應該可以輕易地看到保險政策的歷史。
在這個陳述中有兩個問題使得需求變得復雜：
功能性（歷史）同非功能性（易于使用）混雜在一起。
“易于”是一個主觀的概念，是無法詳細描述的。
非功能性需求的陳述經常是沒有被明確定義的，這使得它們很難被估量和測試。在這個特定的例子中，我要通過問清楚“易于”這個詞來確定這個需求是對于整個系統都有效，還是僅僅同例子中政策的歷史這一功能結合在一起。
細節中的可用性需求表現了個人的風格和品位；并不是所有的需求都會吸引所有的涉眾。細心篩選那些適用于大多數用戶以及你的贊助商的需求。有時，可看可感的 標準和規范可以避免關于顏色、字體以及導航等問題的長時間的爭論。你是如何看待下面這份需求陳述的呢？它是用于控制一臺核能設備還是一種單人紙牌游戲呢？
系統應該是可靠的。
在系統中將功能性和非功能性分離是很重要的，同樣，像下面這個例子中那樣給予非功能性適當的范圍也很重要。
SR1：系統應當捕獲所有政策變化的歷史信息。
NFR1: 政策的歷史應當很容易被找回。品質（鼠標點擊數）：
容易 - 0次
可以 - 1次
不容易 - 2次或者更多
約束
當非功能性需求的陳述包含詞語“必須”時，通常是表明一個或更多的約束適用于整個系統；例如，遵守指導方針、法律或者行業規范。約束應當被從其他需求類型中分離出來，同其他類型的非功能需求一樣被來區別對待。例如：
C1： 系統必須遵守某某管理法令。
C2： 系統必須能夠容忍故障發生。
�。ㄆ焚|：系統崩潰次數/星期）
非常好：0-1
可以接受：2-5
不可接受：>5
用例設計
關于用例的書已經出了不少，它們論述了用例的風格、深度以及細節。我不打算再介紹這些題目，而是要闡明如何將業務用例同系統用例分開記錄。
我們來考慮一個實際的例子。假設我們要為旅館搭建一個前臺終端設備。這家旅館起初都是通過手工流程操作。鑰匙、日歷本、擦除器和鋼筆都是前臺需要用到的工具。在我們開始規劃未來的前臺應用程序之前，首先來看一看當前已經存在的用例，也被稱作當前場景。這個業務用例的程序“顧客登記”是這樣的：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
