軟體專案需求開發過程實踐之業務建模用例圖

        本次軟體工程專案是重建辦公業務流程管理平臺，需要在繼承原370個流程基礎上，還需要提供快速流程開發能力，並要求體現出流程管理的規範性，以及流程的執行力、效率、效益，最終為企業管理創新提供流程再造的能力。

        在專案前期及需求分析階段，開發人員致力於“降低成本”，以最小的代價完成專案，其可預見性的軟體產品是經過系統平臺升級的，並經過改良的第二個辦公業務流程管理平臺。按客戶驗收要求，“只能打60分，是不能給予驗收”。

        在軟體開發中，需求工作致力於解決“產品好賣”的問題，設計工作致力於解決“降低成本”的問題。二者不能相互取代。如果需求和設計不分，利潤就會縮水。從需求直接對映設計，會導致功能分解得到重複程式碼。如果從設計出發找需求，會得到一大堆假的“需求”。

        拿自古以來就有的一個系統“人體”來舉例。人體對外的功能是會走路，會跑步，會跳躍，會舉重，會投擲，會游泳…。但是設計人體的內部結構時，不能從需求直接對映到設計，得到“走路子系統”、“跑步子系統”、“跳躍子系統”…。人體的“子系統”是“呼吸子系統”、“消化子系統”、“血液迴圈子系統”、 “神經子系統”“內分泌子系統”…..。

        首先，回顧我們常用的軟體需求開發過程。

        1. 需求分析定義

        在軟體工程中，需求分析指的是在建立一個新的或改變一個現存的資訊系統時描寫新系統的目的、範圍、定義和功能時所要做的所有的工作。需求分析是軟體工程中的一個關鍵過程。在這個過程中，系統分析員和軟體工程師確定顧客的需要。只有在確定了這些需要後，他們才能夠分析和尋求新系統的解決方法。需求分析階段的任務是確定軟體系統功能。

        2. 需求開發過程綜述

        （1）目的：

        用以指導專案組客觀、準確地識別和文件化客戶及相關干係人的需求，並在已確認的使用者需求基礎上完成軟體需求的分析及文件化工作。

        （2）角色職責：

        客戶經理：協助專案經理與顧客的溝通與需求的獲取。

        專案經理：.負責全程的需求標識的管理。及時與顧客進行溝通，瞭解客戶需求，審查客戶所提需求，協調對需求標識的評審。

        專案成員（需求開發人員）：協助專案經理完成客戶需求的收集；將收集的需求，通過分析、整理製作成文件；協助專案經理審查收集到的顧客的初始需求。

        客戶代表：儘可能完整、準確的提出系統所要求的目標、功能、效能、技術、介面、安全水平等需求。並對需求評審結果進行確認。

        使用者代表：為客戶代表和專案成員提供業務需求，並對需求結果進行確認。

        （3）輸入：

        所有與客戶需求相關的材料。

        （4）輸出：

        原始需求索引表；

        使用者需求說明書；

        需求獲取分析表；

        需求用例文件；

        軟體需求說明書

        （5）開發過程

        

                                     圖1

        3、關鍵開發活動

        （1）“確認使用者需求”活動中，不僅要形成使用者需求說明書（格式不限，只要求把需求描述清楚），還必須有使用者方客戶代表簽字確認，最好內附使用者代表確認簽字。

        （2）“評審需求文件”活動，不能省略，需要系統分析、設計人員全面瞭解、分析需求，確認需求分析描述清楚，並且不超出範圍。

        （3）“建立及釋出需求基線”活動，通過此活動固化了需求，並要求建立需求跟蹤矩陣。

        

        接著，我們再重點說需求分析。

        需求分析藉助UML建模工具EA，通過EA進行業務建模和開發需求用例和物件模型。此段重點關注業務建模實踐過程，回答辦公業務流程平臺要做什麼？

        1、業務建模

        在業務建模用例圖上表述出370個業務流程是不合適的，這些流程的功能基本是一致的。流程業務通常情況是這樣的，工作人員填寫業務申請單（填寫表單），並準備好相關資料（新增附件），把業務申請單和資料打包（儲存）後，送出傳遞給流程下一環節審批人辦理。

        既然要管理370個流程，而且是不停在變的流程，那麼從流程建模開始，到流程上線應用、執行流程例項，再到對監控及分析流程，對流程的使用情況進行績效管理。這樣，流程再造是永恆的主題，這也是回答辦公流程平臺要做什麼。至於快速開發流程、監控分析流程，以及體現執行力、效率等管理目標都是屬於表面只管需求。業務建模是要通過資訊化管理模型來提供有效流程再造的支撐，以此達到管理創新的終極目標。

       

                                                                                               圖2

        通過上述分析，業務建模就不必畫具體流程用例，也不必畫具體報表用例…。下圖3才是辦公業務流程平臺系統核心業務模型用例，而資費審批流程、中層領導請假流程…，僅僅是流程模型【注：為圖3中監管流程（定義）資訊】不同。

                                                                                     圖3

        業務模型應用簡單場景如下：

        （1）通過快速開發流程（建模流程）用例，開發資費審批流程模型，併發布流程；

        （2）申請、審批流程用例，是執行流程例項；

        ……。

        2、系統平臺建模

        此係統平臺用例，本不應該放在此處，但是，由於此專案的特殊性，建設目標之一是搭建辦公能力平臺，所以，就出現了系統平臺建模，也可以看作系統用例。概念有些模糊，姑且先放在這兒。

                                                                                              圖4

        為什麼需求經常“容易變化”？根源之一是它們的來路不正，一開始的時候是拍腦袋得來的，沒有把系統當作一個零件放在組織中來看，得到的系統當然和組織的其他零件格格不入，系統上馬磨合後發現問題，自然要改。“需求變化劇烈”只是一個假象，許多需求的變化是假的變化，真正的需求並沒有變化，只不過開發人員一開始捕獲的需求是假的。如果能正確運用業務建模技能，大多數假的需求變化會消於無形。

        業務用例是組織的、而不是組織內某個系統的用例。組織的用例不會因為某個人肉系統或電腦系統的存在或消失而改變。

        綜上所述，軟體專案需求開發過程中，業務建模是非常重要的活動，直接關係到專案的成敗。而本專案實質是使用者化的BPM，例如解決人員跨組織問題，以及提供流程業務資料統計支撐需求等。

參考及摘自：

        《軟體方法》UMLChina 潘加宇 2012.11

        易擴充套件的辦公流程化管理核心模型（第1版） 肖永威 2015.1

        用MongoDB資料庫來管理辦公系統中文件型的表單和資訊——通用流程化應用審批單設計思路（二，續） 肖永威 2015.1