Blog

「軟體需求分析與塑模」- 企業層級系統塑模的範疇

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

把企業/組織當成系統作需求分析,其系統功能的實現 (realization),由於涵蓋作業的時間長,且會有多類角色的參與者 (participant) 參與期間,以組成一連串的協力活動 (activities)。

而關於企業多人使用的資訊系統,如 MIS (Management Information System)、ERP (Enterprise Resource Planning)、電子商務 (e-commerce)、電子服務平台 (e-service platform) …等,也常需先分析與描述為達成企業某一特定目的 (specific goal) 需求時,原來傳統人工作業的活動,這往往是未來為分析資訊系統功能的前置引導作業。

所以對於「活動」流程的表達,必然是對於企業本身、企業層級的資訊系統等的系統需求分析,是一種必要的開發儀式。

前一章節已提及,單一特定目的作業流程適於採用 UML 活動圖 (activity diagram) 記錄;而表現多個作業流程之間的關聯性,則適於採以「erikson-penker」uml 流程擴充圖來表達。本章節針對這兩種設計圖,就語法與操作應用上作詳細的說明。

另外特別強調的,需求分析師在描述作業流程,盡量不要加入「資訊系統」的參與, 原因有二 [註1]:

  1. 不容易界定資訊系統的開發/維護範圍。
  2. 不容易瞭解會有幾個資訊系統的參與。

[註1] 資訊系統範圍的界定與系統的切分,係由擔任系統整體架構規劃的架構師 (architect) 所負責。需求分析師在初期並不容易瞭解資訊系統的責任,所以最好不要在作業流程的表達加入資訊系統的角色,以免容易造成混淆。

所以作業流程,適合描述的是傳統的人工作業,也就是所有的參與者必定是「人」或「組織」所擔任的角色 (role)。

至於資訊系統的系統功能 (system functions) 分析,會採以較適合的塑模技術,例如使用案例模型,這在後續章節即會詳述。

企業流程與資訊系統功能的分析與描述,這裡採以「MSS」三層次的塑模分析方法,如此可以有效表達在人工與資訊系統的「活動-系統功能」間的關係,並得以讓設計圖表現得簡潔,自然能形成一種層次分明、井然有序的設計框架。

  • M-Multiple Process (跨多個作業流程)。
  • S-Single Process (單一作業流程)。
  • S-System Function (資訊系統功能)。

「軟體需求分析與塑模」- 區分功能性需求與非功能性的需求

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

所謂的功能性需求 (functional requirements) 即是使用者需要系統能為他做什麼。這往往是顯而易見的,因為,使用者可以清楚的看到系統為他服務並會有回應。例如在一個訂購系統中,功能性需求有:

  • 系統接受顧客的訂購 (系統功能-place order),並且會通知倉管該產品庫存量是否充足。
  • 系統會對前一日的訂購在當夜會產生統計報表 (系統功能-process order summary report)。

系統的功能性需求源自於開發或維護中系統的問題領域 (problem domain)。例如「電子商務系統」,功能性需求有「處理訂購」、「追蹤訂購」…等。

功能性需求需直接滿足於使用系統的操作人員或相關利益關係人 (stake holder),它是屬於系統的「顯性價值」,是與企業的需求有直接的關聯。

功能性需求的分析技術即為本書內容的重點。各類軟體開發方法論均有提供如何分析系統功能的技術。例如 Agile (敏捷式) 的「user story」、SCRUM 的「backlog」,以及行之有年的「use case (使用案例)」。本書的系統功能分析主以「使用案例」的分析技術來捕捉系統功能性需求。它既能包容其它需求分析的技術,又能很順暢橋接到結構設計與程式寫碼實作,這在後續的章節即會詳述,並會以案例研討的方式舉例說明。

非功能性的需求 (non-functional requirements) 往往是使用者所感受不到系統有直接提供服務並有回應。非功能性的需求是總體 (global) 的、模糊 (fuzzy) 的一些因素而導致系統整體的良好運作。例如:

  • 系統要能處理超過1千人以上線上訂購書籍的效能 (performance issue)。
  • 系統為了要能應付日增的交易處理,所以必須要能具備延展性 (scalability issue)。
  • 系統的登入 (logon) 須具有密碼加密的機制 (security issue)。

系統的非功能性需求源自於開發或維護中系統的解題領域 (solution domain)。例如「電子商務系統」採以「JEE (Java Enterprise Edition) + Spring Framework」的實作解題技術框架。

非功能性需求是屬於系統的「隱性價值」。它不容易被直接感受到,只有當碰到系統整體性的震盪 (如多人操作存取時的效能與穩定問題、帳戶安全性問題)時,系統的品質問題與危機意識等才會浮現出檯面。

一般非功能性需求較被列為實作面的考量,例如下列幾個實作議題:

  • 多人上線時的交易效能與穩定性。
  • 安全性的考量。
  • 分散式溝通議題。
  • 延展性議題。
  • 異地備援/災難重建議題。

非功能性需求並非採以上述所提及的系統功能分析 (如 use case) 技術,一般它可能僅以清單列表的方式註記並列為系統的一種約束 (constraint) 即可。

「軟體需求分析與塑模」- 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) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

圖例、傳統人工訂購-出貨作業流程
軟體思維顧問

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

Personal