IT 觀察者隨筆 - 資訊科技博客 - 第 68 頁，總計 84 頁 - 聚焦資訊科技內容領域最前沿資訊，網絡精華，心得交流

如何將工作流程與 BPMN 集成？

業務流程圖是為你的公司或部門建立工作流程模型的一個非常好的工具，因為它清楚地顯示了誰負責某項任務以及流程的流程。然而，業務流程圖並沒有告訴我們應該如何執行一項特定的任務。

決策表是一個很好的工具，可用於測試和需求管理。從本質上講，當處理複雜的業務規則時，它是一種結構化的練習來製定需求。在決策表中，業務邏輯被很好地劃分為條件、行動（決策）和規則，用於表示形成業務邏輯的各種組件。

我們在軟件開發中總是會遇到這些術語。有時人們一塊軟件的功能–需求/用例，積壓項目….。軟件人員使用這個或哪個的慣例是什麼？

在軟件開發中，通常的“估計”包括對執行給定開發任務所需工作的定量評估；這通常以持續時間（小時/天）或估計單位（故事點）來表示。目的是合併一些這樣的單獨估計，以獲得軟件項目的總體持續時間、工作或成本的指示。

UML用例圖是開發中的新軟件程序的系統/軟件要求的主要形式。用例指定了一個系統的預期行為（what），而不是使之發生的確切方法（how）。一套完整的用例規定了使用系統的所有不同方式，因此定義了系統所需的所有行為，限定了系統的範圍。

一個用例是對用戶如何在你的系統上執行任務的書面描述。它從用戶的角度概述了系統在響應一個請求時的行為。每個用例都表示為一連串的簡單步驟，從用戶的目標開始，到目標實現時結束。

用例2.0是一種可擴展的、敏捷的方法，它使用用例來捕捉需求，並推動系統的漸進式發展以滿足這些需求。它幫助你了解系統將如何被使用，並引導你開發一個合適的系統來支持用戶。

用例圖模擬了不同類型的用戶與系統的互動，以解決一個問題。因此，它描述了用戶的目標，用戶和系統之間的互動，以及系統在滿足這些目標時的必要行為。用例定義了外部角色和系統之間的互動，以達到特定的目標。一個用例圖包含四個主要部分

2011 年夏天，Ken Schwaber 和 Jeff Sutherland 修改了他們的 Scrum 指南。在其中，他們刪除了 Scrum 已知的一種長期存在的行為，即團隊對產品所有者和客戶的承諾。承諾被預測取代。他們說團隊可能會預測他們的工作，但不會承諾。

完成的定義（DoD）是一個用戶故事必須遵守的要求列表，以便團隊將其稱為完成。而用戶故事的驗收標準由一組測試場景組成，這些測試場景需要被滿足，以確認軟件是按預期工作的。