2026/01/24 (更新)
2026/02/23 (更新第二週、第三週內容)
2026/02/24 (更新第二週作業)
2026/03/06 (更新第三週內容)
2026/03/24 (更新第五週、第六週內容)
2026/03/31 (更新第八週內容)
2026/04/08 (更新第八週內容)
2026/04/20 (更新第九週內容)
2026/05/01 (更新評分標準)
2026/05/05 (更新第十一週進行方式)

注意，「系統分析與設計」課程會需要用到「程式設計」、「創新與設計思考」及「資料庫」的相關概念，請自行複習，老師不會重複講授這些概念。另外，未來專題或工作會用到的工具，不一定是系上課程中教過的，自主學習新工具非常重要，建議利用本課程學習新工具。

這個教學網站是為了輔仁大學資訊管理學系114學年度的「系統分析與設計」課程。

• 課程介紹

  • 開發方法論

    • Lean UX

    • Agile with UX

  • Gen AI工具

    • 在系統分析與設計課程中使用Gemini

  • AI增強開發工具

• 課程評分標準

  • 學長姐經驗 (個人作業 5%)

  • 課堂參與 (5%)

    • 由每組在期末推薦非本組最有貢獻的五位同學

  • 文件報告 (40%) (依組內分工給分)

    • 系統描述 & 初步軟體需求規格  (12%)

    • Sprint Review 1 (9%)

      • sprint1軟體需求規格(4030%)

        • 相關user story的驗收條件

      • sprint1軟體設計規格(6050%)

      • sprint1實作成果 (20%) 

        • 市場測試、使用者回饋

    • Sprint Review 2 (9%)

      • sprint2軟體需求規格 (4030%)

        • 相關user story的驗收條件

      • sprint2軟體設計規格 (6050%)

      • sprint2實作成果 (20%)

    • Final (10%)

      • sprint3軟體需求規格 (30%)

        • 相關user story的驗收條件

      • sprint3軟體設計規格 (50%)

      • 第四章系統專題實作成果 (20%)

  • 系統功能 (40%) (依組內分工給分)

    • Sprint Review 1 (8%)

    • Sprint Review 2 (16%)

    • Final (16%)

  • 小組分工 (5%)

  • Sprint report額外加分 (每次2%)

    • 由Scrum master負責

      • Spring planning、daily scrum、spring review、spring retrospective、分工

  • 個人學期自主學習及課程心得與建議 (5%)

    • 自主學習心得 (3%)

    • 學習心得 (1%)

    • 建議 (1%) 

