Transcript 第三章 需求擷取與分析

第三章 需求擷取與分析
Requirements Elicitation & Analysis
1
內容大網







學習目標
3.1 導論
3.2 需求擷取方法
3.3 需求表達工具
3.4 需求分析個案
3.5 需求分析之重要工作與文件樣板
3.6 結論
2
學習目標





詳讀本章，你至少能瞭解：
常見的六種需求擷取方式及其執行要點。
以流程圖為主之需求表達工具。
需求分析之步驟及應注意之事項。
需求分析之重要工作與文件樣板。
3
3.1導論 -使用者需求定義


使用者需求定義(User Requirements)：係指使用
者期待系統解決的問題與希望從系統獲得之資
訊。
使用者需求是資訊系統開發最關鍵、最重要且
最容易發生錯誤的部份，亦是資訊系統失敗的
主因之一。
4
3.1導論 -RA主要工作


需求分析(Requirements Analysis)階段之主要工作是
應用已通過驗證之原理(Principles)、技術
(Techniques)、語言(Languages)與工具(Tools)，以
幫助分析師SA瞭解問題或描述新系統之外部行為。
從使用者角度，去了解其問題、目標、限制與實際需
求，讓結果具體表達出來給使用者確認，並進一步作
為系統分析重要來源文件。
5
3.1導論 -RA階段主要三個活動

Hooper 與 Hsia (1982)認為需求分析階段主要
包括三個活動：



1.需求判斷：強調如何判斷真正的需求及需求的正
確性。
2.需求分析：則重視在分析已有的需求下所產生的
不一致、不完整、矛盾等問題。
3.需求溝通：重視以最佳的方式組織及描述需求，
以促使需求容易令人瞭解並經由相互溝通，達到需
求確認的目的。
6
3.1 導論 -RA兩大步驟

需求分析階段可分為兩大步驟：需求擷取與需
求轉換(如圖 3-1，下頁)。


需求擷取：主要是對系統範圍內之各種事物及相關
現象加以瞭解、判斷和選擇，並設計成描述性綱目。
(找出需求項目、結構、彼此關聯)
需求轉換：主要將描述性綱目以系統模式語法轉換
成概念性綱目。(再結構化表達→MIS)
7
圖3-1 RA兩大步驟圖解
擷取
各種事物現象
轉換
描述性綱目
找出需求項目、
結構、彼此關聯
概念性綱目
再結構化表達
→MIS
8
3.1 導論 -巨觀需求VS.微觀需求

使用者需求可分為巨觀需求與微觀需求。


巨觀需求包括欲電腦化之環境、作業程序與範圍、
輸出與輸入所需之資訊或表單及系統目標、限制、
主要功能等，這些需求應盡可能的在需求分析階段
中釐清與確定。
微觀需求指的是電腦化之微觀範圍，可包括使用者
介面之要求、例外狀況之處理與錯誤及輔助訊息之
顯示等要求，這些需求通常需到設計階段才較容易
處理，在此之前這些細部需求不易被掌握。
9
3.1 導論 - RA之4個主要工作

RA階段之重要工作(4個)包括：




瞭解現有問題
瞭解新系統目標
瞭解新系統之限制
瞭解使用者巨觀之需求等
★ 好的RA是什麼？
10
3.2 需求擷取方式(6種)


在擷取使用者需求之前，必須瞭解系統之潛在
使用者及可能之人機互動。
常用的需求擷取方式：查閱文件、觀察、問卷、
訪談、開會討論與聯合開發等六種，這些方式
可單獨應用亦可混合使用。
11
3.2.1 查閱文件


研究企業的內部工作說明書、企業表單
(Business Forms)與手冊是瞭解企業運作邏輯
之初步工作。
一般來說，組織中很少有完整的文件詳細地描
述出系統之全貌，加上系統可能已經過多次的
修改，文件往往未能配合更新，因此以該方式
收集之資訊常有過時之慮。
12
3.2.2 觀察



一般來說，實地觀察所獲得的資料正確性會比
查閱文件為高，亦能驗證所收集資料之正確性
及補充不完整的資料，透過觀察可以獲得第一
手的資料。
僅用觀察仍無法完整的反映出組織的真實情況
與需求，例如被觀察者行為可能改變。
選擇正常與例外情況之時機或對象來做觀察，
可獲得更多的資料。
13
3.2.3 訪談


訪談是系統分析最有效且最普遍的資料收集方
法，訪談時分析師親自與使用部門的主管或相
關作業人員面對面討論實際作業的情況、報表
和資訊需求等。
在訪談期間，系統分析師蒐集到的可能是事實、
選擇或推測，並且可觀察到人們的肢體語言、
情緒和他們對於現行系統之觀感等。
14
3.2.3 訪談 -開放式訪談

