問題建構和分析

核心概念

「界定問題」是指在開始設計或編寫程式之前，把要解決的事情說得精確、清楚、可驗證。它不只是「知道自己想做甚麼」，而是要把目標、範圍、對象與限制條件具體化，令團隊能用同一種理解去工作。

• 避免答非所問：如果問題描述含糊，即使程式寫得無錯，也可能解決了「另一個」問題。
• 方便評估是否成功：界定清楚後，才可以設定可量度的成功準則（例如「輸出必須在 1 秒內完成」）。
• 減少返工：早期釐清需求，比後期改動系統成本更低。

將問題「框」出邊界

界定問題時，最容易忽略的是「邊界」。同一個題目，只要範圍不同，系統設計會差很遠。

• In-scope（涵蓋範圍）：系統必須做到的功能／情境。
• Out-of-scope（不包括）：明確列出「暫時不做」的部分，避免需求無止境膨脹。
• 假設（Assumptions）：例如「所有身高輸入以米為單位」、「用戶已登入」等。
• 約束（Constraints）：例如「只能使用校內電腦」、「必須離線運作」、「數據庫只能用 SQLite」等。

兩類需求要分清

• 功能性需求（Functional Requirements）：系統要做甚麼，例如「計算 BMI」、「顯示類別」、「儲存用戶紀錄」。
• 非功能性需求（Non-functional Requirements）：系統做到有幾好，例如速度、可靠性、易用性、保安、可維護性。

例子（BMI 計算器）

• 功能性需求：用戶輸入身高與體重 → 系統計算 BMI → 顯示數值及「正常／過重」等類別。
• 非功能性需求：輸入錯誤要即時提示；界面清晰；輸出保留 1 位小數；可在手機瀏覽器正常顯示。

用 5W1H 問到「具體」

六何法是一組提問框架，協助你從不同角度把需求問清楚。

• Who：誰會使用？（目標用戶、管理員、不同權限）
• What：要提供甚麼內容／功能？（輸入、輸出、主要功能）
• When：何時使用？（使用頻率、截止時間、操作流程時序）
• Where：在哪裡使用？（手機／電腦、校內／校外、線上／離線）
• Why：為甚麼需要？（痛點、目的、成功標準）
• How：如何運作？（規則、限制、例外情況、資料來源）

為何要做資料搜集？

資料搜集不是「找資料填充」，而是用來驗證假設、理解用戶習慣，以及找出真實限制。

• 訪談：直接問用戶的流程、困難與期望。
• 問卷：收集大量意見，適合比較偏好或需求優先次序。
• 觀察：看用戶實際怎樣做，而不是只聽他們怎樣說。
• 參考同類系統：了解常見功能與界面做法，避免重覆踩坑。

心智圖（mind map）如何用？

把問題放在中心，向外延伸：用戶 → 功能 → 輸入資料 → 輸出結果 → 限制／例外。完成後，便可整理成需求清單。

常見文件／成果

• 問題陳述（Problem Statement）：一段簡潔文字，清楚交代情境、對象、目標。
• 需求清單：以條列方式列出功能性／非功能性需求。
• 成功準則（Acceptance Criteria）：如何判斷系統「合格」；例如輸出格式、正確性、時間限制。
• 範圍聲明：列出 in-scope / out-of-scope，避免爭拗。

輸入 ‧ 處理 ‧ 輸出（Input–Process–Output）

IPO 是分析問題最常用的框架之一，用來把一個系統的運作「拆成三塊」：

• 輸入（Input）：系統需要取得哪些資料？資料從哪裡來？（用戶輸入、感測器、檔案、網絡等）
• 處理（Process）：系統要對輸入資料做哪些運算／判斷／轉換？（公式、比較、分類、迴圈、排序等）
• 輸出（Output）：系統最後要向用戶呈現甚麼結果？以甚麼形式呈現？（文字、圖表、提示訊息、檔案等）

找輸入資料的三個問題

• 來源：資料來自哪裡？（表單、條碼掃描、感測器、數據庫、API）
• 格式：資料是數字、文字、日期，還是選項？是否有單位？
• 驗證：哪些輸入屬於不合理／不允許？要怎樣提示用戶？

例子（BMI）

• 身高通常以米（m）或厘米（cm）輸入；若單位不同，處理步驟亦要加入「單位轉換」。
• 身高不能為 0 或負數；體重亦不應為負數。

處理 = 具體步驟 + 規則

「處理」不是一句「計算一下」就算。應把主要步驟寫到他人可跟隨，並指出規則／例外情況。

• 運算：加減乘除、平方、平均、四捨五入等。
• 判斷：若…則…否則…（分類、是否符合條件）
• 重複：對多個項目做相同步驟（例如累加總價）

用書面語描述 BMI 處理

