商業分析 - 快速指南

---

---

商業分析 - 簡介

什麼是商業分析？

商業分析是一組識別業務需求並確定企業業務問題解決方案的任務、知識和技術。儘管總體定義相似，但在不同行業中的實踐和程式可能會有所不同。

在資訊科技行業，解決方案通常包括系統開發元件，但也可能包括流程改進或組織變革。

商業分析還可以用於瞭解組織的現狀，或作為識別業務需求的基礎。然而，在大多數情況下，商業分析是為了定義和驗證滿足業務需求、目標或目的的解決方案。

誰是商業分析師？

商業分析師是指分析組織或業務領域（真實或假設的）並記錄其業務、流程或系統，評估業務模型或其與技術的整合的人。但是，組織職稱各不相同，例如分析師、商業分析師、商業系統分析師或系統分析師。

為什麼需要商業分析師？

組織出於以下原因採用商業分析：

• 瞭解系統部署的組織結構和動態。

• 瞭解目標組織中的當前問題並確定改進潛力。

• 確保客戶、終端使用者和開發人員對目標組織有共同的理解。

在專案的初始階段，當解決方案和設計團隊正在解釋需求時，商業分析師的角色是審查解決方案文件，與解決方案設計師（IT 團隊）和專案經理密切合作，以確保需求清晰。

在一個典型的、大型的 IT 組織中，尤其是在開發環境中，您可以找到本地和離岸交付團隊擔任上述角色。您可以找到一個“商業分析師”，他作為關鍵人物，必須將這兩個團隊聯絡起來。

有時，他會與業務使用者互動，有時與技術使用者互動，最終與專案中的所有利益相關者互動，以獲得批准和最終確認，然後才能繼續進行文件編制。

因此，BA 的作用對於任何專案的有效和成功的啟動都至關重要。

IT 商業分析師的角色

商業分析師的角色從定義和確定組織的業務領域開始，然後是收集需求、分析和記錄需求、將這些需求傳達給相應的利益相關者、確定正確的解決方案，然後驗證解決方案以查詢需求是否滿足預期標準。

它與其他職業有何不同？

商業分析不同於財務分析、專案管理、質量保證、組織發展、測試、培訓和文件開發。但是，根據組織的不同，商業分析師可能會執行所有或部分這些相關職能。

僅從事軟體系統開發的商業分析師可以被稱為 IT 商業分析師、技術商業分析師、線上商業分析師、商業系統分析師或系統分析師。

商業分析還包括在利益相關者、開發團隊、測試團隊等之間充當聯絡人的工作。

軟體開發生命週期

軟體開發生命週期 (SDLC) 是軟體組織中軟體專案遵循的一個過程。它包含一個詳細的計劃，描述如何開發、維護、替換和更改或增強特定軟體。它定義了一種改進軟體質量和整體開發過程的方法。

• SDLC 是 IT 分析師用來開發或重新設計高質量軟體系統的一個過程，該系統同時滿足客戶和現實世界需求。

• 它考慮了軟體測試、分析和後期維護的所有相關方面。

SDLC 的重要階段如下圖所示：

規劃階段

每個活動都必須從計劃開始。不計劃就是計劃失敗。不同模型的規劃程度不同，但清楚地瞭解我們將透過建立系統規範來構建什麼非常重要。

定義階段

在此階段，我們分析和定義系統的結構。我們定義體系結構、元件以及這些元件如何組合在一起以產生工作的系統。

設計階段

在系統設計中，詳細描述設計功能和操作，包括屏幕布局、業務規則、流程圖和其他文件。此階段的輸出將描述新系統作為模組或子系統的集合。

構建階段

這是開發階段。我們開始基於系統的使用編譯器、直譯器、偵錯程式等工具進行程式碼生成，使系統執行。

實施

實施是構建階段的一部分。在此階段，我們開始基於系統的使用編譯器、直譯器、偵錯程式等工具進行程式碼生成，使系統執行。

測試階段

隨著系統的不同部分完成；它們會經過一系列測試。它根據需求進行測試，以確保產品實際上解決了需求階段中提出的需求。

• 測試計劃和測試用例用於識別錯誤並確保系統按規範執行。

• 在此階段，進行單元測試、手動測試、驗收測試和系統測試等不同型別的測試。

測試中的缺陷跟蹤

軟體測試報告用於傳達已執行測試計劃的結果。鑑於此，報告應包含與當前正在測試的系統相關的所有測試資訊。報告的完整性將在審查會議中進行驗證。

專案的測試旨在實現兩個主要目標：

• 檢測系統中的故障和缺陷。

• 檢測需求和實現之間的不一致性。

下圖描述了**缺陷跟蹤流程**：

為了實現主要目標，擬議系統的測試策略通常包含四個測試級別。

這些是單元測試、整合測試、驗收測試和迴歸測試。以下小節概述了這些測試級別，哪些開發團隊角色負責開發和執行它們，以及確定其完整性的標準。

部署

測試階段結束後，系統將釋出並進入生產環境。一旦產品經過測試並準備部署，它就會正式釋出到合適的市場。有時，產品部署會根據組織的業務戰略分階段進行。

產品可能首先在一個有限的細分市場中釋出，並在真實的業務環境中進行測試（UAT - 使用者驗收測試）。然後，根據反饋，可以按原樣釋出產品，或者在目標細分市場中釋出具有建議改進的產品。

SDLC 後過程

產品釋出到市場後，將為現有客戶群進行維護。

一旦進入生產環境，系統將因未檢測到的錯誤或其他意外事件而發生修改。對系統進行評估，並重復迴圈以維護系統。

商業分析師在 SDLC 過程中的作用

正如我們在下圖中看到的，BA 參與驅動業務需求並將它們轉換為解決方案需求。

他參與將解決方案功能轉換為軟體需求。然後在分析和設計階段發揮主導作用，在程式碼開發中發揮作用，然後在作為專案團隊變革推動者的錯誤修復期間遵循測試階段，最終滿足客戶需求。

商業分析 - 角色

商業分析師在 IT 專案中的作用可能是多方面的。專案團隊成員可能承擔多個角色和責任。在某些專案中，如果可用資源有限，BA 可能會承擔商業智慧分析師、資料庫設計師、軟體質量保證專家、測試人員和/或培訓師的角色。

專案協調員、應用程式開發負責人或開發人員也可能在特定專案中承擔商業分析師的角色。

商業分析與分析業務的正常執行需求以及最佳化其執行方式的需求高度重疊。商業分析的一些示例包括：

• 建立業務架構
• 準備商業案例
• 進行風險評估
• 需求收集
• 業務流程分析
• 需求文件編制

BA 的主要角色

大多數商業分析師的關鍵作用是在業務和技術開發人員之間充當聯絡人。商業分析師與業務客戶一起工作，以收集/定義系統或流程的需求以提高生產力，同時與技術團隊一起設計和實現系統/流程。

作為貢獻者