訪談可分成兩種方式：



開放式訪談(Open Interview)
結構化訪談(Structured Interview)。
開放式訪談


分析師事先不預定表格、問卷或固定的標準程序，
訪談過程全由使用者自由談論其工作。
適用於分析師對問題領域不熟悉或無法預期之情況。
15
3.2.3 訪談 -結構化訪談

結構化訪談

結構化訪談又稱為標準化訪談或導向式訪談，其訪
談過程近似於詢問(Interrogation)而非交談
(Conversation)，所要求資訊的深度、專門程度亦
較深。
16
3.2.3 訪談 -結構化訪談(略)


這種方式的特點是把問題標準化，然後由受訪者回
答或選擇。
所有的受訪者都回答同一形式的問題，其作法如下：



(1) 每討論一個主題時，先由分析師依其現有瞭解的知
識，提出簡短敘述。
(2) 使用者針對主題作深度分析，但分析師應在適當知
識深度時加以中止。
(3) 對某個主題有初步瞭解，就可以進行另一主題的訪
談。
17
3.2.3 訪談 -開放性問題


訪談之問題依其性質可分成開放性與封閉性問
題兩種：
開放性問題



用來探索分析師無法預期的回答或明確詢問之問題。
優點是能讓先前不知道的資訊浮現出來，分析師可
以用一些非預期中的問題，不斷的來探究新的資訊。
缺點是回答問題所花的時間較長，也較難作結論。
18
3.2.3 訪談 -封閉性問題

封閉性問題



適用於問題可預期且回答可明確描述之情況。
優點：訪談的時間較短，問題可較廣泛。
缺點：所列回答之選項未必包含受訪者所要回答之
答案。
19
3.2.3 訪談 -封閉性問題設計(3種)

封閉性問題可以有下列幾種設計形式：



(1)對與錯的選擇方式。(是非)
(2)多重選擇的方式。(選擇)
(3) Likert尺度的衡量方式。用一些級距來衡量受訪
者意見的強弱程度，例如用很好、好、普通、差與
很差5個(單數)等級。
20
3.2.3 訪談 -規劃與準備


訪談前需有周詳的規劃。
一些有助於訪談進行之準則包括：


(1)進行時：要仔細的聆聽受訪者的回答，同時將重
點記下來，在得到允諾的情況下，還可以將訪問的
內容用錄音機或錄影機錄下來，以有效的掌握訪談
內容。
(2)結束後：需在48小時之內將訪談內容整理出來，
因為經過48小時之後，訪談的內容會慢慢的從記憶
中消失。
21
3.2.3 訪談 (c.9)



(3)進行時：不管是面對開放性或是封閉性的問題，
分析師不要強調問題答案的對或錯。
(4)進行時：不要對新的系統做任何預期的想法。需
讓受訪者知道他們的意見會被仔細的考慮，並讓受
訪者知道專案的完成需要很多的步驟，同時還有很
多人的觀點都需要一起考慮。
(5)整體：從系統潛在的使用者、管理者與對現行系
統有經驗的專業人員等尋找各式各樣的觀點，以對
新系統做全盤性的瞭解，如此才能設計出大多數使
用者都可接受的系統。
22
3.2.4 問卷


當潛在使用者太多或分布太廣時，可考慮以問
卷之方式擷取需求。
一般來說，問卷調查適合於大型企業或公眾資
訊系統的設計，因為它所涉及的作業範圍或對
象太廣，系統分析師無法逐一親自調查，故利
用問卷方式來收集使用者需求較為可行。
23
3.2.4 問卷 (c.2)


設計一份好的問卷需有相當的練習與經驗，因
為問卷上的問題是以文字靜態的表達，故問題
之語意與邏輯必須很清楚且有條理。
問卷設計時也可以用各種不同的方法來問同一
個問題，以觀察各種可能的答案。
24
3.2.4 問卷 -先導測試


正式問卷調查前需有先導測試(Pretest)。
經由先導測試之檢討與回饋可進一步修飾問卷，
及早發現問卷可能之問題，對提升問卷之效能
有很大之幫助。
25
3.2.4 問卷 -抽樣方法

正式問卷調查時必須決定那些族群是調查的對
象。對象選取之抽樣方法主要分成：


機率抽樣(Probability Sampling)
非機率抽樣(Nonprobability Sampling)
26
3.2.4 問卷 -機率抽樣

機率抽樣方法：


簡單隨機抽樣：將使用者的名單逐一給予編號，再
以摸彩法或亂數表來抽樣，以決定那些人將成為受
測的對象。
分層抽樣：先將所有可能之使用者分成若干互斥的
組或層，然後再從各組或各層中隨機抽選預定數目
之使用者為受測對象。
27
3.2.4 問卷 -非機率抽樣

