Blog

「軟體需求分析與塑模」- UML 應用於需求分析的技術

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

UML (Unified Modeling Language) 係由 OMG (Object Management Group) 所制定的一種以圖形作為軟體塑模 (modeling) 的標準。UML 2.X 規格總共制定了 14 種涵蓋軟體包括結構面與行為面的設計圖,其中適用於需求分析的設計圖主要有兩種:

  • 活動圖 (activity diagram):描述單一作業的業務流程。
  • 使用案例模型 (use case model):紀錄與描述系統功能。包含使用案例圖 (use case diagram) 與使用案例敘述 (use case description) 。

UML 活動圖比較適合描述單一作業流程內部的活動。所謂的「單一」業務流程係指在該流程內諸多活動的協力合作,以完成某一特定的企業目標 (specific business goal)。例如「請購流程」,它的目的在於:決定優先順位的供應商;而至於「採購流程」,它的目的在於:採購高品質的物料。

這些各有不同目的的作業流程,彼此之間可能會有某些關聯存在。例如上述的 「請購流程」,它會產出一請購確認的資訊,然後再將其傳入至「採購流程」。

利用活動圖並不適合描述有多個作業流程之間的關係,因為它揭露了作業流程內部的活動。描述過多的細節反而會失去多個作業流程之間關係表達的焦點。

適合描述多個作業流程的關聯的設計圖,可以利用UML for Erikson-Penker 企業擴充模型 (uml business extension model) 。下圖即為一個電子化採購系統關於「請購」與「採購」的「火箭圖」[註1]。

[註一] 因為 Erikson-Penker 語法內關於作業流程的圖示呈現的是一種 IPO (Input-Process-Output) 類似火箭的圖樣,所以簡稱為「火箭圖」。

圖例、請採購業務流程擴充模型圖 (多個作業流程的塑模)

圖例、請採購業務流程擴充模型圖 (多個作業流程的塑模)

圖例、請購作業流程活動圖 (單一作業流程的塑模)

圖例、請購作業流程活動圖 (單一作業流程的塑模)

至於資訊系統的系統功能分析,則以使用案例圖 (use case diagram)來作為塑模的表達。它很容易可以界定出系統開發/維護範圍、外界 (使用者/外部系統)與系統的關係。

圖例、電子化採購系統使用案例圖 (系統功能的塑模)

圖例、電子化採購系統使用案例圖 (系統功能的塑模)

另外也會使用系統循序圖 (system sequence diagram),表達參與者 (actor,一般指使用系統的人/角色,以及支援服務的外部系統。) 與系統之間的互動訊息 (message)。

系統循序圖是一種系統功能「實現 (realization)」的表達。如下圖 描述的是「Web ATM」系統其中「轉帳」系統功能的實現。系統分析師可以用此來表達參與者與系統/外部系統之間的訊息傳遞的互動關係。

圖例、實現「轉帳」系統功能的系統循序圖 (描述系統功能實現的塑模)

圖例、實現「轉帳」系統功能的系統循序圖 (描述系統功能實現的塑模)

「軟體需求分析與塑模」- 需求分析人員的職掌

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

針對「需求」作描述、紀錄與分析的人員統稱為「需求分析師 (requirement analyst, RA)」。

而以「企業」或「資訊系統」作為分析的標的來區分,需求分析人員的角色 (role) 可分為兩種:企業分析師 (business analyst, BA) 與資訊系統分析師 (information system analyst, 簡稱 SA)。

BA 涵蓋的分析範疇較 SA 來得廣,自然需較有整體性的架構觀;但相對細節,如對某一資訊系統的畫面操作或單一業務規則 (business rule),則無法來得比 SA 精細。

一般而言,BA 涵蓋的範疇有:

  • 企業策略的規劃。
  • 業務流程的制定與再造 (BPR, Business Process Re-engineering)。
  • 企業的塑模 (business modeling)。
  • 多個資訊系統之間的訊息交換與整合。

而對於資訊系統分析師 SA,一般較僅以單一資訊系統為分析的範疇:

  • 紀錄與描述未來某些活動 (activities) 會由資訊系統實現的作業流程。
  • 界定系統功能與非系統功能需求 (functional and non-functional requirements)。
  • 表單畫面的操作程序。
  • 表單需要的欄位資訊與業務規則的整理。

對於資訊系統的技術議題,SA 係從系統外觀 (把系統當黑箱) 看待系統所提供的服務 (系統功能),以及實現該功能的操作程序、業務邏輯與所需欄位資訊等。所以 SA 一般不會涉及到結構性的設計議題,諸如資料庫的資料模型 (data model) 設計,那是由 SD (System Designer) 所負責;以及程式寫碼的實作議題,那是由 Programmer 負責。

再則 BA/SA 一般並不需具備某一領域 (domain) 的相關知識,那應是由領域專家 (domain expert) 所負責。但BA/SA 需能具備與領域專家溝通的技能,例如了解該領域所常使用的詞彙術語與其意涵。

另 BA/SA 合作的對象除了領域專家外,當然會包括各類開發人員,諸如專案經理 (Project Manager)、SD (System Designer)、Programmer (程式設計師) …等。

而訪談的對象也包括了客戶單位的利益關係人 (stakeholder)、操作人員 (operator) …等。

簡而言之,BA/SA 最大的挑戰在於如何與各類不同角色的人員達成順暢的溝通,並進而引導發掘出其潛在甚或模糊的需求,且得以條理分明地讓開發人員理解而轉成實作的程式。

「軟體需求分析與塑模」- 物件合作

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現 (realize) 軟體資訊系統功能,從物件導向 (object-oriented) 的觀點來看待時,系統內部的主要組成元素是「物件」,也可以稱為「個體 (instance)」。可以想像軟體系統內部就是由擔任各種不同職掌的類型物件,為實現某一特定功能,在動態期間 (run-time) 的互動合作來協力完成。