BA 的主要職責是幫助業務使用者/關鍵使用者識別業務問題、需求和功能，瞭解利益相關者的擔憂和需求，以確定改進機會，併為 IT 系統開發專案制定商業案例提供業務投入。

作為促進者

業務分析師還應促進/協調需求的收集和分析，與利益相關者合作和溝通，管理他們的期望和需求，並確保需求完整、明確，並將其與組織的即時業務需求相匹配。

作為一名分析師

另一個重要的角色是評估擬議的系統和組織對系統實施的準備情況，併為使用者提供支援，並與IT人員協調。

從業務角度幫助審查並提供對擬議IT系統設計的意見，解決利益相關者之間的衝突/矛盾，透過協助使用者開發測試用例來幫助組織全面而高質量的使用者驗收測試（UAT），並幫助組織培訓，目的是確保部署的IT系統能夠滿足業務需求和要求，並實現預期的效益。

規劃和監控業務分析活動，制定範圍、進度和方法，以執行與IT系統開發專案相關的業務分析活動，監控進度，與內部專案經理協調，並在適當的時候報告收入、盈利能力、風險和問題。

業務分析師的主要職責

業務分析師的職責範圍要求他在專案的不同階段履行不同的職責，如下所述：

啟動階段

此階段標誌著一個新專案的開始，業務分析師將承擔以下職責：

• 協助進行專案的成本效益分析。
• 瞭解商業案例。
• 確定解決方案/專案/產品的可行性。
• 協助建立專案章程。
• 確定專案中的利益相關者。

規劃階段

此階段將涉及收集需求和規劃專案如何執行和管理。其職責包括以下職能：

• 收集需求
• 分析、組織和記錄需求。
• 透過建立用例、RTM、BRD、SRS等來管理需求。
• 評估擬議的解決方案。
• 與利益相關者進行聯絡並加強溝通。
• 協助制定專案管理計劃。
• 幫助確定專案的範圍、約束條件、假設和風險。
• 協助設計解決方案的使用者體驗。

執行階段

此階段標誌著根據收集到的需求開發解決方案。職責包括：

• 向IT/開發團隊解釋需求。

• 澄清關於擬議解決方案的疑問和擔憂。

• 討論和確定專案範圍變更的優先順序並達成一致。

• 為初步測試建立Beta測試指令碼。

• 與利益相關者共享正在開發的模組並徵求他們的反饋。

• 遵守截止日期並管理利益相關者的期望。

• 解決衝突並管理與專案團隊的溝通。

監控和控制階段

在此階段，對專案進行衡量和控制，以防偏離初始計劃。此階段與執行階段同時進行。

• 開發測試指令碼並進行全面的模組和整合測試。

• 進行使用者驗收測試（UAT）並建立測試報告。

• 獲得客戶對交付成果的驗收/批准。

• 向開發團隊解釋變更請求。

• 監控變更請求的開發並驗證其是否根據專案目標實施。

收尾階段

此階段標誌著專案的結束。職責包括：

• 向客戶展示已完成的專案並獲得他們的驗收。

• 建立使用者培訓手冊、任何功能材料和其他指導手冊。

• 在生產環境中進行詳盡的整合測試。

• 建立最終產品文件，記錄專案經驗教訓。

BA預期交付什麼？

業務分析師充當業務使用者和技術IT人員之間的橋樑。他們的存在將極大地促進IT專案的成功。擁有一位專門的業務分析師有很多好處。專門的業務分析師可以：

• 從業務角度提供清晰的專案範圍。

• 制定合理的商業案例，更現實地估計資源和業務效益。

• 特別是在大型IT專案中，準備關於專案範圍、規劃和管理（包括成本和進度）的更完善的報告。

• 製作清晰簡潔的需求，反過來，如果IT專案外包，這有助於提供更清晰、更準確的需求。

• 從使用者那裡收集真實的業務需求，並有效地管理使用者的期望。

• 提高擬議IT系統的質量，使其滿足使用者需求。

• 確保開發的系統質量，然後再交給終端使用者審查和驗收。

• 對交付的系統進行全面的質量測試，並將反饋提供給技術IT人員。

業務分析 - 工具和技術

擔任BA職位時，業務分析師應該熟悉各種分析工具和相關技術。

正如我們之前已經瞭解到的，業務分析是一個過程，在這個過程中，你試圖理解一個商業企業，並識別機遇、問題領域、問題，並與各種角色和職責廣泛的人員（如CEO、VP、主管）會面，並瞭解他們的業務需求。

從根本上說，我們可以將業務分析分為三種類型：

• 戰略分析 - 戰略業務分析處理專案前的工作。它是識別業務問題、制定業務戰略、目標和目標以幫助高層管理人員的方法或過程。它為有效的決策過程提供管理資訊報告。

• 戰術分析 - 它涉及在適當的專案中在適當的時間應用特定業務分析技術的知識。

• 運營分析 - 在這種型別的業務分析中，我們透過利用資訊科技關注業務方面。它也是研究運營系統以識別業務改進機會的過程。

對於每種型別的分析，市場上都有一套工具可用，並且基於組織的需求和要求，這些工具需要被使用。

然而，為了將業務需求轉化為可理解的資訊，一個優秀的BA會在他們的日常活動中利用事實調查、訪談、文件審查、問卷調查、抽樣和研究等技術。

功能性需求和非功能性需求

我們可以將需求分解為兩種主要型別：功能性需求和非功能性需求。

對於所有技術專案，必須將功能性需求和非功能性需求分開，分別進行分析。

定義合適的工具和適當的技術可能是一項艱鉅的挑戰。無論您是開發一個全新的應用程式還是對現有應用程式進行更改。考慮功能流程的正確技術本身就是一門藝術。

目前市場上廣泛使用的業務分析技術的概述：

工具和流程的適用性

儘管業務分析師可以使用各種工具和程式，但這完全取決於組織的當前實踐以及他們希望如何使用它。

例如，當需要更深入地研究某個重要領域或功能時，可以使用根本原因分析。

但是，業務需求文件是將需求以文件格式呈現的最流行和最被接受的方式。

在接下來的章節中，我們將深入討論上述一些技術。

商業分析 - JAD 會議

聯合應用程式開發 (JAD) 是一種在為公司開發新的資訊系統時用於收集業務需求的流程。JAD 流程還可以包括增強使用者參與、加快開發和提高規範質量的方法。JAD會議的目的是彙集主題專家/業務分析師或IT專家來提出解決方案。

業務分析師是與整個團隊互動、收集資訊、分析資訊並編寫文件的人。他在JAD會議中扮演著非常重要的角色。

JAD會議的用途

JAD會議是高度結構化的、輔助的研討會，它彙集了客戶決策者和IT人員，以便在短時間內產出高質量的交付成果。

換句話說，JAD會議使客戶和開發人員能夠快速就專案的基本範圍、目標和規範達成一致，或者無法達成一致，這意味著需要重新評估專案。