1. 接收身高（m）及體重（kg）。
2. 以公式 BMI = 體重 ÷ 身高² 計算數值。
3. 按 BMI 數值範圍判斷類別（過輕、正常、過重、肥胖）。
4. 把 BMI 及類別輸出。

輸出要配合用戶需要

輸出是系統的「可見成果」。良好的輸出設計，能讓用戶理解結果並採取行動。

• 內容：輸出甚麼？（數值、類別、建議、錯誤提示）
• 格式：要不要顯示小數？用文字還是圖表？要不要加單位？
• 情境：在甚麼時候輸出？（即時、完成後、錯誤時）

例子（BMI）

• 只輸出「23.4」並不足夠；配合「正常」或「過重」類別，才對一般用戶有意義。
• 如題目允許，可加入簡短提示（例如「如有疑慮請諮詢專業人士」）。

把 IPO 轉化為演算法

IPO 不是終點，而是「過渡」。完成 IPO 後，下一步通常是把處理步驟轉化為流程圖或偽代碼。

• 輸入 → 變成「讀取／輸入」指令或流程圖中的 I/O 符號。
• 處理 → 變成「運算、判斷、迴圈」的步驟方塊。
• 輸出 → 變成「顯示／輸出」指令或 I/O 符號。

學生常見錯誤

• 輸入寫得不完整：只寫「輸入資料」，但沒有說明是哪一種資料、單位、來源。
• 處理寫成口號：例如「計算 BMI」但沒有公式或分類規則。
• 輸出只寫「顯示結果」：沒有說明結果包含甚麼（數值？類別？提示訊息？）。

甚麼是拆解問題（Decomposition）？

拆解問題是把一個大型或複雜的問題，分拆成多個較細小、較清晰、較容易處理的子問題（sub-problems）。每個子問題都可以獨立思考、獨立設計，最後再整合成完整解決方案。

• 降低認知負擔：一次只處理一小部分，思路更清晰。
• 方便分工：不同人可負責不同模組。
• 方便測試與除錯：錯誤較容易定位到某一模組。

Top-down 與 Stepwise refinement

• 由上而下（Top-down）：先寫出整體目標，再把它分成主要功能，再把每個功能繼續拆細。
• 逐步求精（Stepwise refinement）：先用較粗略步驟描述，然後逐步把每一步改寫得更具體，直到每一步都能清楚執行。

例子（網上商店）

• 整體：網上商店
• 第一層：登入／商品瀏覽／購物車／付款
• 再拆：付款 → 計算總額 → 套用折扣 → 選擇付款方式 → 確認付款

模組界面（Interface）的觀念

當問題被拆成多個模組後，每個模組都應清楚說明：

• 輸入：這個模組需要甚麼資料？
• 處理：在模組內做甚麼？
• 輸出：回傳甚麼結果給其他模組？

例子（計算購物總金額）

• 模組：計算總額
• 輸入：商品價格清單
• 輸出：總金額（數值）

合適的拆解粒度

拆解太粗會難以實作；拆解太細則會令管理成本增加。一般可用以下準則：

• 一個步驟是否仍然含糊到需要再問「其實怎樣做？」若是，應再拆細。
• 一個模組是否可以在短時間內獨立完成、獨立測試？若不能，可能仍太大。
• 一個模組是否只有「一個主要責任」？若同時負責多件事，建議分拆。

為何拆解能提升程式質素？

• 重用（Reusability）：例如「輸入驗證」模組，可在多個表單重用。
• 維護（Maintainability）：需求改動時，只需修改相關模組，不必重寫整個系統。
• 單元測試（Unit Testing）：可為每個模組建立測試資料，逐一驗證正確性。

拆解後仍可能出問題

• 耦合（Coupling）過高：模組互相依賴太多細節，改一個模組就牽連全局。
• 責任重疊：兩個模組做相同工作，造成重複與矛盾。
• 命名含糊：例如「處理資料」沒有說明處理甚麼、輸出甚麼，難以維護。

模式識別（Pattern Recognition）

模式識別是指在多個問題之間找出重複出現的結構、規律或處理方式，從而重用相似的解決方法。它不是「死記硬背」，而是把共通部分抽出來，形成通用策略。

• 重點：找的是「結構相似」，例如同樣需要累加、同樣需要逐一比較、同樣需要分類。
• 結果：你可以把解法變成「模板」，下次遇到同類題目，只要換資料或條件即可。

由下而上歸納（Bottom-up）

做模式識別時，可先列出幾個具體例子，再問：「它們的共同步驟是甚麼？」常見共通模式包括：

• 累加（Accumulation）：例如計算購物總額、計算總分。
• 計數（Counting）：例如計算合格人數、計算出現次數。
• 尋找最大／最小：例如找最高分、最便宜商品。
• 分類（Classification）：例如 BMI 類別、成績等級。