• Homework

  • 下週小組報告 (不超過5分鐘)

    • 題目排除過去三年的題目 (如tronclass公告)，盡量思考可以找到使用者進行訪談的題目

    • 在系統分析與設計課程中使用Gemini

    • 問題陳述

      • 明確定義試圖解決的「問題」是什麼？這個問題對「誰」造成了困擾？這個問題目前是如何被解決的？ 現有解決方案有什麼「痛點」？

      • 創業時，我們在知乎聊什麼？ (deeplink學長姐分享，該場次未錄影，請參考投影片)

    • 利害關係人分析

      • 列出所有與本系統相關的「人」。直接系統使用者是最基本的（例如：學生、店長、管理員）。思考是否有其他利害關係人？（例如：出資的業主、系統維護者、部門主管）。不同利害關係人對系統的「期望」有何不同？

    • 需求蒐集方法

      • 說明如何「得知」這些需求？ 例如：訪談了 5 位潛在使用者、發放了 80 份線上問卷、觀察了 3 次現行作業流程、或是參考了特定法規或文獻。

    • 競爭者分析

      • 在市場上（包含 App Store、網路服務）尋找 2-3 個功能最相近的「競爭對手」或「替代方案」。分析它們的優點、缺點。

      • 競品分析方法論 (deeplink學長姐分享，該場次未錄影，請參考投影片)

    • 市場定位/ 利基

      • 綜合以上分析，說明系統與競爭者「有何不同」？「目標客群」是誰？ 闡述「價值主張」。

  • 學長姐經驗 

    • 請利用v-senpai詢問以下其中五個問題，並追問至少三個問題，並複製chatbot的回答，標示不滿意的答案 (一週內繳交) (2%)

      • 從系統分析與設計課程中遇到甚麼問題? 如何解決?

      • 從系統開發中遇到甚麼問題? 如何解決?

        • 使用git嗎? 遇到甚麼問題?

        • 使用哪個語言、資料庫開發? 為何? 優缺點是?

        • 使用生成式人工智慧嗎? 如何使用? 遇到甚麼問題?

        • 嘗試過自動測試嗎? 遇到甚麼問題?

        • 如何定期追蹤組員進度? 遇到甚麼問題?

      • (到目前為止，)專題遇到的最大問題是甚麼? 如何解決?

      • (到目前為止，)專題系統開發中遇到甚麼問題? 如何解決?

        • 使用git嗎? 遇到甚麼問題?

        • 使用哪個語言、資料庫開發? 跟SA所使用的一樣嗎? 為何? 優缺點是? 

        • 使用生成式人工智慧嗎? 如何使用? 遇到甚麼問題?

        • 嘗試過自動測試嗎? 遇到甚麼問題?

        • 如何定期追蹤組員進度? 跟SA一樣嗎? 遇到甚麼問題?

      • 對各位的建議是?

    • (3/17以後) 請利用新版對話機器人詢問至少五個問題，並複製chatbot的回答，標示不滿意的答案(3%)

    • 推薦觀看Deeplink學長姊與專題相關之分享

      • 小專題那些事

        • 陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋

      • 專題分享會

        • 游凱淳、李函澐、劉蓉瑄

      • 臉書實名制

        • 吳柏瑋

      • 揭開DeepLink的心路歷程

        • 陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋

      • Make a Killing! Futures Warbler

        • 廖奕慈、簡筠庭

      • 專題分享!深度學習-居家智慧照顧系統

        • 許智傑

      • 競賽心得分享

        • 陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋、蘇彥碩

      • 第28屆資服競賽得獎經驗分享 (EZ)

        • 吳姳蓁、彭于芳、張瑋純

      • 第28屆資服競賽得獎經驗分享【捐捐不息】

        • 詹宜璠、林鈺惠、邱柏儒、丘卉妍

      • :P-insurance 專題經驗分享

        • 顏佩臻、葉文心、游文瑄、劉幼祺、王乙婷、庾光威

• 建議組內分工

  • Scrum Master、Product Owner、前端、後端 (DB)、測試

    • 前端、後端 (DB)、測試同學評估相關技術

      • 可以利用過去所學的PHP+MySQL

      • 或者為專題做準備，學習新工具

        • 採用Next (React)及RWD

          • 吳濟聰老師的進階web程式設計課程教材

          • Next開發筆記

      • AI增強開發工具

        • Github Copilot

• 選題的流程

  • 各組報告(不超過5分鐘)

  • 自由退場時間

  • 票選主題

• 各組報告 (不超過5分鐘)

  • 問題陳述

  • 利害關係人分析

  • 需求蒐集方法

  • 競爭者分析

  • 市場定位/ 利基

• 自由退場時間

  • 如果剩下題目太少，啟動「題目門診」，大家選一些有潛力的題目，進行提案，增加候選主題

• 選出大家最有興趣的題目，三~四組用同一個題目

  • 選題目請考慮期末評分標準

    • 功能創新性、功能實用性、系統技術性、介面親和性、內容豐富性

  • 各組對提案提出申請 (總共10點去投票)，留下申請組別夠多的主題 (三到四個主題)，若最後主題未獲選，則從其他獲選中主題挑選主題

  • 由提案組挑選組別

  • 提案組將本週的報告投影片上傳到tronclass討論區

• Homework

  • 各組根據報告組提出的需求蒐集方法，進行進一步的需求蒐集

    • 需求分析

  • 下週由主題提供組主持，每個主題30分鐘，深入討論，確定產品目標及需求的細節，並逐步完成文件的第一章

    • 系統發展目的

    • 系統範圍

    • 背景知識

    • 系統限制