簡而言之，JAD會議可以

• 簡化 - 它將數月的會議和電話會議整合到一個結構化的研討會中。

• 識別 - 問題和參與者

• 量化 - 資訊和處理需求

• 澄清 - 具體化和澄清會議中商定的所有需求。

• 統一 - 一個開發階段的輸出是下一個階段的輸入。

• 滿足 - 客戶定義系統；因此，它是他們的系統。共同參與帶來了成果的份額；他們對系統的成功充滿信心。

JAD會議的參與者

參與JAD會議的參與者如下：

執行贊助商

執行贊助商是推動專案的人——系統所有者。他們通常來自更高的職位，能夠做出決策並提供必要的戰略、規劃和方向。

主題專家

這些是業務使用者和外部專家，他們對於成功的研討會是必需的。主題專家是JAD會議的支柱。他們將推動變革。

主持人

他主持會議；他確定可以在會議中解決的問題。主持人不會向會議提供資訊。

關鍵使用者

關鍵使用者在某些情況下也稱為超級使用者，它們可以互換使用，並且在不同的公司之間有所不同。關鍵使用者通常是與IT專案更緊密相關的業務使用者，負責在專案期間配置其團隊成員的配置檔案。

例如：假設John是關鍵使用者，Nancy和Evan是SAP系統的使用者。在這種情況下，Nancy和Evan無權更改功能和配置檔案，而John作為關鍵使用者有權使用更多授權來編輯配置檔案。

與傳統的做法相比，JAD 方法被認為能夠縮短開發時間並提高客戶滿意度，因為客戶參與了整個開發過程。相比之下，在傳統的系統開發方法中，開發者調查系統需求並開發應用程式，客戶的輸入僅限於一系列訪談。

需求收集技術

技術描述了在特定情況下如何執行任務。一個任務可以沒有相關技術，也可以有一個或多個相關技術。一項技術應該至少與一項任務相關聯。

以下是一些眾所周知的需求收集技術：

頭腦風暴

頭腦風暴法用於需求收集，以從一群人那裡獲得儘可能多的想法。通常用於識別問題的可能解決方案，並闡明機會的細節。

文件分析

審查現有系統的文件可以幫助建立現狀流程文件，並推動差距分析以確定遷移專案的範圍。理想情況下，我們甚至會審查推動建立現有系統的需求——這是記錄當前需求的起點。現有文件中常常埋藏著資訊金礦，這些資訊可以幫助我們在驗證需求完整性時提出問題。

焦點小組

焦點小組是由代表產品使用者或客戶的人員組成的聚會，以獲取反饋。可以收集關於需求/機會/問題的反饋以識別需求，也可以收集反饋以驗證和改進已獲得的需求。這種市場調研方法不同於頭腦風暴法，因為它是一個有特定參與者的管理過程。

介面分析

軟體產品的介面可以是人機介面。與外部系統和裝置的整合只是另一種介面。以使用者為中心的設計方法非常有效地確保我們建立易用的軟體。介面分析——審查與其他外部系統的接觸點，這對於確保我們不會忽略使用者無法立即看到的需求非常重要。

訪談

對利益相關者和使用者的訪談對於建立優秀的軟體至關重要。如果不瞭解使用者和利益相關者的目標和期望，我們就很難滿足他們的需求。我們還必須認識到每個受訪者的觀點，以便能夠正確地權衡和處理他們的意見。傾聽是幫助優秀分析師從訪談中獲得比普通分析師更多價值的技能。

觀察

透過觀察使用者，分析師可以識別流程流程、步驟、痛點和改進機會。觀察可以是被動的（不干預）或主動的（在觀察時提出問題）。被動觀察更適合獲得原型反饋（以改進需求），而主動觀察更有效地瞭解現有業務流程。這兩種方法都可以使用。

原型設計

原型設計是一種相對現代的需求收集技術。在這種方法中，您收集初步需求，然後用這些需求來構建解決方案的初始版本——原型。您將其展示給客戶，然後客戶會提供額外的需求。您更改應用程式並再次與客戶迴圈。這個重複的過程持續進行，直到產品滿足關鍵的業務需求或達到商定的迭代次數。

需求研討會

研討會對於收集需求非常有效。比頭腦風暴會議更有條理，相關方協作記錄需求。捕獲協作的一種方法是建立領域模型工件（如靜態圖、活動圖）。兩個分析師比一個分析師參與研討會效果更好。

逆向工程

當遷移專案無法訪問現有系統的足夠文件時，逆向工程將識別系統的作用。它不會識別系統應該做什麼，也不會識別系統何時做錯了事。

調查問卷

當從許多人那裡收集資訊時——由於預算和時間限制，人數太多而無法進行訪談——可以使用調查問卷。調查可以強迫使用者從選項中選擇，對某事物進行評分（“非常同意，同意……”），或者提出開放式問題，允許自由形式的回答。調查設計很難——問題可能會影響受訪者的回答。

功能需求文件

功能需求文件 (FRD) 是應用程式功能需求的正式宣告。它與合同具有相同的目的。在這裡，開發人員同意提供指定的 capabilities。如果客戶提供的 capabilities 在 FRD 中指定，則客戶同意認為產品令人滿意。

功能需求捕獲系統的預期行為。此行為可以表示為系統需要執行的服務、任務或功能。該文件應根據特定專案的需要進行調整。它們定義諸如系統計算、資料操作和處理、使用者介面以及與應用程式的互動等內容。

功能需求文件 (FRD) 具有以下特點：

• 它證明了該應用程式在未來幾年的業務目標和業務流程方面具有價值。

• 它包含應用程式的完整需求集。它不留任何空間讓人假設 FRD 中未陳述的任何內容。

• 它是獨立於解決方案的。ERD 是關於應用程式應該做什麼的陳述，而不是關於它是如何工作的陳述。FRD 不會讓開發人員承擔設計責任。因此，在 FRD 中任何提及使用特定技術的參考文獻都是完全不合適的。

功能需求應包括以下內容：

• 對將輸入系統的資料的描述

• 對每個螢幕執行的操作的描述

• 對系統執行的工作流程的描述

• 對系統報告或其他輸出的描述

• 誰能將資料輸入系統？

• 系統如何滿足適用的法規要求？

功能規範的設計目的是讓一般讀者都能閱讀。讀者應該理解系統，但不應該需要任何技術知識就能理解此文件。

功能需求交付成果

業務需求文件 (BRD) 包括：

• 功能需求——包含要開發的系統的詳細需求的文件。這些需求定義了系統必須具備的功能特性和功能。確保在業務案例中確定的任何假設和約束仍然準確且最新。

• 業務流程模型——當前流程狀態的模型（“現狀”模型）或流程應成為何種狀態的概念（“目標”模型）

• 系統上下文圖——上下文圖顯示系統邊界、與系統互動的外部和內部實體以及這些外部和內部實體之間相關的流程。

• 流程圖（現狀或目標）——圖解地描述業務流程的操作順序或資料的移動。根據模型的複雜性，包含一個或多個流程圖。

• 業務規則和資料需求——業務規則定義或約束業務的某些方面，並用於定義資料約束、預設值、值範圍、基數、資料型別、計算、異常、必需元素和資料的關聯完整性。

• 資料模型——實體關係圖、實體描述、類圖

• 概念模型——業務功能的不同實體及其相互關係的高階顯示。

• 邏輯模型——說明業務功能中涉及的特定實體、屬性和關係，並表示業務、技術或概念環境中所有資料的定義、特徵和關係。

• 資料字典和詞彙表——關於構成資料庫或類似資料管理系統基礎的資料模型的資料元素、欄位、表和其他實體的詳細資訊集合。

• 利益相關者地圖——確定所有受擬議變更影響的利益相關者及其對需求的影響/許可權級別。此文件在專案管理方法 (PMM) 的起源階段開發，由專案經理擁有，但需要專案團隊在整個過程中更新新/更改的利益相關者。

• 需求可追溯性矩陣——一個表格，說明各個功能需求與其他型別的系統工件之間的邏輯連結，包括其他功能需求、用例/使用者故事、架構和設計元素、程式碼模組、測試用例和業務規則。

軟體需求規格說明書

軟體需求規格說明書 (SRS) 是一份文件，用作客戶之間的溝通媒介。最基本的軟體需求規格說明書是用於在客戶和開發人員之間溝通軟體需求的正式文件。

SRS 文件側重於需要做什麼（做什麼），並仔細避免解決方案（怎麼做）。它作為開發團隊和客戶之間的合同。此階段的需求使用終端使用者術語編寫。如有必要，稍後將據此制定正式的需求規格說明書。

SRS 是要開發系統的行為的完整描述，可能包括一組用例，這些用例描述使用者將與軟體進行的互動。

SRS 的目的

SRS 是客戶/客戶、業務分析師、系統開發人員、維護團隊之間的溝通工具。它也可以是購買者和供應商之間的合同。

• 它將為設計階段奠定堅實的基礎
• 支援專案管理和控制
• 幫助控制和發展系統

軟體需求規格說明書應該是完整、一致、可追溯、明確和可驗證的。

系統規格說明中應解決以下問題：

• 定義系統的功能
• 定義硬體/軟體功能劃分
• 定義效能規格
• 定義硬體/軟體效能劃分
• 定義安全要求
• 定義使用者介面（使用者手冊）
• 提供安裝圖紙/說明
• 軟體需求規格說明書模板

修訂歷史

文件審批

以下軟體需求規格說明書已獲得以下人員的接受和批准：

商業分析 - 用例

UML 的九個圖之一是用例圖。這些圖不僅重要，而且是軟體專案必要的需求。它基本上用於軟體生命週期。眾所周知，開發週期中有多個階段，用例最常用的階段是在需求收集階段。

什麼是用例？

用例描述了系統執行的一系列操作，這些操作為參與者提供價值。用例描述了系統在各種情況下響應來自利益相關者（稱為主要參與者）的請求時的行為。

參與者是系統的“誰”，換句話說，他是終端使用者。

在軟體和系統工程中，用例是步驟列表，通常定義角色（在 UML 中稱為“參與者”）和系統之間的互動，以實現目標。參與者可以是人或外部系統。

用例指定了系統中事件的流程。它更關注系統為了執行一系列操作而執行的操作。

用例的好處

用例提供以下好處：

• 這是一種簡單易行的方法，可以捕捉功能需求，重點關注為使用者帶來的增值。

• 與傳統的需求方法相比，用例編寫和閱讀相對容易。

• 用例迫使開發人員從終端使用者的角度思考。

• 用例讓使用者參與到需求過程中。

用例的構成要素

名稱 : 說明用例目的的描述性名稱。

描述 : 用幾句話描述用例的功能。

參與者 : 列出參與用例的任何參與者。

前提條件 : 在開始用例之前必須滿足的條件。

事件流程 : 系統和參與者之間互動的描述。

後置條件 : 描述用例執行完畢後系統的狀態。

用例模板指南

使用本章末尾給出的模板記錄每個用例。本節描述了用例模板中每個部分的含義。

用例識別

• 用例ID − 為每個用例提供一個唯一的數字識別符號，採用分層形式：X.Y。相關的用例可以在層次結構中分組。功能需求可以追溯到標記的用例。

• 用例名稱 − 為用例指定一個簡潔、面向結果的名稱。這些名稱反映了使用者需要使用系統完成的任務。包括一個動作動詞和一個名詞。一些示例：

  • 檢視零件號資訊。

  • 手動標記超文字源並建立到目標的連結。

  • 訂購帶有更新軟體版本的CD。

用例歷史

在這裡，我們提到用例文件的利益相關者的姓名。

• 建立者 − 提供最初記錄此用例的人員的姓名。

• 建立日期 − 輸入最初記錄用例的日期。

• 最後更新者 − 提供對用例描述進行最近一次更新的人員的姓名。

• 最後更新日期 − 輸入最近更新用例的日期。

用例定義

以下是用例關鍵概念的定義：

參與者

參與者是軟體系統外部的人或其他實體，他們與系統互動並執行用例以完成任務。不同的參與者通常對應於從將使用該產品的客戶群體中識別的不同使用者類別或角色。命名將執行此用例的參與者。

描述

簡要描述此用例的原因和結果，或對操作序列和執行用例的結果進行高階描述。

前提條件

列出在用例開始之前必須執行的任何活動或必須為真的任何條件。為每個前提條件編號。

示例

• 使用者身份已透過身份驗證。
• 使用者的計算機有足夠的可用空閒記憶體來啟動任務。

後置條件

描述用例執行結束時系統的狀態。為每個後置條件編號。

示例

• 文件僅包含有效的SGML標記。
• 資料庫中專案的價格已更新為新值。

優先順序

指示實現允許執行此用例所需功能的相對優先順序。使用的優先順序方案必須與軟體需求規範中使用的方案相同。

使用頻率

估計參與者在某個適當的時間單位內將執行此用例的次數。

正常事件流程

詳細描述在正常、預期條件下執行用例期間將發生的使用者操作和系統響應。此對話序列最終將實現用例名稱和描述中陳述的目標。此描述可以作為對假設問題的回答：“如何<完成用例名稱中陳述的任務>？”最好將其編寫為參與者執行的操作的編號列表，並與系統提供的響應交替出現。

備選流程

在本節中分別記錄在此用例中可能發生的其它合法使用場景。說明備選流程，並描述步驟序列中發生的任何差異。使用用例 ID 作為字首對每個備選流程進行編號，後跟“AC”表示“備選流程”。示例：X.Y.AC.1。

異常情況