把相同解法寫成通用形式

當你已找到共同模式，下一步是把差異部分變成「參數」，令解法更通用。

例子：排序

• 共同部分：比較兩個值、決定次序、重覆直到完成。
• 可變部分：比較的是身高、體重、價錢，或其他欄位。

例子：總金額

• 共同部分：把每件商品價錢加入總和。
• 可變部分：是否需要折扣、是否加運費、是否計稅。

為何模式識別能提升效率？

• 減少重新發明：遇到新題目時，不必每次由零開始構思。
• 降低錯誤：成熟的模式通常已被多次驗證，更可靠。
• 促進學習遷移：學生能把在一題學到的做法，遷移到另一題。

小心錯誤類比

兩個問題看似相似，但其實可能在關鍵條件上不同，例如：

• 排序：是否允許相同值？是否需要穩定排序？
• 累加：是否要排除負數？是否要處理缺失值？
• 分類：分界線是否包含等號（≥ 或 ＞）？

抽象化（Abstraction）

抽象化是指在解決問題時，刻意忽略不必要的細節，只保留對解決問題最關鍵的資訊與結構。目的不是令事情「更簡單就算」，而是令我們能把注意力放在真正影響結果的部分。

• 降低複雜度：資訊過多會令人難以判斷重點，抽象化可提升理解與決策效率。
• 方便溝通：用簡化模型與他人討論，較容易達成共識。
• 利於設計：系統分析時先用抽象模型（如 IPO、流程圖）描述，再逐步補回細節。

不同層次的抽象

同一事物可以用不同抽象層次表示：

• 高層次：只描述目的與主要流程（例如「用戶輸入 → 系統計算 → 顯示結果」）。
• 中層次：描述資料欄位、規則、主要例外情況。
• 低層次：具體到變量、資料型態、每一行程式步驟。

資料抽象化（Data Abstraction）

資料抽象化是決定「哪些資料值得記錄」。例如同學資料可以有很多細節，但若目標只是計算平均分，可能只需要分數。

例子：學生紀錄

• 可能的資料：姓名、班別、電話、地址、生日、成績、出席率…
• 若題目是「按成績排序」：關鍵欄位是姓名 + 成績；其他欄位可暫時忽略。

程序抽象化（Procedural Abstraction）

在程式設計中，我們經常用函式（function）把一段複雜步驟封裝起來，外部只需要知道「輸入甚麼、輸出甚麼」，而不必每次重看內部細節。

例子（BMI）

• calculateBMI(height, weight)：輸入身高與體重，輸出 BMI 數值。
• classifyBMI(bmi)：輸入 BMI，輸出類別。

日常例子背後的共同原理

• 地鐵路線圖：重點是站點與轉線關係，而非真實地理距離。
• 時間表：只保留時間、科目、地點等決策所需資訊。
• 地圖 App：縮放時會自動隱藏小路或細節，只保留主要道路與地標。

如何取得平衡？

• 抽象太少：把所有細節都納入，導致分析混亂、設計困難。
• 抽象太多：刪走了關鍵限制或例外情況，令方案不可行或不正確。

基本概念

• UI（User Interface，用戶界面）：用戶看得到、摸得到的界面元素，例如按鈕、表單、選單、提示訊息。
• UX（User Experience，用戶體驗）：用戶使用過程的整體感受，例如是否順暢、是否容易理解、是否感到安心。

良好的 UI 設計能降低用戶犯錯，提升完成任務的速度與滿意度；因此它是系統成功與否的重要因素之一。

讓用戶輸入得正確

• 清楚標籤（Label）：例如「身高（m）」比「身高」更不易出錯。
• 提示格式：用 placeholder 或例子提醒格式（例如「例如：51234567」）。
• 必填欄位：用 * 或文字說明，並在提交前提示缺漏。
• 限制與驗證：限制只能輸入數字、設定範圍（例如身高 0.5–2.5 m）。

好錯誤訊息的三個元素

• 指出位置：是哪一個欄位或哪一步出錯。
• 說明原因：為何不接受該輸入。
• 提供修正方法：應該改成甚麼格式或範圍。

例子

• 較差：Error
• 較好：「電話號碼必須為 8 位數字，請重新輸入。」

一致性（Consistency）

• 視覺一致：顏色、字體、按鈕樣式、間距保持一致。
• 行為一致：相同操作得到相似結果，例如「儲存」按鈕永遠在相近位置。
• 用詞一致：同一概念不要一時叫「提交」一時叫「確認」。

資訊層次（Hierarchy）

用標題、分段、列表等方式突出重點，令用戶容易掃視與定位。

讓更多人能順利使用

