定義業務需求

業務需求定義並沒有簡單的公式。業務需求的判定應根據與軟體解決方案利害關係人的合作、您對業務網域的相關知識以及實用的創意思考。

本節提供定義業務需求時應考慮的幾個因素。

設定業務目標

業務分析應該說明部署專案的目標。清楚的目標有助於集中設計判斷，亦可避免專案偏離主題。用目前的作業對照業務目標可協助判定設計的判斷。

範圍

業務需求應該要陳述部署專案的範圍。確定您定義的範圍可以被處理，並且避免「無限制」的敘述使目標不清楚或無法達成。不清楚的定義範圍會導致部署設計無法充分滿足業務需求或是浪費資源。

優先性

排出目標的優先順序，來確保部署最重要的層面可以最先達成。如果資源有限時，則可能需要延遲或修改某些目標。一般而言，大型複雜的部署需要階段性實作解決方案。透過確定優先性，您可以提供決策可能需要為您的部署設計建立以便獲得利害關係人承認的指導。

關鍵特性

找出成功的關鍵領域，以便利害關係人和設計者可以將重心放在在最重要的標準。

成長因素

設定業務目標時，您不只要考慮組織目前的需要，也要預估這些需求長期下會如何變更和成長。您應該避免決定一個很快就不適用的解決方案。

安全性界限

解決方案的設計以業務分析階段期間所做的假設為基礎。有許多原因可能造成這些假設不正確，例如，資料不足、判斷錯誤，或是未預期的外部事件。請確保您同時在業務目標和整個規劃中進行安全性界限規劃，如此，您所設計的解決方案才能處理未預期的事件。

瞭解使用者需求

進行必要的研究，以瞭解解決方案鎖定的使用者類型、他們的需求以及他們的預期利益。例如，下列清單提供一個分類使用者的方法：

• 僅限於現任員工

• 現任和離職員工

• 管理員

• 活躍的客戶

• 所有的客戶

• 會員場所

• 公眾

• 限制存取

清楚指出使用者的預期利益可幫助促成設計決定。例如，這裡是解決方案可提供給使用者的一些好處：

• 遠端存取公司資源

• 企業合作

• 單純化日常作業

• 由遠端團隊分享資源

• 增加產能

• 一般使用者的自我管理

開發作業需求

將作業需求以一組包含明確目標的功能需求來表示。一般而言，您會為下列的區域建立作業需求，例如：

• 一般使用者功能

• 減少回應時間

• 可用性和正常執行時間

• 減少錯誤率

• 資訊存檔和保留

以所有利害關係人都能瞭解的適當術語來表達作業需求。避免含糊不清的語言，像是「適當的一般使用者回應時間」。作業需求的範例如下所示：

• 電源中斷時，在 10 分鐘之內修復服務的能力

• 重新傳送過去 48 小時的傳入訊息的能力

• 在尖峰期間，在 60 秒內完成線上交易

• 在尖峰期間，在 4 秒內完成一般使用者認證

支援現有的使用模式

以可清楚評量的目標表示現有的使用模式。下列問題可協助判定此類的目標。

• 如何使用目前的服務？

• 使用模式為何 (例如，偶爾使用、時常使用或大量使用)？

• 您的使用者通常會連線到哪個網站？

• 使用者通常傳送的訊息大小為何？

• 使用者每日或每小時通常會完成多少交易？

研究會存取服務的使用者。使用者何時會存取現有的服務及存取時間長度，此類的因素是識別目標的關鍵。如果組織的經驗無法提供這些模式，請研究類似組織的經驗。

瞭解公司文化

需求分析應該將公司文化和政策的各種層面考慮在內。如果不注意公司文化會導致解決方案不容易被接受，或是難以實作。

利害關係人

確認在提議解決方案的成功當中具有既得利益的個人和組織。所有的利害關係人都應該主動參加業務目標和需求的定義。如果利害關係人沒有參加或是對規劃的變更一無所知，則規劃可能會有很嚴重的缺失。此類的利害關係人甚至會阻礙部署的實作。

標準和策略

確定您瞭解組織要求解決方案的標準和策略。這些標準和策略可能會影響設計、產品選項和部署方法的技術面。

一個範例是人事資料的機密性，這可能是由人事資源組織或部門主管所擁有或控制的資訊。另一個範例則是改變經營的公司程序。改變經營的公司程序可能會嚴重地影響解決方案的接受度、實作方法和時間表。

法規需求

法規需求有很大的程度是取決於業務的特性。研究和瞭解可能會影響部署的法規需求。許多公司和政府機構需要遵循存取標準。部署全球性解決方案時，亦需考慮到外國的法律和法規。例如，許多歐洲國家對儲存個人資訊有嚴格的控制。

安全性

您之前確認的目標，可能有需要特別注意的潛在安全性問題。調出部署所需的特定安全性目標。例如：

• 專屬資訊的授權存取

• 以角色架構存取機密資訊

• 遠端位置間的安全通訊

• 在本機系統呼叫遠端應用程式

• 與協力企業和組織安全交易

• 強制執行安全性策略

站點分散

站點間的地理分散與頻寬會影響設計決定。此外，某些站點可能需要本機管理。

這些地理考量會提高專案的訓練成本和複雜性等等。清楚指出站點地理分散造成的需求。強調哪些站點是設計成功的關鍵。

使用遞增方式

通常您會將軟體解決方案視為一個全體、廣泛的系統。然而，您經常以評量步驟逐步達成完整系統的部署。

當採用遞增方式時，您通常會設計藍圖來提供引導到最終、廣泛解決方案的基準點。此外，您可能要考慮延遲到後期實作的廣泛解決方案層面的短期規劃。

遞增方式提供這些優點：

• 您可以配合業務成長帶來的需求變更。

• 您可以調配現有的架構作為最終部署實作前的過渡階段。

• 您可以調度資本支出需求。

• 您可以調配小型的人力資源供給。

• 您可以考慮合夥可能。

瞭解服務層級合約

服務層級合約 (SLA) 指定最低的效能需求以及依據達成那些需求造成的失敗指定必須提供的客戶支援的層級和範圍。服務層級合約 (SLA) 是以業務分析期間定義的業務需求為基礎，稍後會將這些需求指定為技術需求階段期間的服務層級需求。會在專案核准 (也就是部署設計階段) 期間簽訂。

您應該以下列項目為中心開發 SLA，例如正常執行時間、回應時間、訊息傳送時間和損壞修復。應該考慮這些項目，例如，系統概觀、支援組織的角色和責任、如何衡量服務層級、改變要求等等。以系統可用性為中心來確定組織的預期是判定 SLA 範圍的關鍵。