描述執行用例期間可能發生的任何預期錯誤條件，並定義系統如何響應這些條件。此外，還應描述如果用例執行由於某些意外原因而失敗，系統將如何響應。使用用例 ID 作為字首對每個異常情況進行編號，後跟“EX”表示“異常”。示例：X.Y.EX.1。

包含

列出此用例包含（“呼叫”）的任何其他用例。出現在多個用例中的公共功能可以拆分為一個單獨的用例，這些用例需要該公共功能。

特殊需求

確定用例在設計或實現過程中可能需要解決的任何附加需求，例如非功能性需求。這些可能包括效能要求或其他質量屬性。

假設

列出分析中做出的任何假設，這些假設導致將此用例納入產品描述並編寫用例描述。

備註和問題

列出關於此用例的任何附加註釋或必須解決的任何剩餘未決問題或待定事項 (TBD)。確定誰將解決每個問題，截止日期以及最終解決方案是什麼。

變更管理和版本控制

版本控制是對文件、大型網站和其他資訊集合的更改進行管理。更改通常由數字或字母程式碼標識，稱為修訂號或修訂級別。每個修訂都與時間戳和進行更改的人員相關聯。

用例圖

統一建模語言 (UML) 的一個重要部分是繪製用例圖的工具。用例在專案的分析階段用於識別和劃分系統功能。它們將系統劃分為參與者和用例。參與者代表系統使用者可以扮演的角色。

這些使用者可以是人、其他計算機、硬體部件，甚至是其他軟體系統。唯一的標準是它們必須位於被劃分成用例的系統部分之外。它們必須向該系統部分提供刺激，並且必須從中接收輸出。

用例代表參與者在追求目標的過程中使用您的系統執行的活動。我們需要定義這些使用者（參與者）需要系統提供什麼。用例應反映使用者的需求和目標，並且應由參與者啟動。參與業務用例的業務、參與者、客戶應透過關聯連線到用例。

繪製用例圖

下圖顯示了用例在 UML 示意圖形式中的外觀。用例本身看起來像一個橢圓形。參與者被繪製成小的簡筆人物。參與者透過線條連線到用例。

用例 1 − 銷售員結賬

• 顧客將商品放在櫃檯上。
• «uses» 刷 UPC 閱讀器。
• 系統在資料庫中查詢 UPC 程式碼，獲取商品描述和價格
• 系統發出可聽見的蜂鳴聲。
• 系統透過語音輸出宣佈商品描述和價格。
• 系統將價格和商品型別新增到當前發票。
• 系統將價格新增到正確的稅款小計

因此， «uses» 關係非常類似於函式呼叫或子例程。

以這種方式使用的用例稱為抽象用例，因為它不能獨立存在，而必須由其他用例使用。

示例 ─ 取款用例

客戶與我們的自動取款機 (ATM) 相關的目標是取款。因此，我們正在新增取款用例。從自動取款機取款可能涉及銀行進行交易。因此，我們還添加了另一個參與者 – 銀行。參與用例的兩個參與者都應透過關聯連線到用例。

自動取款機為客戶和銀行參與者提供取款用例。

參與者和用例之間的關係

可以使用以下關係組織用例：

• 泛化
• 關聯
• 擴充套件
• 包含

用例之間的泛化

可能存在參與者與類似用例關聯的情況。在這種情況下，子用例繼承父用例的屬性和行為。因此，我們需要泛化參與者以顯示功能的繼承。它們由帶有大空心三角形箭頭頭的實線表示。

用例之間的關聯

用例圖中用實線表示參與者和用例之間的關聯。每當參與者參與用例描述的互動時，就存在關聯。

擴充套件

有些功能是可選觸發的。在這種情況下，使用擴充套件關係並附加擴充套件規則。需要注意的是，即使未呼叫擴充套件用例，基本用例也能夠自行執行功能。

擴充套件關係顯示為虛線，帶有從擴充套件用例指向擴充套件（基本）用例的開放箭頭。箭頭用關鍵字«extend»標記。

包含

它用於提取在多個用例中重複的用例片段。它還用於透過將大型用例拆分為多個用例以及提取兩個或多個用例行為的公共部分來簡化大型用例。

用例之間的包含關係，由從基本用例到包含用例的帶有開放箭頭頭的虛線箭頭表示。箭頭用關鍵字«include»標記。

用例僅處理系統的功能需求。其他需求，例如業務規則、服務質量要求和實現約束，必須單獨表示。

下圖顯示了一個簡單的用例圖示例，其中所有元素都已標記。

成功應用用例的基本原則

• 透過講述故事來簡化
• 無需完美即可高效
• 理解全域性
• 識別用例的重用機會
• 關注價值
• 分片構建系統
• 增量交付系統
• 適應團隊的需求

用例模板

在這裡，我們展示了一個用例示例模板，業務分析師可以填寫該模板，以便技術團隊可以使用這些資訊來確定有關專案的資訊。

業務分析 - 需求管理

收集軟體需求是整個軟體開發專案的基礎。徵求和收集業務需求是每個專案的關鍵第一步。為了彌合業務需求和技術需求之間的差距，業務分析師必須充分理解給定環境中的業務需求，將這些需求與業務目標對齊，並正確地將需求傳達給利益相關者和開發團隊。

關鍵利益相關者希望有人能夠用簡單的英語解釋客戶/客戶端需求。這是否會使他們受益於高層次地理解價值？這將是主要關注領域，因為他們將嘗試將文件與需求進行對映，以及 BA 如何以最佳方式進行溝通。

專案失敗的原因

專案失敗的原因有很多，但一些常見領域包括以下方面：

• 市場和戰略失敗
• 組織和規劃失敗
• 質量失敗
• 領導力和治理失敗
• 技能、知識和能力失敗
• 參與度、團隊合作和溝通失敗

問題的核心在於專案日益複雜，變化頻繁，溝通具有挑戰性。

為什麼成功的團隊進行需求管理

需求管理是關於讓您的團隊保持同步並提供專案內部情況的可見性。

對於專案的成功至關重要的一點是，您的整個團隊都理解您正在構建什麼以及為什麼要構建它——這就是我們對需求管理的定義。“為什麼”很重要，因為它為關於需求的目標、反饋和決策提供了背景。

這提高了未來成功和潛在問題的可預測性，使您的團隊能夠快速糾正任何問題，並按時且在預算內成功完成專案。作為起點，讓所有相關人員對什麼是需求以及如何管理需求有一個基本的瞭解非常有價值。

讓我們從基礎開始

需求是利益相關者為解決問題或實現目標所需的條件或能力。系統或系統元件必須滿足或具備的條件或能力，以滿足合同、標準、規範或其他正式施加的檔案。

需求可以用文字、草圖、詳細的模型或模型來表達，任何能夠最好地向工程師傳達要構建什麼以及向質量保證經理傳達要測試什麼的資料。

高層需求有時簡稱為需求或目標。在軟體開發實踐中，需求可以被稱為“用例”、“功能”或“功能需求”。更具體地說，在敏捷開發方法中，需求通常被捕獲為史詩和故事。

