流程整合需求規格怎麼寫？交代觸發、輸入、輸出和排除項

把一段現行流程整理成可估價的需求說明：寫清楚參與者、觸發條件、資料流向、限制、假設、排除項目與例外情境。

流程整合需求規格的用途，是讓委託方與執行者能依同一份說明估算工作、指出未知，並在交付時逐項核對。先挑一段有明確起點和終點的流程，再寫下現況、角色、資料、限制、假設、排除項與例外。以下以「網站表單詢問由團隊接手」作為假設情境，只用來示範如何描述需求，不代表任何公司的既有系統或處理成果。

描述現況流程

先把現行做法寫成從起點到終點的連續動作，描述現在實際怎麼做，不要先把期待中的自動化寫成現況。起點要能被觀察，例如有人送出詢問表單；終點也要可辨認，例如負責人已收到可處理的案件，而不是籠統寫「完成整合」。若流程中有人工判斷，記下判斷者看到哪些資訊、採取什麼動作，以及判斷後案件流向哪裡。

接著標出人與系統之間的交接：資料從哪個畫面或檔案進來，誰負責複製、整理、確認，再通知下一位；發生錯誤時目前怎麼發現，需不需要回頭補件。把等待、重複輸入和例外分開記錄，避免把痛點藏在「手動處理」四個字裡。若某一步依靠個人經驗，寫一個具體情境和目前處置方式，讓估價者看出規則是否清楚，或仍需訪談釐清。

可以用「角色、收到什麼、做什麼、留下什麼、下一站」記錄每一站；有分支時，從條件處分開描述，不要把不同路徑塞進同一條箭頭。假設表單詢問送出後，窗口先檢查內容，再依問題類型交給不同負責人；如果資料不完整，就通知補件並等待回覆，而不是直接分派。這樣能看出哪些是現況步驟，哪些是需要納入的新工作。

最後附上一筆去識別化樣本或表格截圖，讓文字描述能對照實際欄位；遮掉姓名、電話等不必要的個人資料。逐步核對文件與實際做法是否一致，若訪談中出現不同版本，就列出差異、暫採假設和待確認的人。忠實呈現現況能避免估價時漏掉資料整理、流程轉換或保留舊作法的工作，也讓雙方知道討論的是哪一個流程版本。

列出使用者與觸發

使用者不只包含最後操作畫面的人，也可能包括提出需求的人、負責處理的人、核准者和維護資料的人。逐一寫出他們的工作目標與責任：誰建立案件，誰判斷類型，誰能改派或結案，誰只查看進度。不要只寫「員工」或「管理者」；同一個人可能兼任多種角色，但不同權限仍要說清楚，否則執行者無法估算需要幾種操作路徑。

接著定義觸發條件，也就是什麼事件讓流程開始。可能是表單送出、收到指定檔案、有人按下確認，或每日由人員整理一批資料。寫出觸發來源、發生時點、必要條件，以及相同事件再次出現時怎麼處理。像「有新詢問」仍不夠明確：測試資料算不算、空白內容算不算、同一人重送要新建案件還是補進原案件，都會改變實作方式。

對假設中的表單流程，可以將角色分成提問者、窗口與問題負責人。提問者提交內容後，窗口看到新案件並檢查完整度；內容齊全才交給負責人，缺少必要資料則由窗口聯絡補充。若窗口休假或沒有適合的負責人，案件先交給誰？這些安排應寫成可確認的條件，不要用「系統自動找對的人」代替尚未定義的分派規則。

權限也要跟著角色列出。哪些人能讀取聯絡資料，哪些人可以改分類、指派、退回補件或結案；離職或輪班交接時由誰調整權限，也可列為待確認。觸發後是否需要人工確認、人工能否取消或修正，也會影響流程邊界。若這些細節尚未決定，就明確標成假設或待確認事項，避免把一個模糊職稱誤當成已定案的操作權限。

明確輸入與輸出

每一項輸入都要寫清楚來源、格式、必要性和用途。除了表單欄位，也可能有附件、識別碼、時間、分類或人工補充；說明哪些欄位必填，空白或格式錯誤如何處理，是否允許同一筆資料重送。不要只寫「接收表單資料」，因為執行者還需要知道取哪些欄位、如何判定有效，以及資料缺漏時要停止、提醒補件，還是交由人員判斷。

輸出則描述流程結束後留下什麼，以及誰會看到或使用它。可能是案件紀錄、分類結果、通知內容或待辦狀態；需說明產生位置、欄位、接收對象與完成條件。通知送出不一定等於案件完成，若還要有人確認或回覆，就把確認步驟列出。這也能協助估價者分辨必要交付與尚未決定的需求。

這張表只是示意，不代表某個工具已具備相關功能。把輸入與輸出一一對照，才能發現欄位是否在過程中遺失、產生的結果能否支持下一位工作，以及是否需要保留原始內容供人工查閱。若要使用外部表單、CRM或自動化工具，請把它們寫成待評估的整合選項，並確認可用資料與權限，不要把工具名稱當成已核實的能力。

記錄限制與假設

