Unit4
需求調查
一、目標進度→
二、觀念介紹→
三、範例研討→
四、單元討論→
G
oG
oG
oG
o
一、目標進度
本單元目標達成進度
(1)、定義系統需求，並區別功能性和非功能性需求間的差異。
(2)、了解問題分析的活動並能夠建立魚骨圖 (Ishikawa
diagram)
來幫助解決問題
(3)、了解需求管理的概念。
(4)、確認七種事實調查技術，並描述各個技術的優缺點。
(5)、了解用於有效聆聽的六種原則。
(6)、了解什麼是肢體語言和人際距離學 (proxemics)，以及系
統分
析師為何要重視它們。
(7)、描述 JPR 會議典型的參與者之特徵，並說明他們的角色。
(8)、完成 JRP 會議的規劃流程，包括選擇和佈置地點、選擇參
與
者，以及準備議程。
(9)、描述使用 JRP 作為事實調查技術的數種利益。
(10)、說明將使得你大部分的時間都和最終使用者在一起的事實調
查策略
(11)、描述多種以文件來說明和分析需求的技術。
(12)、了解使用案例並且可以用文件來說明它。
Men
u
二、觀念介紹
需求調查概述
需求調查 (requirements discovery) 包括系統分析師所用的技術，
運用它們從使用者社群來確認或是引出系統的問題和解決方案的需求。
問題分析 (problem analysis) 是一種活動，它確定問題，了解問題
(
包括成因和影響），與了解任何可能限制解決方法的限制。
系統需求（system requirement；也稱為企業需求）是對於一個資訊
系統的需要和期望的描述。需求可以描述功能、特色（屬性）和限制。
需求的種類
功能性需求 (functional requirement) 是為了符合企業需要並可
被使用者接受，而必須包含在一個資訊系統中的功能或特色
(feature)。
非功能性需求 (nonfunctional requirement)是系統的功能、特色、
屬性，以及任何會侷限所提出的解決方案界線的限制之描述。
Men
u
觀
念
介
紹
Men
u
Requirement:
Create a means to transport a single
individual from home to place of work.
Management
Interpretation
I T
Interpretation
User
Interpretation
圖 一個模擬兩可的需求敘述之例子圖 一個模擬兩可的需求敘述之例子圖 一個模擬兩可的需求敘述之例子
錯誤的需求所導致的情況
系統的成本也許會比計畫中的高。
系統的發布或許會比承諾的慢。
系統也許不能符合使用者的期望，而且這樣的不滿意也許會導致他們不使用它
一旦完成，維護並加強系統的成本將非常的高。
系統也許不可靠，並且導致錯誤或是停止運轉。
團隊中 IT 成員的評價將因為任何的錯誤而沾污，不管是誰的錯，都將被視為
整個團隊的錯誤。
觀
念
介
紹
Men
u
在哪個階段發現 成本率
需求 1
設計 3-6
編碼 10
發展測試 15-40
接受度測試 30-70
運轉 40-1000
修
正
一
個
錯
誤
的
相
關
成
本
界定符合系統需求的準則
一致的
完整的
可行的
必要的
正確的
可回溯的
可實證的
觀
念
介
紹
Men
u
需求調查的流程
問題的發現和分析。
需求調查。
用說明書並分析需求。
需求管理。
Ishikawa 圖是一個圖形式工具，用來確認、發現並描述問
題，以及這些問題的成因和影響。它常被稱做因果圖
(cause-and-effect diagram) 或是魚骨圖（因為它類
似一隻
魚的骨架）
觀
念
介
紹
Men
u
圖
SoundStag
e 的
魚
骨
圖
需求調查
事實調查是一種正規的程序，透過研究、訪談、問卷、抽樣，
以及其他的技術，來收集關於問題、需求和喜好的資訊。又
稱為資訊蒐集。
七種可用的事實調查方法
現存的文件、表單和資料庫抽樣
調查和實地訪談
工作環境的觀察
問卷
訪談
建立雛型
合作需求規劃(JRP)
觀
念
介
紹
Men
u
以文件說明和分析需求
一份需求定義文件應包含以下幾點：
• 系統應該提供的功能和服務。
• 非功能性需求，包含系統的功能、特色和屬性。
• 侷限系統發展的或系統必須在其下運轉的限制。
• 系統必須與它接合的其他系統的相關資訊。
需求驗證 (requirements validation)檢查需求定義
文件的正確性、完整性、一致性，並符合標準。
抽樣 (sampling)是收集具有代表性的文件、表單、和記
錄的樣本之過程。
– 決定樣本大小：
• 樣本大小 = x (確定因子／可接受的誤差)2
– 對於 90%的確定度 ：
• 樣本大小 = ( = 68
觀
念
介
紹
Men
u
觀
念
介
紹
Men
u
抽樣技術
隨機抽樣 (randomization) 是一種抽樣技術，它的特色
是在選擇樣本資料時沒有預定的樣式 (pattern) 或計畫。
分層化抽樣 (stratification)是一個系統化的抽樣技術，
它藉由展開樣本—例如，藉公式來選擇文件或記錄—和避免太
高或太低的估計來試圖降低估計的變異。
觀察是一種事實調查的技術，在那裡分析師在或加入其中，
或觀看一個人進行活動來瞭解一個系統。
工作抽樣 (work sampling) 是一種事實調查技術，它包
含了大量被隨機的間距所選出的觀察對象。
觀
念
介
紹
Men
u
觀察的指導方針
確認觀察的何人 (who)、何事 (what)、何地 (where)、何
時(when)、何故 (why) 和如何 (how)。
獲得適當的管理人或經理的核准。
告知將被觀察的人員觀察的目的。
保持低姿態。
在觀察期間內作筆記或觀察之後立即做筆記。
和適當的人一起檢視觀察筆記。
不要打擾工作中的個人。
不要大量地將焦點放在不重要的活動上。
不要做假設。
問卷 (questionnaires)是一個有特殊用圖的文件，它可
讓分析師從答題者身上收集資訊和意見。
問卷的種類
自由格式問卷 (free-format questionnaires)提供答題者在回答上
很大的自由。一個問題被詢問，答題者就將答案寫在問題之後空白的地方。
固定格式問卷 (Fixed-format questionnaires) 包含了要求選擇
預定的答案之問題。
固定格式問卷的種類
選擇題 (Multiple-choice questions )
評估問題 (Rating questions)
順序問題 (Ranking questions )
觀
念
介
紹
Men
u
訪談 (interviews) 是一種事實調查技術，系統分析師
透過面對面的互動來收集資訊。
訪談的種類
非結構性的訪談(Unstructured interviews) 是只用在心中一個
一般性的目標或是主題，以及如果有的話，少數的特定問題來進行。施
訪者指望受訪者提供一個架構並且引導這個對話。
在結構性的訪談方面，施訪者有明確的一組問題用來訪談受訪者。
進行訪談的程序
1.選擇受訪者
2.為訪談做準備
• 訪談指南(interview guide) 是施訪者要詢問受訪者的明確
的問題清單。
3.進行訪談
4.訪談之後的活動
觀
念
介
紹
Men
u
在訪談期間應該遵守的規則觀
念
介
紹
Men
u
應遵守的
• 有禮貌的。
• 仔細地聆聽。
• 保持控制。
• 探究。
• 觀察習慣和非口頭的溝
通。
• 有耐心的。
• 保持受訪者的輕鬆。
• 保持自我控制。
應避免的
•不必要地持續一個訪問。
•假設一個回答已完成或不
會引出更多意見。
•透露口頭的和非口頭的線
索。
•使用術語。
•透露你個人的偏見。
•只說話而不聆聽。
•假設和主題與受訪者有關
的任何事。
•以錄音機錄音－象徵不好
的聆聽技巧。
聆聽－「聽到是意識到有人正在說話，聆聽是去了解說話的
人想要溝通的是什麼。」 (Gildersleeve – 1978)
溝通的指導方針
• 用正面的態度舉行會議。
• 讓其他人放鬆。
• 讓他們知道你正在聆聽。
• 提出問題。
• 不要臆測任何事情。
肢體語言(Body language) 是我們所有人用來溝通而且通
常沒有覺察到的非口頭上的資訊。
人際距離學(Proxemics) 是人們與其環繞空間上的關係。
對博學的分析師而言，人際距離學是可被控制的一種溝通因
素
。
觀
念
介
紹
Men
u
觀
念
介
紹
Men
u
發現式雛型法(Discovery prototyping) 是以建立一個
使用者需求的小規模、有代表性或可工作的模型之活動，以
便發現或驗證這些需求。
合作需求規劃(JRP) 是一種流程，在其中舉行高度結構性
的群組會議以分析問題和定義需求。 JRP 是更全面性的合
作應用系統發展或 JAD 技術的一部分，後者包含整個系統
發展的流程。
進行JRP 會議的指導方針
– 不要沒有理由地從議程中離開。
– 依照時程表運作。
– 確認書記可以做筆記。
– 避免使用技術性的用語。
– 運用衝突解決技巧。
– 容許充足的小憩。
– 激勵團體共識。
– 鼓勵使用者和管理者參與而不要讓某些個人支配會議。
– 確認出席者遵守對此會議所建立的基本規則。
腦力激盪(Brainstorming) 是一個在團體會議期間產生構想
的技術。參與者被鼓勵在一個極短的時間內，不經過任何分析的
情況下，盡可能地產生很多的構想，直到耗盡所有的想法為止。
JRP的利益
JRP 積極地讓使用者和管理部門參與發展專案 (鼓勵他們在專案中掌握
主權)。
JRP 減少了發展系統所需的時間。
當JRP 結合建立雛型作為一個確認需求和獲得設計認可的方法時，就可以
實現雛型的利益。
事實調查策略
1. 盡可能地了解所有現有的文件、表單、報告和檔案。
2. 如果合適，觀察作業中的系統。
3. 有了你已經收集到的事實，設計並分送問卷來澄清你不完全了解的事情。
4. 進行訪談 (或是群組工作會議)。
5. (選擇性的)。對於任何不了解的功能性需求，或是如果需求必須加以實證
時，建立發現式雛型。
6. 貫徹到底。
觀
念
介
紹
Men
u
以文件說明需求的方法
使用案例(use case) 是一個行為上順序相關的步驟(一個作業腳本
)，它是自動化的和人工作業的，目的在完成一個單獨的業務工作。
角色(actor) 代表任何需要與系統互動以交換資訊的任何事物。一
個角色可以是一個使用者，一個職務(role)，它可能是一個外部的
系統和人員。
時間性事件(temporal event) 是一個被時間觸發的系統事實。
使用案例運用的利益
促進使用者的參與。
從外部的使用者觀點來提供想要的系統功能性概觀。
創造一個對於驗證需求的有效工具。
提供一個有效的溝通工具。
觀
念
介
紹
Men
u
觀
念
介
紹
Men
u
圖
一
個
高
階
的
使
用
案
例
範
例
觀
念
介
紹
Men
u
需求的可回溯性(Requirements traceability) 是一
種能
力，它追溯一個系統功能或特徵回到要求這項功能的需求
上。
圖
需
求
表
格
的
一
個
範
例
觀
念
介
紹
Men
u
圖
會
員
服
務
系
統
求
的
部
分
表
格
三、範例研討
1.與你的組員一起工作，在你學校的註冊系統、財務
補助系統，或類似的系統中調查任何你已經知道的
問題。使用腦力激盪的技術來確認問題的成因和影
響，並建立一個魚骨圖。
2. 和一個負責你學校的註冊系統之業務分析師安排一
次訪談。根據她提供的資訊執行以下的事：
• 研討問題
a. 確定角色和由他們啟動的使用案例。
b. 對於一個學生選課的事件，完成一個使用案例描述。針對
一個學生退選一門課的事件來描述。
Men
u
四、單元討論
1. 比較功能性需求和非功能性需求。
2. 何謂Ishikawa圖？它的目的是什麼？
3. 何謂事實調查？
4. 需求定義文件中應該包含哪些項目？
5. 什麼是需求驗證？
6. 七種常用的事實調查技術是什麼？
7. 需求分析時希望回答的是哪些問題？
8. 當從現有的文件收集事實時，什麼是分析師第一個收集的文
件？什麼是分析師下一步應該做的？
9. 什麼是抽樣？兩種常用的抽樣技術是什麼？它們有什麼不同？
10.什麼是工作採樣？
11.使用問卷的四個優點是什麼？四個缺點是什麼？
12.定義並簡短地描述問卷的兩種類型？
Men
u
13.一般公認為最重要且最常用的事實調查技術是哪一種？
14.什麼是肢體語言？舉出一個使用肢體語言的例子。
15.列出四個空間地帶並描述各別的特徵。
16.定義發現式雛型？列出發現式雛型的三個優點和三個缺點。
17.什麼是合作需求規劃？
會議的參與者是誰？
19.誰是JRP 贊助人，他的角色是什麼？
20.誰是JRP 會議引導人，引導人的角色是什麼？
21.哪些是一個JRP 會議引導人最重要的特質？
22.何謂書記，他們在JRP 裡的角色是什麼？
23.計畫一個JRP 會議時包含哪些步驟？
會議應該在哪裡舉行？為什麼？
場地應該提供哪些資源？
26.進行一個JRP 會議時，JRP 會議引導人應該堅守的重要的
指
導方針是哪些？
Men
u
27.腦力激盪的三個規則是什麼？
28.透過一個成功的JRP 會議可以得到哪些利益？
29.為什麼一個分析師與一個最終使用者工作時要使用事實調查
的
策略呢？
30.定義專有名詞使用案例。舉出一個例子。
31.定義專有名詞角色。列舉一個例子。
32.定義時間性事件。啟動一個時間性事件的角色是誰？
33.一個使用案例中有哪幾部分不的內容？定義各個部分。
34.什麼是需求的可回溯性？
Men
u
谢 谢
五月-
2221:15:4121:1521
:15五月-22五月-
2221:15
21:1521:15:4
1五月-22五月
-2221:15:41
2022/5/24 21:15:41