無論您的團隊稱它們為什麼或您使用什麼流程；需求對於所有產品的開發都是必不可少的。如果沒有明確定義需求，您可能會產生不完整或有缺陷的產品。在整個過程中，可能有許多人參與定義需求。

利益相關者可能會請求一個功能，該功能描述產品將如何透過解決問題來提供價值。設計師可能會根據最終產品從可用性或使用者介面角度應該如何外觀或執行來定義需求。

業務分析師可能會建立一個符合特定技術或組織約束的系統需求。對於當今正在構建的複雜產品和軟體應用程式，通常需要數百或數千個需求才能充分定義專案或版本的範圍。因此，團隊必須能夠訪問、協作、更新和測試每個需求直至完成，因為需求在開發過程中會自然地隨著時間的推移而發生變化和發展。

現在我們已經從高層次定義了需求管理的價值，讓我們更深入地瞭解每個團隊成員和利益相關者都可以從中受益的四個基本要素：

• 規劃良好的需求：“我們到底在構建什麼？”
• 協作和認同：“快批准規範吧！”
• 可追溯性和變更管理：“等等，開發人員知道更改了嗎？”
• 質量保證：“你好，有人測試過這個東西嗎？”

每個人都知道我們在構建什麼以及為什麼嗎？這就是需求管理的價值所在。

利益相關者的協作和認同

每個人都瞭解情況嗎？我們是否已經獲得對需求的批准以繼續推進？這些問題在開發週期中出現。如果每個人都能就需求達成一致，那就太好了，但是對於擁有許多利益相關者的大型專案而言，這種情況通常不會發生。試圖讓每個人都達成一致可能會導致決策被延遲，或者更糟糕的是根本無法做出決策。就每個決策達成共識並不總是容易的。

實際上，您並不一定需要“共識”，您需要團隊的“認同”以及控制者的批准，以便您可以推進專案。達成共識，您試圖讓每個人都妥協並就決策達成一致。獲得認同，您試圖讓人們支援最佳解決方案，做出明智的決策並做必要的事情來推進專案。

您不需要每個人都同意該決策是最佳的。您需要每個人都支援該決策。團隊協作有助於在決策中獲得支援以及在規劃良好的需求方面獲得支援。

協作團隊努力確保每個人都參與專案並提供反饋。協作團隊持續分享想法，通常具有更好的溝通能力，並且傾向於支援做出的決策，因為他們對專案目標具有共同的承諾感和理解。

當開發人員、測試人員或其他利益相關者感到“脫離迴圈”時，溝通問題就會出現，人們會感到沮喪，專案也會被延誤。一旦每個人都認同了工作範圍，需求就必須清晰且有據可查。跟蹤所有需求的地方是事情變得棘手的地方。

想象一下，有一張長達一英里的待辦事項清單，需要與多個人協作才能完成。您將如何理清所有這些專案？您將如何跟蹤對一個專案的更改將如何影響專案的其餘部分？這就是可追溯性和變更管理增加價值的地方。

規劃良好的需求

那麼，什麼構成了良好的需求？良好的需求應該是有價值且可操作的；它應該定義需求並提供通往解決方案的途徑。團隊中的每個人都應該理解它的含義。需求的複雜性各不相同。

• 一份良好的需求文件可以作為一組文件的一部分，其中高層需求分解為子需求。

• 它們還可以包含非常詳細的規範，其中包括一組功能需求，描述最終產品的行為或元件。

• 良好的需求必須簡潔明瞭，並且應該回答“我們需要什麼？”而不是“我們如何滿足需求？”

• 良好的需求確保所有利益相關者都瞭解其計劃的一部分；如果部分內容不清楚或被誤解，最終產品可能會出現缺陷或失敗。

透過在需求演變過程中不斷從團隊那裡獲得反饋，可以防止需求失敗或誤解。與每個人的持續協作和認同是成功的關鍵。

需求收集和分析

需求是利益相關者為解決問題或實現組織目標所需的條件或能力；系統必須滿足或具備的條件或能力。

在軟體工程中，需求分析涵蓋了確定新產品或更改後的產品滿足需求或條件所需的任務，同時考慮各種利益相關者的可能衝突需求，分析、記錄、驗證和管理軟體或系統需求。

需求應：

• 有記錄的
• 可操作的
• 可衡量的
• 可測試的
• 可追溯的

需求應與已識別的業務需求或機會相關，並定義到足以進行系統設計的詳細程度。

業務分析師透過觀察現有系統、研究現有程式、與客戶和終端使用者討論來收集資訊。分析師還應該具備在沒有工作系統的情況下進行想象力和創造性思維的能力。分析收集到的需求以找到缺失的環節是需求分析。

引出方法

要引出目標，請向業務專家、開發經理和專案發起人提出以下問題：

• 這個專案將幫助公司實現哪些業務目標？

• 我們為什麼現在要進行這個專案？

• 如果我們以後再做會怎樣？

• 如果我們根本不做會怎樣？

• 誰將從這個專案中受益？

• 那些將從中受益的人是否認為這是目前可以做出的最重要的改進？

• 我們是否應該做不同的專案？

可能的目標可能是降低成本、改善客戶服務、簡化工作流程、更換過時的技術、試用新技術等等。此外，請確保您完全理解擬議專案將如何幫助實現既定目標。

不同型別的需求

業務分析師感興趣的最常見需求型別如下：

業務需求

業務需求是企業必須執行的關鍵活動，以滿足組織目標，同時保持與解決方案無關。業務需求文件 (BRD) 詳細說明專案的業務解決方案，包括客戶需求和期望的文件。

使用者需求

使用者需求應指定使用者期望/想要從軟體專案構建的軟體中獲得的具體需求。使用者需求應可驗證、清晰簡潔、完整、一致、可追溯、可行。

使用者需求文件 (URD) 或使用者需求規範通常用於軟體工程中，它指定使用者期望軟體能夠執行的操作。

系統需求

系統需求涉及定義軟體資源需求和前提條件，這些需求和前提條件需要安裝在計算機上才能提供應用程式的最佳功能。

功能需求

功能需求捕獲並指定正在開發的系統的特定預期行為。它們定義諸如系統計算、資料操作和處理、使用者介面以及與應用程式的互動等內容，以及其他顯示如何滿足使用者需求的特定功能。為每個需求分配唯一的 ID 號。

非功能性需求

非功能需求是指指定可用於判斷系統操作的標準，而不是特定行為的標準。系統架構說明了實現非功能需求的計劃。

非功能需求說明系統應該是什麼樣的，或者可以像“系統應該……”一樣提及。非功能需求被稱為系統的質量。

過渡需求

過渡需求描述解決方案必須滿足的功能，以便促進企業從當前狀態過渡到理想的未來狀態，但在過渡完成後將不再需要這些功能。