• 文字可讀：字體大小適中，行距合理。
• 顏色對比：重要資訊不要只靠顏色區分；避免低對比造成難以閱讀。
• 鍵盤操作：表單與按鈕應可用鍵盤完成操作（對部分用戶很重要）。
• 清楚語言：避免含糊字眼，用短句說明操作。

UI 設計是一個迭代過程

1. 建立原型：先畫草圖或低保真 prototype（不必一開始就完美）。
2. 找用戶試用：觀察他們在哪裡卡住、誤解、輸入錯誤。
3. 收集意見並改良：逐步提升清晰度與效率。

計算思維（Computational Thinking）

計算思維不是「只屬於寫程式的人」的思維，而是一套用來解決問題的系統化方法。其核心是把問題轉化成清晰步驟與可處理的資料。

四大元素

• 分解（Decomposition）：把大問題拆成小問題。
• 模式識別（Pattern Recognition）：找出相似問題的共同結構與可重用方法。
• 抽象化（Abstraction）：忽略不重要細節，保留關鍵資訊。
• 演算法設計（Algorithm Design）：把解法寫成清晰、有次序的步驟。

例子：超市購物結帳

1. 分解：把問題分成「讀取每件商品價錢」、「把價錢加入總額」、「輸出總額」。
2. 模式識別：發現「逐件加入總額」會重複出現，因此可用迴圈。
3. 抽象化：忽略品牌與包裝，只保留「價錢」這個關鍵數值。
4. 演算法設計：初始化 total = 0；重複讀取每件價錢 p；total = total + p；最後輸出 total。

把思維映射到程式結構

• 分解 → 多個函式／模組（每個模組處理一個子任務）。
• 模式識別 → 迴圈（for/while）、通用函式、模板化做法。
• 抽象化 → 變量、數據結構（只保留必要欄位）、界面封裝。
• 演算法設計 → 偽代碼、流程圖、逐步的程式語句。

良好演算法的特徵

• 清晰（Unambiguous）：每一步都不含糊，不能有多重解讀。
• 完整（Complete）：包括輸入、處理、輸出，以及必要的例外情況。
• 可執行（Effective）：每一步都能在有限時間內完成。
• 可驗證（Testable）：能設計測試資料檢查輸出是否正確。

避免走偏

• 只記語法：語法是工具；思維與設計才是核心。
• 忽略需求：演算法再快，如果輸出不是用戶需要的內容，仍然失敗。
• 不做測試：沒有測試就難以證明解法正確。

六個常見步驟

1. 界定問題：釐清目標、範圍、對象與限制。
2. 分析問題：整理所需輸入、處理、輸出（例如用 IPO）。
3. 設計解決方案：設計演算法、流程圖、數據結構與界面。
4. 實施解決方案：把設計落實為程式／系統。
5. 測試及改善：用測試資料驗證正確性並修正錯誤。
6. 評估結果：檢查是否符合需求與成功準則，並提出改良方向。

設計階段要做的事

• 演算法：用清晰步驟描述做法，可用偽代碼或自然語言。
• 流程圖：用圖像表示順序、分支、迴圈，適合展示整體流程。
• 資料設計：決定需要哪些變量、資料型態、表格欄位或數據結構。

選用建議

• 要快速溝通流程：流程圖很直觀。
• 要直接轉成程式：偽代碼更貼近程式語句。
• 要處理資料關係：先做資料設計（例如欄位、清單、字典）。

落實方案時的重點

• 模組化：配合 1.3 拆解，把不同功能寫成獨立函式／模組。
• 命名清晰：變量與函式名稱要反映用途（例如 bmi、height_m）。
• 註釋與文件：在關鍵位置加註釋，並保持程式結構整潔。
• 處理錯誤：預留輸入錯誤、缺失資料等情況的處理。

測試不只是按幾下

測試的目標是以有系統的方法，找出程式在不同情況下是否能輸出正確結果。

常見測試數據

• 一般情況（Normal）：合理常見輸入。
• 邊界情況（Boundary）：最大／最小／臨界值（例如 BMI 分界線附近）。
• 異常情況（Abnormal）：空白、文字輸入、負數、超出範圍等。

除錯是一個循環

1. 重現問題：用相同輸入再次出現錯誤，確保問題可重覆。
2. 定位位置：用輸出訊息、追蹤變量（trace）、分段測試找出哪一步出錯。
3. 找根因：是公式錯、條件寫反、資料型態不對，還是漏處理例外？
4. 修正後回歸測試：修正後要重新跑之前的測試，確保沒有引入新問題。

評估常見準則

• 正確性：輸出是否符合需求與預期？
• 效率：時間／空間資源是否合理？
• 易用性：界面是否清楚、流程是否順暢？
• 可靠性與保安：是否能避免錯誤輸入造成崩潰？資料是否安全？
• 可維護性：日後需求改動時是否容易修改？