非機率抽樣方法：


便利抽樣：以方便性為抽樣之主要考量，這些抽樣
之對象可能是最容易找到的使用者、願意接受調查
的人或是動機高的使用者。
判斷抽樣：又稱立意抽樣(Purposive Sampling)，
係根據抽樣設計者的判斷來選擇受測之使用者。設
計者必須對使用者之特徵有相當的瞭解，然後針對
符合某些特徵的名單抽樣，例如針對使用系統已經
兩年以上的使用者或者是經常使用的人。
28
3.2.4 問卷 -去除異常之問卷

上述抽樣策略可單獨使用，亦可混合使用。當
問卷回收後，應該逐一檢查回收問卷之回答是
否完整，並去除異常之問卷，以便進行資料分
析。
29
3.2.5 開會討論



開會討論是一種很有效率的資料收集方式。使
用者代表與系統開發人員聚集一堂，將所知道
的事實、觀念說出，讓所有與會人員一起相互
溝通意見。
此方法的優點是較易獲得正確的資料，即使有
不同的意見與觀念，經由眾人研究亦能加以修
正。此外，亦可發揮腦力的效果。
缺點是安排溝通與協調較費時。
30
3.2.6 聯合開發 -快速取得共識


聯合開發（Joint Application Development,
JAD）主要之精神是透過一個二至五天的集會，
讓開發者與顧客能夠快速有效，而且深入的檢
討需求並取得共識。
聯合開發的具體結果是產生完整的需求文件。
31
3.2.6 聯合開發 -五個步驟

JAD依下列五個步驟來進行：

(1) 範圍界定。
(2) 關鍵人員的熟悉。
(3) 會議(事前)準備。
(4) 會議進行。
(5) 文件產生。

與一般會議方式大致相同(參考即可)




32
3.2.6 聯合開發 -最後確認需求文件

最後階段：文件產生

最後階段將JAD會議所收集的需求整理成需求文件，
為達到會議的效果，需求文件的準備要非常快速，
例如二、三天。最後再召開一次審查會議，以確認
需求文件的內容。
33
3.3 需求表達工具(本章重點)



作業程序(流程)是指作業處理有組織的結合，其結果
需能完成某作業功能，例如行銷或生產管理等。
結構化系統分析與設計主要是考量「流程塑模」與
「資料塑模」(詳如Page.99)。
需求塑模簡要流程：
* Collections of All Requirement Documents
* For Users Documents
* For MIS Documents
34
3.3 需求表達工具 -塑模工具

流程塑模與資料塑模的工具包括：




流程圖(Flow Chart)
 流程圖主要表達實體(Entity)與作業程序及所需資訊間之關係。
處理描述(Operation Description)
 處理描述則表示流程圖中之作業處理、程序與規則及其相關
之資訊輸入與輸出等。
藍圖(Drawing)
 藍圖主要表示資訊之展示格式與內容等，例如表單之格線與
縱橫項目。
資料詞彙(Data Glossary)
 資料詞彙主要描述藍圖內資訊之詳細內容與規則等。
35
圖3-2 流程圖 -主要符號
外部實體(加底線，最上方)：人、組織/單位、系統
Process
If Else (Judge)
Doc/ File
Flow
36
3.3.1 流程圖 -繪製4步驟

流程圖可經下列步驟來建立：


1.找出物件、2.分解、3.命名、4.方向、5.排版、6.完整性
(1)先整理出系統範圍內所有涉及之實體、資訊、
企業功能(處理)、企業程序等。
 實體(名詞)：人、單位、組織、系統
 處理(動詞)：活動、功能、作業名稱
 表單(名詞)：表單、文件、檔案
 方向：資訊流向、事物流向
37
3.3.1 流程圖 -繪製4步驟



(2)逐一檢視每一實體，找出會主動引發刺激之主要實體(一
個主要實體至少會有一個主動刺激，也可能會有多個)，並
由每一刺激開始找出其所引發之一系列高度相關之處理步驟
(這些處理之集合可完成某一功能)，以形成一個流程圖。
 例如訂單處理後會緊接著送貨處理，因此兩者應在同一
流程圖中。
(3) 劃流程圖時，原則上實體應在上方，而其相關之作業處
理及資訊分別表示在其下方，並以文字描述其未盡之情節。
(4) 檢查所有流程圖之完整性，也就是所有流程圖是否涵蓋
整個系統範圍。
38
3.3.2 處理描述


處理描述(Operation Description)進一步的表
達每個處理之執行步驟、法則、控制等，並說
明其資料之輸入與輸出內容與所涉及之實體等。
每個處理描述之名稱應與流程圖中之處理同名，
處理描述之表達形式可如表 3-2。
39
表3-2 處理描述樣板
40
3.3.3 藍圖