它們與其他需求型別有所不同，因為它們本質上總是臨時的，並且因為它們只有在定義現有解決方案和新解決方案後才能開發。它們通常涵蓋從現有系統轉換資料、必須解決的技能差距以及為達到理想的未來狀態而進行的其他相關更改。它們是透過解決方案評估和驗證來開發和定義的。

可追溯性和變更管理

需求可追溯性是一種組織、記錄和跟蹤從最初的想法產生到測試階段的所有需求的方法。

需求可追溯性矩陣 (RTM) 提供了一種方法來跟蹤功能需求及其在開發過程中的實現。每個需求都包含在矩陣中以及其關聯的節號。

隨著專案的進展，將更新 RIM 以反映每個需求的狀態。當產品準備好進行系統測試時，矩陣將列出每個需求、哪些產品元件解決了該需求以及哪些測試驗證了它是否已正確實現。

在 RTM 中包含以下每一列：

• 需求描述
• FRD 中的需求參考
• 驗證方法
• 測試計劃中的需求參考

示例：連線點以識別專案中各項之間的關係。它是常見下游流的聯結器。

理念 需求 設計 測試 業務目標

您應該能夠將每個需求追溯到其原始業務目標。

透過追蹤需求，您可以識別變更的連鎖反應，檢視需求是否已完成以及是否正在得到正確測試。可追溯性和變更管理為管理者提供了安心感和必要的可見性，以便預測問題並確保持續質量。

質量保證

第一次就交付正確的需求意味著更高的質量、更快的開發週期以及更高的客戶滿意度。需求管理不僅幫助您做到正確，還幫助您的團隊在整個開發過程中節省資金和避免許多麻煩。

簡潔、具體的需求可以幫助您儘早發現和修復問題，而不是在修復成本高得多的時候才發現。此外，在開發過程後期修復程式碼中的缺陷，成本可能高達修復需求時成本的100倍。

透過將需求管理整合到您的質量保證流程中，您可以幫助您的團隊提高效率並消除返工。此外，返工是大多數成本問題出現的地方。

換句話說，開發團隊浪費了大部分預算在第一次沒有正確執行的工作上。例如，開發人員根據舊的規範文件編寫一個功能，後來才發現該功能的需求已經改變了。透過有效的需求管理最佳實踐，可以避免這些型別的問題。

總而言之，需求管理聽起來像是一門複雜的學科，但當您將其簡化為一個簡單的概念時——它關乎幫助團隊回答這個問題：“每個人都理解我們在構建什麼以及為什麼？”從業務分析師、產品經理和專案領導到開發人員、質量保證經理和測試人員，以及相關的利益相關者和客戶——專案的失敗根源往往是對專案範圍的誤解。

當每個人都在協作，並且對整個專案生命週期中與需求相關的討論、決策和變更擁有完整的上下文和可見性時，成功就會持續發生，並且您可以保持持續的質量。此外，這個過程更加順暢，減少了參與者的摩擦和挫折。

注意 − 研究表明，專案團隊可以透過有效地管理需求來消除50-80%的專案缺陷。卡內基梅隆軟體工程研究所的資料顯示，“60-80%的軟體開發成本用於返工”。

獲得需求籤字

需求籤字正式確認專案利益相關者對已記錄的需求內容和表達方式的準確性和完整性達成一致。正式協議降低了在實施期間或之後利益相關者引入新的（以前未遇到的）需求的風險。

獲得需求籤字通常包括與每個專案利益相關者面對面地最終審查已記錄的需求。在每次審查結束時，都會要求利益相關者正式批准已審查的需求文件。此批准可以物理地或電子地記錄。

獲得需求籤字通常是需求溝通中的最後一步。業務分析師需要正式需求審查的輸出，包括在審查過程中提出的任何意見或異議。

商業分析 - 建模

業務模型可以定義為對業務或解決方案的表示，通常包括圖形元件以及支援文字以及與其他元件的關係。例如，如果我們必須瞭解公司的業務模型，那麼我們希望研究以下領域：

• 公司的核心價值觀
• 它服務於什麼？
• 它的獨特之處是什麼？
• 它的關鍵資源
• 主要關係
• 它的交付渠道

藉助建模技術，我們可以建立對企業使用的現有和擬議的組織結構、流程和資訊的完整描述。

業務模型是一個結構化模型，就像最終產品的藍圖一樣。它為規劃提供了結構和動力。它也為最終產品提供了基礎。

業務建模的目的

業務建模用於設計企業的當前狀態和未來狀態。業務分析師和利益相關者使用此模型來確保他們對企業的當前“現狀”模型有準確的理解。

它用於驗證利益相關者是否對擬議的解決方案的“未來狀態”有共同的理解。

需求分析是業務建模過程的一部分，並且構成了核心關注領域。“現狀”期間收集功能需求。這些需求由利益相關者提供，涉及業務流程、資料和業務規則，這些規則描述了將在未來狀態中設計的所需功能。

執行差距分析

在定義業務需求後，必須確定當前狀態（例如，當前業務流程、業務職能、當前系統功能和提供的服務/產品以及系統必須響應的事件），以瞭解人員、流程和技術、結構和架構如何透過尋求IT人員和其他相關利益相關者（包括業務所有者）的投入來支援業務。

然後執行差距分析，透過將確定的當前狀態與預期結果進行比較，評估是否存在任何妨礙實現業務需求的差距。

如果沒有差距（即，當前狀態足以滿足業務需求和預期結果），則可能不需要啟動IT專案。否則，應確定需要解決的問題/問題以彌合差距。

可以使用SWOT（優勢、劣勢、機會和威脅）分析和文件分析等技術。

評估擬議系統

BA應協助IT專案團隊評估擬議的IT系統，以確保其滿足業務需求並最大限度地提高為利益相關者提供的價值。BA還應審查組織支援向擬議的IT系統過渡的準備情況，以確保系統實施順利進行。

BA應幫助IT專案團隊確定擬議的系統選項和高階系統設計是否能夠滿足業務需求並提供足夠的業務價值來證明投資合理性。如果有多個系統選項，BA應與IT人員合作，幫助識別每個選項的優缺點，並選擇能夠提供最大業務價值的選項。

業務建模的指導原則

業務建模的主要作用主要在專案的啟動階段和詳細闡述階段，在構建和過渡階段逐漸減弱。它主要與業務的分析方面以及應用程式或軟體解決方案的技術對映有關。

• 領域和使用者差異 − 開發業務模型通常會揭示利益相關者之間存在分歧或混淆的領域。業務分析師需要記錄現狀模型中的以下差異。

• 多個工作單元執行相同的職能 − 記錄現狀模型中的差異。這可能是不同的部門或地區。

• 多個使用者執行相同的工作 − 不同的利益相關者可能會以不同的方式進行類似的工作。差異可能是不同業務部門的不同技能和方法的結果，也可能是企業服務的外部利益相關者需求不同的結果。記錄現狀模型中的差異。