• https://sa2026.vercel.app/

  • 紀錄舉手發言的得分狀況

• 每個主題30分鐘，深入討論，確定產品目標(product goal)及需求的細節

• User Story及User Story Mapping

  • 有些需求比較大，沒辦法一次完成，列為Epic，再分解為User Story

  • 有些需求比較小，可以將幾個User Story統整為一個Epic

  • Epic說明Story之間的關係

    • User Story描述解決方案(需求)

      • Who, Why(問題) & What(需求)

      • 可利用GitHub Project分配工作與追蹤工作進度 / 小專題那些事 (陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋學長姐 deeplink分享)

• 根據產品目標及需求的細節經由Gemini或ChatGPT的協助撰寫User Story

  • 在系統分析與設計課程中使用Gemini

  • 老師隨機抽組別上台報告

• 參考資料

  • Agile

    • 需求不明確或多變動

    • 需求切割為單位很小(可以很快開發完)的user story

    • 將需求排優先順序，要開發前才去確認需求的細節

    • 利用Scrum(Sprint)或Kanban(WIP)來控制進度

• Homework

  • 下次隨機抽組別報告

    • 盤點所有的需求並以Epic/User Story呈現需求

      • 不需要驗收條件

  • 前端、後端 (DB)、測試同學評估並確認相關技術

    • AI增強開發工具

      • Github Copilot

  • 各組整理本週討論的內容，逐步完成文件的第二章

• 驗收條件

  • Given、When、Then

  • 在系統分析與設計課程中使用Gemini

• 3 Whys 攻防戰時間軸

  • 老師定調與靶子示範 (15 分鐘)

  • 第一輪攻防戰 (20 分鐘)

  • 第二輪攻防戰：敏捷迭代 (20 分鐘)

  • 小組大會師與殘酷結算 (10 分鐘)

  • 上傳「小組攻防紀錄與給分表」

• 題目大致底定，下週開始開發

  • 期末在教室驗收

• Homework

  • 下次報告

    • Sprint Planning

      • 根據Product Goal，設定Sprint 1的Sprint Goal

        • 根據Sprint Goal盤點對應的Epic/User Story

          • 如何決定Minimum Viable Product (MVP)?

            • 根據待解決問題或待提供的價值的優先順序

            • 重要的待確認假設

            • 功能的相依性

  • 下週繳交文件的第一章、第二章

    • Epic、User Story不含驗收條件 (Sprint Planning才寫)

  • 體驗GitHub Copilot

  • 利用Git整合程式碼

    • git新手入門教學 (deeplink學長姐分享)

• 補充資料

  • UML

• 第八週由積分決定驗收組別，第15週完成驗收的組別(group A)，第16週完成驗收的組別(group B)，第17週驗收的組別 (group C)

  • 第一個Sprint分兩週報告，groupB又分B1、B2

• Sprint Planning

  • 開始第一個Sprint

    • 根據產品目標 (product goal)確定sprint goal (最優先解決的問題/最優先提供的解決方案)

      • Sprint goal是指這個sprint預期完成的目標

    • 根據sprint goal盤點user story

      • 盤點能在一個sprint之內完成的user story

      • 根據Minimum Viable Product (MVP)去思考

      • 根據這些user story的接受/驗收條件並設計資料庫及畫面

    • 工作分配

      • 專案管理 (吳濟聰老師專案管理課程教材) / 小專題那些事 (陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋學長姐 deeplink分享)

      • 可利用github project分配工作與追蹤工作進度 

        • 小專題那些事 (陳姵淇、王曉瑜、羅巧筠、胡芸毓、徐浤瑋學長姐 deeplink分享)

      • 利用Git整合程式碼

        • git新手入門教學 (deeplink學長姐分享)

• Sprint Planning 驗收攻防戰

  • 老師定調與靶子示範 (10 分鐘)

    • 思考系統邊界與極端狀況

  • 各組準備驗收條件

  • Step 2 & 3：兩輪極速攻防戰 (各 20 分鐘)

  • Step 4：Sprint 任務拆解與給分 (20 分鐘)