關於物件如何分類 (classify),這就是所謂物件導向結構設計的議題。分類作得好,讓系統具有低耦合 (low coupling) 、高內聚 (high-cohesion)的特性,如此系統的應變更具彈性、延展性,並得以提昇再利用性的高度價值。

參考下圖範例,是利用 UML 循序圖 (sequence diagram) 表達實現「餐飲管理系統」其中「點餐」系統功能的物件合作 (object collaboration) 情形。程式開發人員應該可以很容易對應至程式碼的類別 (class) 與方法 (method) 的實作。

圖例、實現「點餐」系統功能的物件合作循序圖

軟體結構設計是屬於系統的內部結構設計議題,而需求分析則是站在系統外部的觀點來看待系統所提供的服務 (系統功能),這是完全不同的兩種構面,不能混為一談。一般在需求分析階段,是會把系統當成「黑箱 (black blox)」來看待,只專注在外界 (人或外部系統) 如何與系統的溝通互動,至於系統內部如何組織分類與實作,那就會由結構與程式設計師來負責的。

「軟體需求分析與塑模」- 流程與活動

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現企業層級系統功能的主要組成元素是「人」,也就是多個不同角色的內部工作者 (internal worker) 在不同的時間點合作接續以完成所屬職掌的工作。

當為了履行一個企業需求,可能需一連串的活動 (activities) 循序接力達成。當然活動的執行需要有特定的參與人員,也就是會有多種不同角色 (role) 或組織 (organization) 參與。這一連串的活動即構成作業流程 (business process)。

Jacobson 為企業流程 (business process) 作了一個簡單的定義:

Put simply, a business process is the set of internal activities performed to serve a customer.
Object Advantage》, Ivar Jacobson, 1994
(簡單地說,企業流程就是要能夠服務客戶的一連串企業內部的活動)

而關於「活動 (activity)」的定義 (from Wiki):

Activity is a major task that must take place in order to fulfill an operation contract.
(活動是一個必須履行的主要工作,為以滿足一個操作上的契約。)

參考下圖範例係利用 UML 活動圖 (activity diagram) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

圖例、傳統人工訂購-出貨作業流程

「軟體需求分析與塑模」- 什麼是系統功能

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

系統 (system) 是由一組互動 (interacting) 或獨立的元件 (component) 所組成的整合體 (integrated whole)。

系統功能 (system functions),即為某一整合體所提供給外界 (參與者或外部系統)的一連串服務 (services)。

把企業 (business) 當成一個整合體,並藉以分析該整合體所提供的功能需求,以及組成該整合體的組成元素。這樣以企業為標的的分析塑模方式,稱為「企業塑模 (business modeling)」。

把資訊系統 (information system) 當成一個整合體,並藉以分析該整合體所提供的系統功能,以及組合該整合體的結構元素。這樣以資訊系統為標的的分析塑模方式,稱為「資訊系統塑模 (information system modeling)」。

把企業或資訊系統當為一個整合體,便可以採用相同的手法,如利用 UML (Unified Modeling Language) 語法,來分析系統需求。

「企業」與「資訊系統」兩者的關係即為,「資訊系統」為組成「企業」內部結構的其中之一的元素 (element)。而當把焦點轉移至資訊系統,探究其中所提供的系統需求 (系統功能)時,則再將「資訊系統」這個結構元素放大,並從「外」的需求分析,與「內」的結構設計來看待資訊系統的分析、設計,乃至於實作了。

參考上節範例,「診療服務」為企業的系統需求,如果企業架構師規劃了三個資訊系統 (組成元素) 的支援,參考如下圖,架構師可以利用 UML 使用案例圖表 (use case diagram) 規劃每一個資訊系統各有其需實現的系統功能,以及資訊系統之間的關係是透過介面 (interface)的連接達成所謂的「SOA (service-oriented architecture)」架構。

圖例、表達資訊系統的系統功能

至於資訊系統是如何實現系統功能,又如何連接其它外部系統,那就是所謂的系統 (這裡就是指資訊系統了) 結構設計與實作的議題了。

「軟體需求分析與塑模」– 企業需求源自於企業價值

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

企業需求要能提供價值 (value),如此才得以讓企業有獲利行為而能永續經營。

「價值」的呈現取決於在創新、成本、效率等因子的調和。這些因子經常是由內部工作者 (internal-worker)、產品、系統、軟體與流程 (process)等所提供並滿足其需求。最終目的當然在於讓企業創造「利潤 (profit)」。

例如,「仁心慈善醫院」是一家企業 (business),其中最主要的核心價值係提供 「醫療」的服務 (service)。為了提供「醫療」這個主要服務,企業內部必然會有多個內部工作者的協同合作,包括「醫師」、「護士」、「藥劑師」、「行政人員」… 等;涵蓋的作業流程可能有「掛號」、「看診」、「住出院」、「領藥」… 等;且為了增進處理效率與節省人力,會導入由 產品/軟硬體 所組成的資訊系統 (information system),成為工作者的協力夥伴。

除了文字陳述紀錄外,可以藉由視覺化的圖形塑模 (visualization diagram modeling),更容易表達焦點。

例如,我們可以使用 UML「使用案例圖 (use case diagram)」表達企業所提供的主要服務 (企業層級的系統功能),以及使用「業務流程圖 (business process diagram)」表達實現 (realize) 企業系統功能的主要組成元素 (內部工作者、資訊系統、主要作業流程)。

圖例、表達企業提供的主要服務

圖例、表達實現企業需求內部的主要組成元素

關於 UML (unified modeling language) 的基本介紹,以及應用在企業與資訊系統需求面的分析 Know-how,參閱後述的章節內容。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal