來自于 Rational Edge：業務需求、軟件需求、業務規則、非功能需求、約束以及用例，這些都是 需求工程學中普遍使用的術語。盡管每一種需求所涉及到的內容都是不相同的，但是在一個復雜的需求陳述中它們卻往往被混為一談。本文將提供一種把復雜的需求陳述分割開來，逐個剖析的方法，從而使得業務需求和軟件需求更加清晰分明的呈現出來。
下面這種啟發用戶說出需求的場景您是否感覺很熟悉呢？
他說：“我希望系統會很快�！�
您說：“當然�！�
他說：“而且使用起來很方便�！�
您說：“我明白�！�
他說：“所有的文檔應該被集中存放在一起，就好像我們在地下室中的檔案文件�！�
您說：“好的�！�
他說：“我們要求每一位員工在登錄和注銷時都簽署一張卡片。但同時我們也必須遵守最近頒布的某某指導原則�！�
您說：“可以�！保ㄓ涗浵聛恚�
盡管為捕獲需求所付出的努力比起記錄這些需求的方式要重要的多，但是一位業務信息分析師或者需求工程師仍然要記錄、歸納和總結關于這個項目的各種需求。在先啟階段通常以某種迭代的方式進行，在這期間，新的需求呈現出來，已經存在的需求則轉化為某種我們所期望的類型和結構。在與涉眾進行有關需求的談判期間，我們經常會發現先前捕獲的需求信息并不重要甚至已經不復存在，而一些新的需求則在這個過程中顯現出來。
在上面這個簡短的場景中，你如何判斷哪些需求與商業需要相關，哪些需求還與軟件功能相關？這是一個非常重要的問題，因為把各個需求彼此分割開來將導致各自獨立的需求陳述，這對于不同需求各自的優先權（時刻表）、 風險和花費的分派是至關重要的。在工程的后期階段重新來做這項工作將是非常耗費時間的，同時也是產生含糊和錯誤的一個可能原因。特別是在測試階段，未被分離的需求將給整個工程帶來額外的負擔，因為此時對需求進行精確的確認和查證是一件非常麻煩的事情。
一旦分離開來，經過分割的需求類型將會節省工程的時間和開銷。需求管理計劃是一件合適的工具，它將表明您會以何種方式記錄和處理工程中遇到的各種需求。
本文在如下三個與需求工程相關的領域提出建議：
如何弄清需求類型的詞匯
如何與涉眾討論需求類型中的相互依賴性
記錄混雜在一起的不同需求的實例和指導方針
一個商業或者軟件系統可以通過逐一記錄下需求陳述來備案，這些陳述也可以通過運用用例設計的原則得到極大的擴展。在討論用例之前，讓我們先來考慮一些關于業務需求、軟件需求和業務規則的傳統需求分析的原則。
業務需求與軟件需求
業務需求是關于業務行為的陳述，與此不同，軟件需求（也稱功能需求）關注的是“系統應該……（做什么）�！避浖枨笸ǔＣ枋鲆呀洿嬖诘幕蚴俏磥淼能浖到y，并且應該與業務需求同步。顯然，一個計劃好的軟件系統應該幫助企業更加有效地完成工作。
讓我們退回來再看看這樣一些情節，它們將展示業務需求和軟件需求之間的不同之處。
辦公自動化：計算機能夠快速的完成大多數工作，在很多情況下，它們比起人工操作更加高效和可靠。更不用說它們可以不停歇的一直工作，以及在危險惡劣的環境中工作了。因此，我們試圖將盡可能多的日常工作委派給計算機及其系統來完成。例如，我們當中的許多人都使用一種時間管理系統來記錄我們的工作時間。在得到時間之后，我們進入一個自動化的許可進程。即使整個進程都是電子化的，我們仍然使用“時間表單”或“工作表單”這樣的稱謂。通過 互聯網訪問這個文檔要遠遠快于在某組織某部門中尋找到那張紙制的時間表單。在這個例子中，業務需求（記錄和批準時間表單）已經轉換為軟件需求，紙張處理過程已經被電子處理過程所取代。
手工辦公的需求：對于一家人壽保險公司來說，評估賠償風險可能完全基于保險商的主觀經驗。并不是所有的業務需求都已被數字化了，手工處理可能會與計算機技術共同存在。在這個例子中，計算機系統將得到風險估價的結果，而不是真正進行風險估價的操作，保險商將會繼續操作這些業務需求（評估風險），而系統只是記錄保險商的決定。
提高辦公能力：不僅計算機系統可以取代一些活動，信息技術也可以為組織機構提供一些管理業務的新方法。例如，出納員將產品的價格輸入終端機和后臺系統的方法就是一種由于條形碼和掃描儀的發明而帶來的新方法。在交易的最后合計價格，這種對于夫妻店仍然行之有效的業務需求，現在可以通過與掃描儀和條形碼技術相關的軟件需求來執行。
在上面的場景中，軟件需求清晰地與業務需求區分開來，兩者都受到 過程改進機會和自動控制的影響。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