• 找老師檢查github是否已設定好是否知道如何使用

  • 組長設定repository，組員已push內容到repository

  • 檢查後就可以下課

• Homework

  • 各組完成第一個sprint相關user story的接受/驗收條件條件、資料庫設計及畫面設計

  • Scrum master上傳進度報告

    • Sprint Planning

      • Sprint goal、user story工作分配

• 預告: 未來的sprint的各種報告(口頭報告當天23:59前上傳到TronClass)

  • Scrum Master負責上傳進度報告

    • Sprint Planning

      • Sprint goal、user story工作分配

    • Daily Scrum摘要 (開了幾次、遇到的問題、解決的方法)

    • Sprint Review

      • 整理大家的建議，以及對應的處理

    • Sprint Retrospective

      • 團隊合作方式、開發方式應該進行甚麼樣的調整

    • 下個Sprint的Sprint goal及user story

• Database

  • SQL vs. NoSQL

  • Supabase (吳濟聰老師進階web程式設計教材)

  • Firebase Firestore (吳濟聰老師進階web程式設計教材)

  • 聊聊 | 如何選擇合適的資料庫 (deeplink學長姐分享)

  • Firebase Cloud Firestore 筆記

• User Interface

  • RWD

  • UI設計入門 (UI設計與Figma) (李偉成學長 deeplink分享)

  • Scss!讓你的CSS不再雜亂無章 (deeplink學長姐分享)

  • 互動網頁需要的原來不是美感 (deeplink學長姐分享)

  • 切版助教三個月目睹之怪現狀 (deeplink學長姐分享)

• User Experience 

  • 視覺層級 (吳濟聰老師碩士在職班使用者經驗設計課程教材)

  • 互動設計 (吳濟聰老師碩士在職班使用者經驗設計課程教材)

  • 資訊架構 / [好書推薦] 資訊架構學 (deeplink分享)

• 由積分決定驗收組別，第15週完成驗收的組別(group A)，第16週完成驗收的組別(group B)，第17週驗收的組別 (group C)

  • 二甲: 第九週 A1-A5、第十週 B1-B5

  • 二乙: 第九週 A1-A6、B1-B2、第十週 B3-B5、C1-C3

• Daily Scrum

  • 重點不在於進度報告，而是解決進度上的問題

    • 需求上的疑惑

    • 討論如何解決，而不是指責

  • 請記錄遇到甚麼問題以及解決方案

  • 是否需要進行優先順序、工作分配等調整?

• 軟體品質

  • 驗收條件與測試

    • 測試 (進階web程式設計)

    • Copilot利用驗收條件撰寫自動化測試腳本，並進行自動化測試

      • GitHub Copilot Agent Mode

      • 測試

      • GitHub Copilot Skills

        • 以測試為例提供skill範例

  • Quality  / 軟體品質 (吳濟聰老師 deeplink分享)

    • Coding Standard

      • 請參考Sprint 1實作裡的CONVENTIONS.md

    • Code Review

    • Code Refactoring

• 各組請Gen AI (Copilot)撰寫測試腳本並進行測試，找老師驗收後才可以下課

  • 根據sprint goal，利用自動化測試確保最重要的功能已經完成，並進行對應的測試

    • 單元測試測試

      • 使用ViTest或PHP Unit

      • 個別執行

    • E2E測試

      • 使用Playwright

      • 個別執行，一起執行都不能有問題

• 下週報告組繳交文件

  • Sprint 1的

    • 驗收條件 (第六週就應該已經完成)

    • Database

    • User Interface

• 下週

  • Sprint Review

    • 針對報告組進行幾輪的分組驗收

      • 報告組根據Sprint Goal，所完成User Story的功能展示

      • 驗收組思考完成的功能與Sprint Goal、Product Goal的差距

        • 有沒有根據使用者的痛點提出解決方案?

      • 老師會從本週的驗收成果決定參與哪些組的驗收

    • 整理驗收結果

  • Sprint Retrospective (分組驗收後)

    • 造成與目標的差距的原因 (問題)

    • 調整作法 (解決方案)

      • 有需要的話，老師可以協助

• Sprint review 1

  • 二甲: 第九週 A1-A5、第十週 B1-B5

  • 二乙: 第九週 A1-A6、B1-B2、第十週 B3-B5、C1-C3

  • 請於報告前前繳交文件至Tronclass，遲交者視遲交情況酌予扣分。

    • 文件包含

      • 第一章、第二章、第三章 (只需要sprint 1相關設計)

  • Sprint Review

    • 報告組上台報告，所有組別對除了本組織外的組別評分

      • 評分項目:

        • 功能創新性 (20%): 解法夠不夠聰明？是否用打破常規的方式解決痛點？或是巧妙運用了工具輔助產出了意想不到的系統亮點？

        • 功能實用性 (50%): 痛點是否真的被解決？(核心價值) 這個 MVP 是否真實對應了 User Story？如果明天系統上線，真實使用者會不會想用？還是淪為偽需求？

        • 系統技術性 (10%): 防呆與架構穩不穩？實機 Demo 時是否順暢無報錯？

        • 介面親和性 (10%): 操作動線是否直覺 (UI/UX)？ 不需要看說明書，使用者能否在短時間內順利走完「核心任務」的流程？

        • 內容豐富性 (10%): MVP 的完成度與真實感？測試資料是否用心（不是只有 test 123）？作為一個 MVP，周邊的輔助資訊或資料庫關聯是否完整？

    • 報告組回應並紀錄與整理老師及各組的發問 (Sprint Review報告)

  • Sprint Retrospective (分組驗收後)

    • 造成與目標的差距的原因 (問題)

    • 調整作法 (解決方案)

      • 有需要的話，老師可以協助

  • 組長繳交sprint進度報告 (報告當天23:59前上傳到TronClass)

    • • Sprint planning

        • Sprint goal

      • Daily Scrum摘要

        • 開了幾次、遇到的問題、解決的方法

      • Sprint Review

        • 整理大家的建議，以及對應的處理

      • Sprint Retrospective

        • 團隊合作方式、開發方式應該進行甚麼樣的調整

      • 下個Sprint的Sprint Planning

        • 下個Sprint的Sprint goal及user story

• Sprint review 1

  • 二甲: 第九週 A1-A5、第十週 B1-B5

  • 二乙: 第九週 A1-A6、B1-B2、第十週 B3-B5、C1-C3

• 由Sprint 2的優先發問組(攻擊組)對報告組(防禦組)進行獨立驗收

  • 由Sprint 2的攻擊組填寫獨立驗收 (IV&V) 三輪戰報表

  • 防禦組提供Product Goal、Sprint 1的Sprint Goal (10分鐘)

  • 攻擊組根據生成式AI的建議，以及小組的想法，提出5個驗收條件 (10分鐘)

    • 產生驗收條件並提供給防禦組

【攻擊手專用：雙層次規格生成 Prompt】

「這是一個正在開發中的系統專案，目前剛剛結束 Sprint 1 的開發。

我們的 Product Goal (最終產品願景) 是：【填入防禦組的產品願景】

我們本階段的 Sprint 1 Goal (當前衝刺目標) 是：【填入防禦組的 Sprint 1 目標】

請你扮演一位極度嚴格的系統分析師 (SA)。請在**『絕對不超出 Sprint 1 Goal 開發範圍』的前提下，為了確保系統未來能順利往 Product Goal 邁進，列出 5 條這個系統目前『必須具備、且最容易被忽略的底層邏輯』**的 Acceptance Criteria (AC)。請以 BDD (Given-When-Then) 格式輸出。請專攻異常流程 (Unhappy Path) 與資料狀態的防呆。」

• • 第一輪驗收

    • 防禦組有20分鐘準備第一輪驗收

    • 攻擊組有20分鐘進行第一輪驗收

      • 每組派兩到三位同學扮演攻擊手，根據剛剛給的五個驗收條件進行驗收，也可以進行臨時驗收，並記錄驗收結果

      • 其他同學擔任防禦員，接受驗收，並記錄驗收結果 (做為改進依據，不必繳交)

  • 第二輪驗收

    • 防禦組有15分鐘準備第二輪驗收

      • 針對前一輪驗收進行緊急修補

    • 攻擊組有15分鐘進行第二輪驗收

      • 每組派兩到三位同學扮演攻擊手，根據未通過的驗收進行補強驗收，也可以進行臨時驗收，如果第一輪完美通過驗收，請新增臨時驗收，並記錄驗收結果

      • 其他同學擔任防禦員，接受驗收，並記錄驗收結果 (做為改進依據，不必繳交)

  • 第三輪驗收 (重點在於針對Sprint 2的sprint goal，然而Sprint 2剛開始，所以，重點在於Sprint 2的準備)

    • 防禦組有15分鐘準備第三輪驗收

    • 攻擊組有15分鐘進行第三輪驗收

• Group A sprint review 2

• Group B sprint review 2

• Group C sprint review 2

• 驗收程序:

  • 請於驗收前繳交文件至Tronclass，遲交者視遲交情況酌予扣分。

  • 驗收系統功能，核對系統功能、資料庫與文件是否相符，不相符者視情況酌予扣分。

  • 老師先驗收第3個sprint的進度，接下來依據分工表驗收。

  • 接下來由助教進行系統的驗收、評分。

• 驗收標準:

  • 若系統未完成整合，一律不驗收。請仔細測試系統，若系統還有語法錯誤或無法執行，也不驗收。

  • 同組同學都應到場(上線)，老師將依據分工表，驗收每一位同學負責的部份，並抽檢程式碼，若發現與實際狀況不符的現象，老師將當場要求更改分工表。

• 未於規定時間內完成驗收，視情況酌予扣分，驗收最後期限為6/10 16:00。

• 總成績可能不及格的同學，請提前繳交自主學習作業，學期總成績滿50分但未達60分者，可以透過補救作業補救，老師會視分數差距給不同程度的補救作業(例如:修改文件或完成某個功能)，補救作業完成期限為6/10 16:00，延長至6/13 16:00。

• 驗收

• 驗收

• 繳交個人學期自主學習心得、課程心得與課程建議 (5%)

  • 自主學習心得 (3%)

  • 課程心得 (1%)

  • 課程建議 (1%) 

• 請挑選任一方向進行自主學習

  • 參加專題發表，並訪談一位學長姐以及參加心得

    • 專題遇到的最大問題是甚麼? 如何解決?

    • 專題系統開發中遇到甚麼問題? 如何解決?

      • 使用git嗎? 遇到甚麼問題?

      • 使用哪個語言、資料庫開發? 跟SA所使用的一樣嗎? 為何? 優缺點是? 

      • 使用生成式人工智慧嗎? 如何使用? 遇到甚麼問題?

      • 嘗試過自動測試嗎? 遇到甚麼問題?

      • 如何定期追蹤組員進度? 跟SA一樣嗎? 遇到甚麼問題?

    • 對各位的建議是?

    • 對於學長姐的發表有何心得?

  • UX心理學 (吳濟聰老師powercam影片) 

    • 使用者經驗與心理學 (吳濟聰老師使用者經驗設計課程內容)

    • 好書導讀: 設計的心理學 (吳濟聰老師 deeplink分享)

  • Database

    • SQL vs. NoSQL

    • 聊聊 | 如何選擇合適的資料庫 (deeplink學長姐分享)

    • Firebase (吳濟聰老師進階Web程式設計教材)

  • Scrum (吳濟聰老師敏捷式軟體開發課程內容)

    • The Scrum Guide (吳濟聰老師敏捷式軟體開發課程內容)

    • Team (吳濟聰老師敏捷式軟體開發課程內容)

    • Events (吳濟聰老師敏捷式軟體開發課程內容)

    • Artifacts (吳濟聰老師敏捷式軟體開發課程內容)

  • 測試

    • 測試導向開發 (吳濟聰老師敏捷式軟體開發課程內容)

    • 軟體測試 (吳濟聰老師敏捷式軟體開發課程內容)