第 3 章建立需求模型

1

第 3 章建立需求模型

Prepared by S. F. Chang

2

系統分析階段概述 P123

系統分析階段的整體目的在於了解所提議成立的專案，同時確認它能夠支援企業需求，且為後續的系統開發打好基礎。在此階段，你運用各種模型及文件工具來預見並描述所提議的系統。

• 系統分析的活動系統分析階段包含三個主要活動 : 建立需求模型、建立企業模型 ( 即建立資料與處理工作模型 ) ，及考量開發策略。

建立需求模型 (requirements modeling #) ，其中包括了發現事實來描述目前的系統並指出新系統的需求，例如 : 輸出、輸入、處理工作、績效及安全等需求。輸出 (outputs #)係指由系統產生的電子或列印的資訊。

3


輸入 (inputs #) 係指需要輸入到系統的資料，不論是以人工或是以自動化的方式來進行。處理工作 (processes #) 則是指用來將資料轉化為有用的資訊的邏輯規則。績效 (performance #) 則是指系統的特質，如速度、資料量、容量、可靠性及穩定性。安全 (security #)則是指用來保護系統及其資料免於內部或外部威脅的各種硬體、軟體、及流程控制。

建立資料與處理工作模型即是運用傳統結構化分析技術，以圖形來表示系統資料及處理工作，而繼續模型建立的流程。在結構化分析中，視資料及處理工作為個別的元件。

4


在開發策略中，你將要考量各種開發的方式並準備轉入 SDLC 的系統設計階段。

系統分析階段的交付標的或產出是一份系統需求文件 (system requirement document #) ，這份文件是新系統的整體設計藍圖。除此之外，系統分析階段中的每一個活動各自有產出及一個或多個里程碑。

• 系統分析技巧為了正確地建立新系統的模型，你必須具備良好的分析技巧和人際技巧。

分析技巧使你能夠明辨問題所在、評估關鍵因素，並開發出有用的解決方案。

5


人際技巧對一個必須與組織內各層級的人合作，並需在使用者互相衝突的需求間求得平衡，並做有效溝通的分析師而言，實在是非常的重要。

• 團隊導向方法及技巧許多 IT 經理試圖提高使用者在開發過程中的參與度，使用者的高度參與往往會造成較好的溝通、更快的開發時間，及更滿意的使用者。

許多公司現在是用小組方式來開發資訊系統。例如，聯合應用系統開發 (JAD, joint application development #) 方法，就是一種用來發現事實及建立需求模型的團隊導向的技術。

6


另一種廣泛使用的使用者導向方法是快速應用系統開發 (RAD, rapid application development #) 。 RAD 是完整 SDLC 的精簡版本，其中使用者隨時參與每一個步驟。

相較於 JAD 一般只著重在發現事實及需求確認， RAD 對整個系統開發工作的全程提供一個快捷的方法，其中包括規劃、設計、建構，及切換。

7

聯合應用系統開發方法 P125

• 使用者參與使用者在資訊系統中有重大的關聯，而且他們應該在開發過程中完全參與。

在開發的過程中， IT 人員會從使用者那裏收集資訊、定義系統需求，並建構新系統。在過程中的各階段， IT 人員可能會要求使用者複閱其設計、提供意見，並提出修改的要求。

IT 專業人員現在已體認到成功的系統必須是使用者導向的，而使用者需要參與系統開發的每一階段，不論是正式或非正式地。

8


在 JAD 團隊方式中對於使用者參與有一個廣受採用的策略，其中涉及一個由使用者、經理人，及 IT 專家組成的特別工作小組。他們一同工作以取得各種資訊、討論企業需求，及定義出新系統的需求。

• JAD 參與者及其角色 JAD 小組通常每隔幾天或幾週開一次會，地點可能是在公司的會議室，也可以到公司外任意的地點。不管是用什麼形式， JAD 成員必須不被其日常的業務干擾。其目的在於分析現行系統、設法找出潛在的解決方案，及對新系統的需求達成共識。

9


一般 JAD 成員及其角色

JAD 成員角色JAD專案領導人發展議程、擔任召集人及主持 JAD會議。高階管理人提供對專案的高層授權及支援。管理人員對專案提供部門層級的支援，並了解本專

案必須如何支援企業功能及需求。使用者提供對目前作業、希望的改變、輸入輸出

需求、使用者介面議題，以及本專案該如何支援每日例行任務等操作層次的意見。

系統分析師及其他 IT人員

為整體 JAD的小組成員提供如︰安全性、備份、硬體、軟體，及網路容量等技術面的協助和資源。

會議記錄記錄 JAD會議的結果，並配合系統分析師建立系統模型及發展 CASE工具文件。

10


• JAD 的優缺點缺點︰與傳統方法相比較， JAD 成本較高

且如果小組相對於專案規模顯得太大時也可能變得繁複。

優點︰ 1. JAD 讓主要的使用者有機會在需求模型建立的過程

中有效的參與，讓使用者們比較會對其結果產生歸屬感而支持新系統。

2. 當運用得當時， JAD可以產生更精確的系統需求描述、對共同目標更加了解，以及對新系統的成功提供更強的保證。

11

快速應用系統開發 P128

快速應用系統開發 (RAD) 是一種能夠加快資訊系統開發速度，且產生一個能夠運作的資訊系統的一種以團隊為基礎的系統開發技術。

如 JAD 一殷， RAD也採用團隊方法，但是更為深入。相較於 JAD 是一套需求模型， RAD 的最後產出則是一個新的資訊系統。

RAD 是一套完整的方法論，其中包括一個與傳統 SDLC 各階段相對應的四階段生命週期。許多公司採用 RAD 來降低成本及系統開發時間，並提升成功的機率。

RAD 非常仰賴雛型的建立及使用者的參與。 RAD的過程允許使用者儘早能夠檢視一個可運作的模型、判定它是否能滿足其需求、並建議必要的變更。

專案小組採用 CASE 工具來建立雛型，並且產生一系列的文件。

12


• RAD 各階段及其活動RAD 模型包含四大階段 : 需求規劃、使用者設計、建構及切換。需求規劃階段 (requirement planning phase) 結合了 SDLC 中系統規劃及系統分析階段的所有元素。 (**** 參考下兩頁之插圖 )

在使用者設計階段 (user design phase)期間，使用者與系統分析師互動，並產生能夠代表所有系統處理工作、輸出，及輸入的模型及雛型。 RAD 團隊或次團隊通常混合使用 JAD 技術及 CASE 工具來轉化使用者需求成為可運作的模型。使用者設計是一個允許使用者去了解、修改，並最後認可一個符合其需求的可運作系統模型的連續互動的過程。

13


建構階段 (construction phase)著重在與 SDLC 相似的程式及應用系統開發的工作。然而在 RAD 中，在實際的螢幕畫面或報表在開發時，使用者持續地參與並仍然可以建議做修改或改善。

切換階段 (cutover phase) 與 SDLC 中建置階段的最後任務相似，包括資料轉換、測試、轉換到新系統，及使用者培訓。與傳統的方法比較，其整體的過程是壓縮了。其結果是新系統更快地被打造、交付，並開始運作。

14

圖 1-27 SDLC 的各階段及其交付標的 p36

階段 1:系統規劃

階段 2:系統分析

階段 3:系統設計

階段 4:系統建置

階段 5:系統運行與支援

系統申請

初步調查報告

系統需求文件

系統設計規格

功能完備的資訊系統

運行的資訊系統

Stop停止開發專案



相似於 RAD 的需求規劃階段

相似於 RAD 的使用者設計階段

相似於 RAD 的建構階段及切換階段

15

圖 3-7 RAD 模型中的四階段為需求規劃、使用者設計、建構，及切換

需求規劃

使用者設計建構

切換

任務 :

.使用者、經理人，及lT人員對業務需求、專案範圍及系統需求獲致協議

. 獲得繼續推動的授權

任務 :

. 與使用者互動

. 發展模型及雛型

. 實施密集的 JAD 形式的會議

任務 :

. 程式及應用系統開發

.編碼

.單元、整合及系統測試

任務 :

. 資料轉換

. 全面測試

. 系統轉換

. 使用者培訓

16


• RAD 目標所有 RAD 方法的主要目標是藉由使用者在系統開發每一階段的參與來減少開發的費用及時間。因為它是一個連續的過程，當設計演化中，RAD 容許開發小組快速地做出必要的修改。

除了使用者參與之外，一個成功的 RAD 小組也必須要有 IT 資源技術、及管理者的支持。

17


• RAD 的優缺點與傳統結構化分析方法相較 RAD 有其優點及缺點 :

優點︰系統可以在節省大量成本之下快速地被開發出來。

缺點︰1. RAD強調系統本身的機制而不注重公司的策略性

業務需要，其風險在於短期內系統可能運作良好，但是公司及系統的長期目標不見得相符。

2. 加速的週期時間，可能導致無暇兼顧品質、一致性，及設計標準。然而，若是一個企業組織了解可能的危機， RAD 可以是一個誘人的替代方法

18

建立模型的工具及技巧 P131

模型可以幫助使用者、管理者，及 IT 專業人員了解系統的設計。在建立需求模型時你可以使用各種工具來描述業務流程、需求，及使用者與系統間的互動。

• CASE 工具 CASE 工具可以提供強力的模型建立功能。系統分析師交替地使用模型建立及發現事實，首先他們將發現事實的結果建入模型，然後再研究此模型以決定是否需要額外的發現事實工作。

為了協助他們了解系統需求，系統分析師經常使用能夠提供企業導向概觀的功能分解圖，及能夠展示出人們如何與該系統互動的統一建模語言。

19


• 功能分解圖功能分解圖 (FDD, functional decompositio

n diagram #) 是一種由上而下展示企業功能與流程的方法， FDD也被稱為結構圖 (structure chart #) 。使用 FDD 分析師能夠展示出企業功能並且將它們分解為更低層的功能及流程。 ( 參考圖3-9) (亦稱為 HIPO 圖，即 Hierarchical Input Process Output 的縮寫 )

FDD 可以在系統開發的許多階段被使用。在建立需求模型的階段，分析師用 FDD 來建立企業功能的模型，並展示它們是如何地被分解成更低一層的處理單元，這些處理單元在應用系統開發時可轉換為程式模組。

20

本圖節錄自「電子商城購物網站系統」，陳宗興策劃，知城數位公司出版

1.0會員專區

本龍電腦商城系統

2.0產品專區

4.0熱門商品

3.0本週新品

5.0購物車

1

1

1.3新會員的修改

1.2新會員的查詢

1.1新會員的加入

1

2.3刪除選購產品

2.2修改選購產品

2.1選購產品

1



3.1選購本週新品

1



4.1選購熱門商

1



21

本圖節錄自「餐飲業網站訂位管理系統」，陳宗興策劃，知城數位公司出版

2000/12/13

HIPO

首頁0.0

客訴處理6.0

飯店簡介1.0

訂位服務5.0

會員登錄8.0

訂位查詢7.0

特賣活動4.0

新品快訊3.0

商品瀏覽2.0

內容介紹1.1

中式餐廳介紹1.1.1

西式餐廳介紹1.1.2

自助餐聽介紹1.1.3

中餐商品2.1

西餐商品2.2

自助餐2.3

新品介紹3.1

印折價卷4.1

登入畫面6.1

登入畫面7.1

資料輸入8.1

登入完成8.1.1

顯示資料7.1.1

訴求內容6.1.1

餐點內容5.1.1

訂餐5.1

修改刪除5.1.1.2

顯示資料5.1.1.1.1

新增5.1.1.1

22


• 統一建模語言統一建模語言 (UML, Unified Modeling Lan

guage #) 是一種廣受採用於將系統設計視覺化及建立文件的方法。

UML採用物件導向設計的觀念，但它獨立於任何特定的程式語言，被用來描繪企業流程和需求。

UML 提供幾種圖形工具和技術，例如 : 使用情況圖及次序圖。

使用情況圖 (use case diagram #) 以視覺化的方式來表達使用者和資訊系統之間的互動。在使用情況圖中，使用者變成一個演員 (actor)以描述他在與系統互動時扮演的特定角色。

23


因為使用情況描繪使用者眼中的系統，在描述交易時則可以使用一般的企業術語。 ( 如圖3-10 圖3-12)

使用情況名稱 : 信用卡核驗流程演員 : 客戶說明 : 描述信用卡核驗流程

正常情況 : 1. 客戶點選輸入選項並輸入信用卡號碼及效期2. 系統核驗該卡3. 系統發出授權訊息

例外情況 : 1. 客戶點選輸入選項並輸入信用卡號碼及效期2. 系統拒絕該卡3. 系統發出拒絕訊息

預設條件 : 客戶已經選購了至少一件貨品並已經到達付款櫃台續後條件 : 信用卡資訊已經通過核驗有效，客戶可以繼續訂購

假設 : 無

24

學籍系統的使用情況圖 P135

學籍系統

填寫註冊選課單指導教授

註冊選課

學生

上課並取得分數

任課老師登錄分數

註冊組職員

<<include>>

25


次序圖 (sequence diagram #)顯示出當物件之間有交易發生時的時序。下圖為一個信用卡核驗成功的次序圖。

信用卡客 : 戶客戶

: 信用卡信用卡

輸入信用卡號碼

確認信用卡號碼

授權

26

系統需求查核清單 P136

在建立需求模型時，系統開發人員必須指出並描述所有的系統需求。所謂系統需求 (system requirement #) 是一些為使資訊系統能夠滿足企業需求，且為使用者所接受而必須具備的特性或特質。因此，系統需求便成為一個系統完成後其整體被接受程度的標竿。系統需求可分為五大類 : 輸出、輸入、處理工作、績效，及控制。各類別的系統需求實例詳述如下︰

• 輸出此網站必須每四小時回報一次線上使用量，在尖峰時段則需每小時回報。

27


此業務聯繫系統必須為每個業務代表產生一份每日的備忘清單。

此進貨系統必須能夠提供最新的規格給供應商。 …

• 輸入部門的主管必須用另一個獨立的螢幕輸入加班鐘點數。每張輸入表單須包含日期、時間、產品編號、客戶代號及數量。

資料輸入螢幕除了背景顏色可以由使用者改變之外，其餘必須標準化。

…

28


• 處理工作 (功能 ) 學生學籍系統必須在每學期末計算 GPA 。薪資系統年終作業的最後一個步驟是更新員工薪資、紅利及福利，並產生國稅局所需的稅務資料。

錄影帶出租系統應該制止有逾期未還影帶的客戶再借影片。

…

• 績效此系統必須同時供 25位使用者上線。反應時間不可超過 4秒。學生學籍系統必須在註冊結束後 5 小時產生班級名單。 …

29


• 控制系統必須在作業系統層次及應用系統層次提供登入安全機制。

員工資料記錄只能由人力資源部門的專人做新增、修改及刪除。

所有的交易必須留下可供稽查的紀錄。 …

30

未來成長、成本，及利益 P138

除了以上所列之系統需求外，系統分析師必須考慮決定系統如何處理未來的成長及需求的規模彈性，以及包括了所有未來的運行及支援的總取得成本。

• 規模彈性所謂規模彈性 (scalability) 是指系統能夠處理未來業務量及交易增加的能力。因為一個有彈性的系統有較長的有效壽命，所以對於先前的投資會有較好的回報。

為了評估規模彈性，你需要有關目前及未來所有輸出、輸入，及處理工作的工作量及成長率的資訊。

31

未來成長、成本，及利益 P138

例如，在建立一個處理客戶訂單的網站時，你必須知道上網客戶的估計數量、上線活動的尖峰時段、每筆交易所需資料項目之數量及型態，以及用來取得及更新客戶檔案的方法。

• 總取得成本除了直接成本之外，系統開發者必須找出並記錄所有構成總取得成本 (TCO, total cost of ownership) 的間接費用，這對於一個正在對數個方案做評選的發展小組而言尤其重要。例如︰使用者的支援及故障期間生產力的損失等皆屬於間接成本。

32

發現事實 P139

到目前，你已經了解了系統需求的種類、規模彈性，以及總取得成本等觀念，下一步就是開始收集資訊。在建立需求模型的期間，你將會使用各種發現事實的技術，其中包括訪談、文件查閱、觀察、調查及問卷、抽樣，以及研究。

• 誰來做、做什麼、在哪裏做、何時做、如何做、為什麼要做 ? 發現事實會牽涉到五個熟悉的問題 : 誰來做、做什麼、在哪裹做、何時做、如何做 (who, what, where, when, and how) 。而針對這些問題你同時必須逐一地再問另一個重要的問題 :為什麼要做 (why) 。

33

發現事實 P142

圖 3-15 在建立需求模型期間，當注意力由目前的系統轉向新提議的系統時，ㄧ些問題的例子。

目前的系統新提議的系統

已做了什麼 ? 為什麼要做 ? 應當做些什麼 ?

在何處做 ? 為什麼在那裏做 ? 應當在哪裏做 ?

那時做 ? 為什麼在那時做 ? 應當何時做 ?

誰做這件事情 ? 為什麼由這個人做 ? 應當由誰去做 ?

如何完成它 ? 為什麼用這種方式完成 ?應當怎樣完成 ?

34

發現事實 P142

• 訪談所謂訪談 (interview #) 是一個有計畫的會談，藉由它，你可以從其他人口中獲得資訊。你必須具有規劃、執行及記錄一個成功訪談的技術。

每個訪談均會包含以下七個步驟 (依照順序 ):1. 決定訪談對象2. 設定訪談目標3. 發展訪談問題4. 準備訪談工作5. 實際從事訪談6. 記錄訪談文件7. 評估訪談結果

35

發現事實 P144

• 第 1步驟 : 決定訪談對象為能準確地了解系統，你必須問對人，而且問對問題。在初步調查期間，你主要是與中階管理層或部門主管交談。現在到了系統分析階段，你或許需要與組織內各個階層的人做訪談。

雖然你可以從先前查看的正式組織圖中選擇訪談的對象，你也應該同時考慮存在於組織中的非正式架構。在非正式的架構中，有些人比實際組織圖中顯示的更具有影響力或知識。

群組訪談可以節省時間並有機會觀察受訪者的互動，當然群組訪談也有一些問題，可能有某個人會主導交談，有高階經理人出現可能會妨礙低階層員工暢所欲言。

36

發現事實 P144

• 第 2步驟 : 設定訪談目標一個訪談的目標依訪談對象所扮演的角色而定。上層的管理人能夠提供你較廣的視野而對系統的整體做了解。而對於業務及程序的細節，則是向每日實際在該系統中工作的人員詢問較好。

在系統分析階段的初期，訪談的內容通常是一般性的問題。然而在發現事實的工作進行之後，訪談就逐漸著重在特定的議題上。訪談的目標也隨著調查工作各階段的轉換而變化。

37

發現事實 P145

• 第 3步驟 : 發展訪談問題建立一個標準的訪談問題清單幫助你不偏離主題，並避免不必要的一些漫談。

訪談應該由不同型態的問題組成 : 開放式、封閉式，或是區間回應式。當你對問題作陳述時，應該避免會誘致特定回應的誘導式問題。開放式問題鼓勵自發的且非結構性的反應。這種問題適用在當你要去了解一個較大的程序，或想獲得受訪者的觀點、態度或建議時 (就像考試的申論題 ) ，例如 : 這項工作是如何被執行的 ? 你為什麼用這種方式執行 ? 。

38

發現事實 P146

封閉式問題限制了回應的內容。要更特定的資訊或是需要查驗事實的時候，你可以用封閉式的問題(就像考試的簡答題或填充題 ) ，例如 : 在此部門中共有幾部個人電腦 ? 在他們送出報表前你是否做核閱 ?

區間回應問題是封閉式問題的一種，它要求受訪者由對特定問題做限定的回應或以數值量表的方式來評估某些事物，例如 : 你認為此問題的嚴重性如何 :低、中或高 ? 系統當機發生的頻率對你而言是 : 從不、偶爾、經常、總是 ?

• 第 4步驟 : 準備訪談工作在訪談前一天發一封 e-mail 或打電話提醒。對受訪者而言，訪談會打斷其例行工作，因此你應該將訪談限制在一個小時以內。

39

發現事實 P146

向部門主管打聲招呼當你要訪談他手下的員工時。

你應該在會談前幾天就把基本問題的清單送一份給受訪者，尤其是當你需要一些細節的資訊時，如此他可以充分的準備並減少做說明的時間。

如果你有一些問題牽涉到文件或表單，可要求受訪者在開會時準備一些樣本。

對於訪談的最佳地點有兩派說法。有些分析師認為訪談應該在受訪者的辦公室進行，而有些人則認為一個中立地點，如 : 會議室較佳。

40

發現事實 P147

支持在受訪者辦公室進行訪談的人相信︰受訪者在會談中會感到比較舒服，另外一個支持的理由是︰辦公室是受訪者最容易取得會談中可能需要的各種文件的地方。

支持中立地帶的人強調儘量降低干擾，所以對方才能完全地集中精神，此外，不受中斷的面談比較節省時間。

• 第 5步驟 : 實際從事訪談當實際訪談時，首先你應該介紹自己，描述一下本專案，並解說此次訪談的目標。

與受訪者建立一個和善的關係非常重要，尤其在第一次會談時更是如此。

在訪談中的主要任務就是傾聽回答。

41

發現事實 P149

有研究指出，在會談中最長的間斷時間一般是 3~5秒。在這個時間之後，其中一人就會開始發言。

在訪談之後，你應該彙整訪談的會議記錄並取得參與者的確認。

• 第 6步驟 : 記錄訪談文件雖然在訪談中做筆記有優點，但是應該儘可能的減少。雖然你應該寫下一些，以便會後做提醒之用，但是你應該避免抄下所有的對話。花太多的時間抄寫會使別人分心而且使得和善的關係難以建立。

42

發現事實 P149

你必須預留緊隨著訪談之後的時間，來記錄所發現的事實並評估所得到的資訊。因此，儘量不要安排連續的訪談。

有研究指出有 50% 的會談，在 30 分鐘之後被完全遺忘。因此，你應該用筆記來立即記錄所得到的事實，而不至於忘了它們。

雖然有許多人在錄音機出現時感到不自在，但是錄音機仍是有用的訪談工具。在使用錄音機之前，你應該告知受訪者，並且告訴他們你在做完筆錄之後會將錄音帶消磁。

縱使有錄音機協助，你仍應仔細傾聽受訪者的回應，如此你才能問出好的接續問題。

在訪談之後，記得送一份備忘錄給受訪者，對他的時間及合作表示感謝。

43

發現事實 P150

• 第 7步驟 : 評估訪談結果除了記錄下訪談中所發現的事實之外，也要試著找出其中可能的偏頗之處。例如，一個受訪者試圖保護其領域或功能時，可能會提供不完整的答案或是持保留態度。

• 不成功的訪談無論你為訪談做的準備多麼好，有些訪談還是不成功。主要理由之一可能是，你與受訪者未能好好地相處。這種情況可能由幾種因素造成。例如，一個誤會或個性上的衝突，可能對訪談有不利的影響，或受訪者可能害怕新系統將取消或改變他的職務。

受訪者可能對你的開放式問題僅僅給予簡短或不完全的答覆，如果是這樣，你應當嘗試使用封閉式問題或區間式回應的問題。

44

其他發現事實的技術 P152

• 文件查閱文件查閱 (document review) 可幫助你了解目前的系統是如何運作的。要記住，系統文件有時是過時的，一些表格可能改變或停止使用。

你應當取得幾份實際表格和目前還在使用的操作文件。

• 觀察觀看運行中的系統可以給你另一種見解及對系統程序更佳的體認。

親自觀察還使你得以驗證訪談中的說法並判斷程序是否真的如其所述的方式運作。

45


親自觀察還能提供一些益處，例如︰基於對實際操作、親自觀察的建議，往往較能夠被接受。

觀察還能夠提供檢驗或引進未來變更所需的知識，並能幫助與將使用新系統的操作人員建立關係。

在預先規劃你的觀察工作時，可預先備妥一份含有你想觀察的具體任務和想問的問題的核對清單。在你準備這個清單時要考慮下列問題 : 充分提問問題以保證你對現有系統的運作有完整的了解。其中一個主要目標是指認出標準操作程序中沒有列出的情況之處理方法，例如，如果員工遺失了工時卡，薪資處理系統將發生什麼情況 ? 如果一名員工開始工作的時間遲了 10分鐘，但是隨後又加班工作 20分鐘，處理的程序如何 ?

46


觀察一個交易的所有步驟，並且注意到所有相關的文件、輸入、輸出，以及處理工作。

審查每一個有關的表格、紀錄，和報表。確認每一個資訊服務項目的目的。

考量與使用該系統的每一個人和下列問題 : 那個人從其他人員取得什麼資訊 ? 這個人的工作產生什麼資訊 ? 這些資訊如何傳遞 ? ....

與收到現有報表的人員交談，查明這些報告是否完整、及時、準確，並以有用的形式提出。詢問該資訊是否可以取消或改進，以及人們是否想要獲得其他額外的資訊。

所謂霍桑效應，這項研究的目的是決定工作環境中的不同變化如何影響員工的生產力。結論是︰無論何時，只要工作人員知道他們受到觀察，生產率就會提高。

47


要記住，正常的運作並不總是像你的觀察所顯示的那麼平順。運作也有可能因為工作人員在觀察期間神經緊張而比較不順利。如有可能，訪談工作人員及其主管，討論你的規劃和目的，以幫助建立良好的工作關係。

• 問卷及調查在那些希望能從大量人員獲得意見投入的系統開發專案中，問卷調查可能是一個有價值的工具。問卷 (questionnaire) ，有時也稱為調查 (survey) ，是能夠發給許多個人的一份包含有許多標準問題的文件。圖3-21表示含有幾種不同問答格式的問卷樣本。

48


你在設計問卷時，還要記住下面一些觀念︰保持問卷的簡潔，且便於回答者使用。以合邏輯的順序安排問題，題目由簡易到複雜排列。

少使用不容易製表的開放型問題。少使用能夠引起關於職務安全的憂慮或其他負面因素的問題。

… 儘可能在最後定稿並發給大群組之前，在一個小型測試群組中檢驗問卷。

• 抽樣抽樣技術包括︰系統抽樣、分層抽樣和隨機抽樣。

49


假設你有一個 200 個客戶的名單，他們抱怨報表中有錯誤，而你要檢驗一下其中 20 個代表性的客戶樣本。

系統抽樣 (systematic sample)就每十個客戶選擇一個以供考察。

如果你想要確保樣本在地理位置上的平均分佈，你可以採用分層抽樣 (stratified sample) ，從四個郵遞區號中的每一個各選五個客戶。

隨機抽樣 (random sample)就是任意選擇 20 個客戶。

當使用訪談或問卷調查時，你也應該考量抽樣。

50


• 研究研究可能包括網際網路、 IT雜誌，和書籍來取得一些背景資訊、技術材料，和關於產業趨勢消息。此外，你還可以參加專業會議、研討會，以及與其他 IT 專業人士討論。

研究方式也可以包括現場參訪 (site visits) ，其目的是觀察在某個地點使用中的系統。對單獨一個現場的參訪很少能給予你真實的情況。所以，你應當儘量要求參訪多個安裝地點。

在參訪現場之前，正像你為訪談做準備那樣，也要為它做好準備工作。

51


• 訪談與問卷調查的比較當你必須向許多人員提出一系列相同的問題時，問卷調查就很有用。

如果僅從少數人取得資訊，那麼你可能就應當個別訪談每一個人。

是訪談還是使用問卷比較好呢 ? 每個情況都不同，而你必須考量資訊的型態、時間限制，及費用因素。

訪談比問卷較為親切且個人化。而且，在面對面的訪談中，你還能夠對受訪者所說的任何事情立即做出反應。訪談中的參與感也能夠協助改善人際關係。

52


然而，訪談是一個昂貴而又耗費時間的過程，個人訪談通常是發現事實技術中最昂貴的。

相較之下，問卷調查給許多人提供意見投入和建議的機會。收到問卷的人能夠在他們方便的時候才回答問題，不必刻意抽出時間接受訪談。如果問卷允許匿名答覆，人們還可能比他們在訪談中更加坦率。問卷調查的優點

問卷調查的缺點︰ (1) 如果一個問題被誤解，你不能像在面對面的訪談中那樣澄清其意義﹔ (2) 除非問卷設計得很好，收到的人可能把它們看做一種打攪、浪費時間，或缺乏人情味。

53


另外一個常用來獲得意見投入的方法稱為腦力激盪 (brainstorming #) ，這是指針對特定問題、機會、或議題所作的小組討論。

腦力激盪可以是結構化的或非結構化的。在結構化的腦力激盪 (structured brainstorming) 中每個參與者輪流發言。在非結構化的腦力激盪 (unstructured brainstorming) 中任何人均可隨意發言。

54

文件製作 P161

保有對各次訪談、事實、想法，和觀察的準確紀錄，是成功的系統開發工作不可或缺的事情。

• 記錄事實的必要性你應當按照下列原則記錄你的工作 :

得到資訊立即記錄儘可能採用最簡單的記錄方法以別人能夠了解方式記錄你的發現把你的文件好好整理，使相關的資料文件等可以容易的被找到。

• 軟體工具 CASE 工具 --- 在系統開發的每個階段你都可以使用 CASE 工具。

55

文件製作 P162

生產力軟體 --- 生產力軟體 ( productivity software ) 包括文字處理、試算表、資料庫管理、及簡報製圖程式。

建模繪圖軟體 --- Microsoft Visio 是能產生各種圖表及圖形的知名建模繪圖軟體。

56

資料與處理工作模型建立的預習 P166

在需求模型建立完成時，系統開發人員應該清楚地了解企業流程及系統需求，下一步是要建立系統的邏輯模型 ( 即建立資料與處理工作模型或建立企業模型 ) 。建立資料與處理工作模型會使用結構化分析方法。結構化分析法是一種廣受採用的傳統技術，其中以資料及對資料作用的處理工作來描述系統。結構化分析的替代方法是物件模型的建立。物件模型建立是一種方法論，其中將資料及處理工作結合在所謂的物件中。IT 專案人士對於系統開發方法論有各種不同的看法，因此並不存在全面被接受的方法。 ---END---

第 3 章 建立需求模型

Documents

第 3 章建立需求模型