• 解決方案機制 − 業務分析師應記錄ToBe解決方案是否將適應當前業務模型中的不一致之處，或者解決方案是否需要標準化。利益相關者需要確定遵循哪種方法。ToBe模型將反映他們的決定。

BA在ERP系統建模中的作用示例

業務分析師應該定義一個標準的業務流程並將其設定到ERP系統中，這對於高效實施至關重要。BA的職責還在於在實施之前用易於理解的語言定義開發人員的語言，然後利用最佳實踐並根據系統功能對其進行對映。

對系統的一個需求是GAAP匹配分析，它必須在以下方面取得平衡：

• 對技術變更的需求，即為了與現有實踐保持一致而進行的增強。

• 有效的變更，這與重新設計現有業務流程有關，以允許實施標準功能和應用流程模型。

功能業務分析師

領域專業知識通常是透過長期從事“業務”而獲得的。例如：

• 銀行職員瞭解客戶（個人和企業）可以操作的各種型別的賬戶以及詳細的業務流程。

• 保險銷售代表可以理解獲取保險單所涉及的各個階段。

• 市場分析師更有可能理解客戶關係管理系統中涉及的關鍵利益相關者和業務流程。

• 參與資本市場專案的業務分析師應該具備主題專業知識和對股票、固定收益和衍生品的深入瞭解。此外，他還應該處理後臺、前臺，並在應用風險管理模型方面擁有實際經驗。

• 醫療保健業務分析師需要對美國醫療保健財務和利用率指標有基本的瞭解，以及對EDI 837/835/834、HIPAA指南、ICD編碼–9/10和CPT程式碼、LOINC、SNOMED知識的技術經驗和理解。

一些業務分析師透過測試業務應用程式和與業務使用者合作來獲得領域知識。他們透過人際交往和分析能力創造了良好的學習環境。在某些情況下，他們會透過AICPCU/IIA和LOMA在保險和金融服務領域提供的少量領域認證來補充他們的領域知識。還有其他機構提供其他領域的認證。

其他主要活動

在徹底檢查了當前的業務流程之後，您可以提供高度專業的幫助，以識別最佳的系統建模方法。

• 組織準備以正式和統一的方式描述業務流程，以確保系統中的高效自動化。

• 協助您的團隊填寫開發人員可能提供的相關係統的標準問卷。

• 參與工作會議，定義對開發人員的需求。

• 檢查和控制您設定的需求是否已在描述系統未來模型的文件（藍圖）中正確“複製”和記錄。

• 準備資料並協助系統原型設計。

• 協助準備資料，以便以系統所需的形式遷移列表和餘額。

• 審查設定原型是否符合業務流程所有者定義的需求。

• 作為支援資源，協助您的IT團隊準備資料並實際執行系統中的功能和整合測試。

在下一節中，我們將簡要討論一些大型組織在IT環境中使用的一些流行的業務建模工具。

工具1：Microsoft Visio

MS-Visio是一款繪圖和圖表軟體，可以幫助將概念轉換為視覺化表示。Visio為您提供預定義的形狀、符號、背景和邊框。只需將元素拖放到圖表中即可建立專業的溝通工具。

步驟 1 − 要開啟新的 Visio 繪圖，請轉到“開始”選單並選擇“程式”→“Visio”。

步驟 2 − 將游標移到“業務流程”上，然後選擇“基本流程圖”。

以下螢幕截圖顯示了 MS-Visio 應用程式的主要部分。

現在讓我們討論每個元件的基本用途：

A − 螢幕頂部的工具欄與其他 Microsoft 程式（如 Word 和 PowerPoint）類似。如果您以前使用過這些程式，您可能會注意到一些不同的功能，我們稍後會探討這些功能。

選擇“幫助”→“圖表庫”是熟悉 Visio 中可以建立的繪圖和圖表型別的好方法。

B − 螢幕左側顯示特定於您正在建立的圖表型別的選單。在本例中，我們看到：

• 箭頭形狀
• 背景
• 基本流程圖形狀
• 邊框和標題

C − 螢幕中央顯示圖表工作區，其中包括實際的圖表頁面以及頁面旁的一些空白空間。

D − 螢幕右側顯示一些幫助功能。有些人可能會選擇關閉此視窗以增加圖表工作區的面積，並在需要時重新開啟幫助功能。

工具 2：企業架構師 (Enterprise Architect)

企業架構師是一個基於 UML 的視覺化建模和設計工具。該平臺支援軟體系統的設計和構建、業務流程建模和基於行業的領域建模。企業和組織使用它不僅可以建模其系統的架構，還可以處理這些模型在整個應用程式開發生命週期中的實現。

企業架構師的目的是確定組織如何最有效地實現其當前和未來的目標。

企業架構師有四個視角，如下所示：

• 業務視角 − 業務視角定義了業務日常運營的流程和標準。

• 應用視角 − 應用視角定義了組織使用的流程和標準之間的互動。

• 資訊視角 − 這定義和分類了組織為了有效運營而需要的大量資料，例如文件檔案、資料庫、影像、簡報和電子表格。

• 技術視角 − 這定義了組織使用的硬體、作業系統、程式設計和網路解決方案。

工具 3：Rational RequisitePro

收集、記錄、組織、跟蹤和更改需求，並在專案團隊之間溝通這些資訊的過程，以確保在整個專案生命週期中保持迭代和意外的更改。

監控狀態並控制對需求基線的更改。主要要素是變更控制和可追溯性。

RequisitePro 用於上述活動和專案管理目的，該工具用於查詢和搜尋，檢視作為需求一部分的討論。

在 RequisitePro 中，使用者可以處理需求文件。該文件是在 Reqpro 應用程式中建立並與專案資料庫整合的 MS-Word 檔案。在 RequisitePro 之外建立的需求可以匯入或複製到文件中。

在 RequisitePro 中，我們還可以處理可追溯性，這裡它是兩個需求之間的依賴關係。可追溯性是一種透過連結彼此相關的需求來管理更改的方法性方法。

RequisitePro 使跟蹤需求在整個開發週期中的更改變得容易，因此無需單獨檢視所有文件即可確定哪些元素需要更新。您可以使用可追溯性矩陣或可追溯性樹檢視來檢視和管理可疑關係。

RequisitePro 專案使我們能夠建立一個專案框架，在其中組織和管理專案工件。每個專案都包含以下內容：

• 常規專案資訊
• 包
• 常規文件資訊
• 文件型別
• 需求型別
• 需求屬性
• 屬性值
• 跨專案可追溯性

RequisitePro 允許多個使用者同時訪問相同的專案文件和資料庫，因此專案安全方面非常關鍵。安全措施可防止未經授權的使用者訪問專案文件，從而防止系統使用、潛在損害或資料丟失。

建議為所有 RequisitePro 專案啟用安全功能。這樣做可以確保對專案的所有更改都與進行更改的個人的正確使用者名稱相關聯，從而確保您擁有所有更改的完整審計跟蹤。