限制是會影響設計或估價的現實條件，例如現有系統能否提供資料、哪些人有帳號、誰能核准欄位異動，以及可接受的操作方式。把已知條件和仍待確認的條件分開；「目前由窗口用試算表記錄」是現況描述，「新流程必須沿用該檔案」才是限制。若限制尚未確認，寫明要向誰取得答案，以及答案會影響哪一段範圍，讓未定事項不會被誤當成承諾。

假設則是為了先估算而暫時採用的前提。比如假設提交資料會包含可聯絡的方式，若實際資料常缺漏，就可能需要增加補件、暫存或人工追蹤。每項假設都要說明成立條件與不成立時的影響；必要時列出需確認的日期或負責角色，但不要把未確認的內容寫成已同意的規格。估價者才能看出哪些工作已可估算，哪些會因答案不同而改變。

資料規則也應寫在限制或假設裡：哪些資料可供哪些角色查看，是否要保留歷程，錯誤資料由誰修正，附件或內容有沒有格式及容量要求。若答案涉及外部系統、帳號或資料授權，就記下需由誰確認可取得的權限與介面。尚未核實前，不要假定某工具能匯入、通知或同步特定資料；把能力確認列成前置事項，避免估價建立在想像的連接方式上。

用假設情境來說，若目前不確定問題分類由窗口選擇還是自動判定，可以先把人工選擇列為估算前提，並標註自動判定不在這個前提內。若窗口表示分類規則已有書面版本，再更新規格並確認例外如何處理。每次改動都記錄來源、日期和受影響的項目，雙方就能追查估價差異來自需求更新，而非對同一段文字有不同理解。

標示排除項目

排除項目要寫成讀者可以判斷的工作邊界，而不是只列「其他不含」。可以交代這次不做哪些角色、流程、資料搬移、通知方式、舊系統調整或後續維護；也要指出哪些工作仍由委託方或其他供應方負責。排除得越具體，越能避免把相鄰需求當成已包含的交付；若某項尚未決定，應列為待確認，不要默默歸入本次範圍。

例如，表單詢問分派流程可說明本次只處理新詢問的收件、分類與通知，不包含舊案件匯入、客戶資料清理、後續銷售追蹤或自動撰寫回覆。這些工作可能與流程相連，但是否納入需要另行確認；不能因為它們同樣使用表單資料，就推定也在原估價內。若希望保留擴充空間，可以描述未來可能接續的方向，但不要讓未來選項變成目前承諾。

還要分清楚交付物與使用者的日常工作。交付流程規格、設定項目或操作說明，不代表執行者代替團隊持續分類案件、維護資料或處理客訴。若委託方預期有人代操作，應另列頻率、責任角色和交接方式供雙方確認。使用外部表單、CRM或訊息服務也要標明由誰選擇、提供帳號並確認權限；它們是可能的工具選項，不因出現在文件裡就成為品牌自有服務。

每個排除項最好補一句何時需要重新估算。像是新增另一種表單來源、增加審核層級、要求匯入歷史資料，或要支援不同團隊的分派方式，都可能改變資料欄位、角色權限和例外處理。這不是拒絕延伸需求，而是指出工作範圍變動時要先更新規格、確認交付，再調整估算。如此可保留討論空間，也不會把未定義的工作混入原本的完成標準。

用邊界情境覆核

把正常案例寫完後，用邊界情境逐項檢查規格是否真的可執行。假設表單欄位缺漏、附件無法讀取、同一人重送，或送出後負責人暫時不在，逐一問：流程停在哪裡、誰會知道、資料是否保留、由誰採取下一步。若規格只能回答「系統處理」或「通知相關人員」，就補上可觀察的結果、接收角色和恢復條件，否則雙方無法判斷實作是否符合要求。

再檢查同一個邊界會不會有多種合理答案。重複詢問可能建立新案件，也可能併入既有案件；分類不明可能交由窗口選擇，也可能先放進待處理清單。選定答案前，先記下它對流程與估價的影響，交由有權決定的人確認。若無法立刻決定，將情境列為待確認，並說明暫定做法與答案改變時需要重新評估的部分。

可以用「情境、預期結果、負責角色、完成證據」做一張覆核表。假設情境是資料缺少聯絡方式，預期結果是案件不會直接指派給問題負責人，窗口能看到待補資料狀態，並知道要聯絡誰補件；完成證據可以是狀態紀錄或人工核對結果。這些都是規格例子，實際處理方式仍須由流程負責人確認，避免把假設情境誤寫成已部署的功能。

最後邀請實際執行者照著文件走一次，請他指出哪一步不知道看什麼、交給誰或如何確認完成。若兩位角色對同一個條件有不同解讀，就把規則改成明確選項並由負責人定案。規格可估價的標準不是字數多，而是不同讀者能否對起點、輸入、輸出、責任、例外和排除項得到一致理解。覆核後，將待確認事項、決定者與更新版本一併留下，作為後續估價和交接的依據。

下一步，挑一段流程，依本文六個問題各填一輪，再請實際操作的人覆核一次；需要討論流程需求時，可從 ZhenheAI 首頁 開始。