需求必須是具體的、可測量的、可控的、可現實的以及限時的。這比看起來更有挑戰性�？墒�，通過尋問以下的問題就能夠很容易地完成：
為什么要用這種方式來處理?
您將獲得什么樣的結果，或者如果這個問題被解決您將能夠做什么?
明確地說，什么過程將會受到這個障礙的影響?
通過補償這個過程將會得到什么利益(盡可能是可計算的)?
做什么來改變事情?
這通常很難回答，涉眾們往往回到問題的陳述上來。需求工程可以以一些如果……怎么樣的建議來獲取一些可能性。盡管如此，還是要在涉眾們回到正軌時立即撤回。
關于時間框架，對于背景和業務環境什么時候可以完成?
這并不是特意為項目交付而設的點，而是推理業務背景的起點。例如，一個上網卡的商人想要以節日為目標開張他的新 Web 站點。
確定并闡明范圍
什么是進什么是出? 什么被執行了或者被交付了，什么時間?
確定“主語”和“謂語”
這是經常最容易被忽略的，也是范圍頻繁變化的主要原因。如果這不僅僅是一個動詞，可以將它規定為獨特的需求。這提高了明確性并促進涉眾們之間更好的理解。
關注需求本身，而不是如何實現
業務需求通常陳述完成了什么，并且應該避免任何關于怎樣完成的提示。例如，一個企業想要主觀的、綜合的觀點融合到他們的業務數據中。重點應該是他們想要做什么，而不是他們需要得到什么(例如，數據庫)。
需求樣例
ESC 有幾個基于 Web 的應用軟件。因為每個應用軟件都是獨立開發的，消費者面臨著像需要分別在每個應用軟件上注冊以及對于每個業務功能需要不同的窗口的問題，引起了他們的抱怨。為了解決這些抱怨，ESC 業務小組制定了下面的需求：
BR264： 消費者應該能夠通過一個兼容的界面訪問所有的 ESC 應用軟件，并且只需要注冊一次。ESCWeb(主要的商業 Web 網站)對于所有的消費者應該有相同的外觀和感覺。這將減少用戶差錯并提高用戶的體驗。ESCWeb 最終也將支持移動的和遠程的客戶。
很顯然，這個需求能夠被改善。通過運用這些原則，我們能夠對它進行如下的重述。
BR264：在 ESC5.0 版本中，消費者想要注冊一次就可以應用所有的 ESC應用軟件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。
BR265：在 ESC5.0 版本中，所有的 ESC 應用軟件將執行 ESC Web Standard 273-1 和 273-2，這將再減少10%的用戶差錯。
技術1. 確定 RequisitePro 中的業務需求
在這個記錄將需求記錄在 RequisitePro 的技術中，關鍵是保持獲取和澄清這個需求的原則。這個技術包括三個步驟：
確定一個業務需求的Requirement Type。所有的業務需求都將分配這個類型。BUS是一個習慣性的前綴。
當規定一個 Requirement Type 時，利用Requirement Must Contain選項來指定一個分隔符(比如 \"|\")。這個主語和謂語可被安置在分隔符的任何一邊。這并不是強制性的要求，RequisitePro 手冊有更多的細節。方法是在識別主謂成為需求的過程中使用逐漸導出的原則。
在最高層次為業務需求創建一個包。您可以立即看到它是如何幫助跟蹤的。
技術1現在已經完成。您已經獲取了一個清晰而且簡潔的業務需求，并準備好轉向下一個階段。圖 2顯示了這個技術。
圖 2. 利用技術1獲取業務需求
用例
技術2 (將用例與需求連接起來)覆蓋了這個項目的下一個階段。只要業務需要被確定，這個業務構架師或者分析師就會開發用例來對它們進行說明。尤其對于大的或者復雜的項目，業務分析師經常會遇到這樣兩個問題：
需求存在于文檔中(除非您使用技術1)，用例位于模型中，比如 Rational Rose® Enterprise (Rose)。
由于需求(和用例)的數量逐漸增長，拆分也變得越來越難于管理。
業務需求與用例是如何連接起來的?用例捕獲用戶的視角，他們說明了用戶的行為和系統的回應。但是業務需求遠遠超越了作為一個服務于用例的數據源。當規定了屬性或者限制時，它們就變成了用例的屬性(或者備用信息流)。我們應該能夠記錄業務需求和一個用例之間正常的連接，并用它做一些有意義的事情，比如跟蹤或者分析。
建模用例時需要大量的資料。在資源部分中的文章都是很好的起點。查看這些案例屬于這篇文章以外的范圍，但是我們將介紹一個應用于這個技術實現的命名習慣。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