藍圖(Drawing)主要用予表達流程圖中有關之
表單、介面等各項資訊需求之名稱、展示位置、
格線、圖表與說明等，這些資訊常無法在流程
圖上具體的表達，因此須另以藍圖進一步的表
示。
41
3.3.4 資料詞彙

資料詞彙(Data Glossary)進一步說明藍圖所無
法表達之內容如資訊之長度、型態、格式、公
式、規則、範圍與限制等 ，並分別舉例說明
之。
42
3.3.4 資料詞彙 -範例

資料詞彙之內容項目除了藍圖中之欄位編號與
名稱外，欄位資料之長度與形態，資料是否唯
一，資料產生之規則/格式/範圍/公式等資訊均
有助於系統分析與設計，因此均可列入資料詞
彙中，其形式可表達如下表 3-3：
43
3.4 需求分析範例 -流程圖

流程圖（圖3-3 銷售流程圖範例）
客 戶
業務部
訂 單
訂單處理
成品庫存
足夠？
生產部
N
生產需求
Y
送貨單
送貨處理
44
3.4 需求分析範例 -處理描述

處理描述（表3-4 「訂單處理」描述範例）
處理名稱
執行程序與規則
資料輸入／來源
資料輸出／目的地
限制與備註
訂單處理
1. 業務部收到客戶訂單之後，需作客戶資料登錄
與檢核。
2. 業務部檢查訂貨之成品庫存，若成品庫存充
足，則進行送貨處理；若成品庫存不足，則通
知生產部進行生產計畫之規劃。
訂單／客戶
送貨訊息／業務部或生產需求／生產部
45
3.4 需求分析範例 -藍圖

藍圖（表3-5 訂單藍圖範例）
夢幻企業股份有限公司
訂
單
客戶：
地址：
A
B
編號：
D
電話：
C
日期：
E
顏
規格
色
F
G
H
I
10000006 太空梭模型 綠
25kg
10000005 鐵釘
25kg
紅
10000006 太空梭模型 綠
25kg
10000002 坐墊
50kg
綠
10000003 方向盤
50kg
黑
10000004 鐵蛋
紅 100kg
貨品編號
客戶簽章：
品名
尺
寸
J
S
L
S
S
M
M
總金額： 9,052
數
量
K
3
1
1
1
2
1
單
單價
金額
位
L
M
N
417.60 1,252.80
個
200.00
200.00
支
200.00
200.00
個
粒 6,000.00 6,000.00
600.00 1,200.00
個
200.00
200.00
粒
O
46
註：套色區域表示須套印表單之部分。
3.4 需求分析範例 -資料詞彙

資料詞彙（表3-6 訂單資料詞彙範例）
編
號
A
B
C
欄位名稱
客戶名稱
地址
電話
D 編號
E
F
G
H
I
J
K
L
M
送貨日期
貨品編號
品名
顏色
規格
尺寸
數量
單位
單價
長度／
鍵
形態
20C
40C
10C
8N
6D
8C
10C
5C
14C
4C
10N
4C
10N
N 金額
10N
O 總計
10N
V
規則／格式／
範圍／公式
範 例
王大明
高雄市鼓山區蓮海路70號
07-5252000
年+月+日+流水號
YYMMDD99
日期
99999999
99,999,999.99
數量 × 單價；
9,999,999,999
999,999,999
註：C表字串；N表數字；D表日期。
98090101
87年9月1日
10000003
方向盤
黑
50Kg
M
2
個
600.00
1,200
9,052
47
3.5 RA重要工作與文件樣板
需求分析文件樣板
一、問題描述
二、新系統目標
三、新系統限制
四、使用者需求
（一） 流程圖1
處理描述1-1
…………..
處理描述1-n
藍圖1-1
資料詞彙1-1
…………..
藍圖1-m
資料詞彙1-m
（二） 流程圖2
…………..
…………..
48
3.6 結論


需求分析主要是擷取與表達使用者之巨觀需求，
這包括欲電腦化之環境、作業處理、輸出與輸
入所需之資訊或表單與系統主要功能等。
需求分析階段對問題領域之瞭解範圍應盡可能
的廣，而到分析與設計階段再縮小到專案範圍，
如此有助於對新系統之瞭解與規劃。
49
3.6 結論 (c.2)

以目前之開發工具來說，需求分析工作約佔整
個專案時間的10％左右，且需求分析往往無法
在一個階段完全做完，常在分析與設計階段仍
有需求分析工作之進行。當然，分析師之專業
知識與經驗，對需求分析之成效有關鍵性之影
響。
50