---
lang: zh-tw
title: '需求訪談/需求規格/工項管制表'
tags: '看'
---
需求訪談/需求規格/工項管制表
===

==理想很美好==

digraph  {
  fontname="Helvetica,Arial,sans-serif"
  fontsize=20;	
  rankdir=LR; 
  node [fontname="Helvetica,Arial,sans-serif"]
  node [shape=box,style="filled",color="#9370DB",fillcolor="#ECECFF", fontcolor="#333"];
  
  "需求訪談
  (需求收集)"
  "需求訪談
  (需求收集)" -> 彙整分析規劃
  彙整分析規劃 -> 產出規格書與工項管制表
  產出規格書與工項管制表 -> 程式撰寫;    
  程式撰寫 -> 產出系統功能; 
}

==現實很殘酷==

<br>

:clock12: 需求訪談
---
- **需求訪談的精隨、核心是 : 積極主動理解、發現以及釐清真實的業務需求(想解決的問題/想達到的目標或目的)，過程中必須確認方向、框定範圍，並將其收集到足以彙整、分析、規劃出一個合適(必要、可行、正確、清楚、足夠)的解決方案(需求規格書)。**<div class="newline"></div>
- **需求訪談的過程中，不是只單純紀錄客戶所說得內容，同時必須從客戶傳達的部分事實情況，推敲出/挖掘出真實需求；有時候也必須**
- **進行說服 : 說服客戶往我們所期望的方向走、說服客戶不要無限上綱，框住在適當的需求範圍內**
- **給新點子 : 給客戶與原本不同的思考方向或處理方案**<div class="newline2"></div>
- 需求訪談紀錄的項目，它通常包括 : *( <span class="m">紅色粗體代表 ++**必要項目**++</span> )*
- **需求訪談紀錄表**
- <span class="m">系統名稱</span>
- <span class="m">受訪單位</span>
- <span class="m">主要目的</span>
- <span class="m">訪談對象</span>
- <span class="m">訪談日期 與 起訖時間</span>
- <span class="m">需求編號</span>
- <span class="m">訪談內容(需求/問題/期望描述、專有名詞定義、業務規則、限制、流程、參考資料...等)</span>
- 受訪人員確認簽章
- 訪談人員確認簽章
- **需求變更訪談紀錄表** : 變更除了異動的部分外，也要注意被影響的部分
- <span class="m">系統名稱</span>
- <span class="m">受訪單位</span>
- <span class="m">主要目的</span>
- <span class="m">訪談對象</span>
- <span class="m">訪談日期 與 起訖時間</span>
- <span class="m">對應需求編號 與 變更編號</span>
- <span class="m">訪談內容(需求/問題/期望描述、專有名詞定義、業務規則、限制、流程、參考資料...等變更)</span>
- 受訪人員確認簽章
- 訪談人員確認簽章<div class="newline2"></div>
- 實務中，在開發、測試、上線、維護階段是會產生需求的 :
雖然功能是依據規格開發，理論上應該是有滿足需求的，但是...很常在第一版需求功能出來後，又會從這版產生更多附加需求功能，當一遇到這種現象出現，一定要想這個功能有真的需要嗎?有需要作到這程度嗎?去跟客戶進行溝通、確認或說服，適時適度的達到止血的動作，不要產生無限上綱的現象。

<div class="newline2"></div>

::: info
[:memo: 1-1.需求訪談記錄表範本(docx)](https://www.geosmart.tw/docs/1-1.需求訪談記錄表範本.docx)
[:memo: 1-2.需求變更訪談紀錄表範本(docx)](https://www.geosmart.tw/docs/1-2.需求變更訪談紀錄表範本.docx)
:::

<br><br><br>

:clock3: 需求規格
---
- **需求規格書是依據需求訪談所收集/挖掘的資訊進行彙整、分析、規劃出一個合適(必要、可行、正確、清楚、足夠)的解決方案**<div class="newline"></div>
- **一定先規劃出系統整體的功能，並使用功能架構圖及功能描述(表列或條列都可以)，讓大家可以清楚的知道系統全部有哪些功能、功能之間的關係以及功能大概在做什事。**<div class="newline"></div>
- 需求規格書的項目，它通常包括 : *( <span class="m">紅色粗體代表 ++**必要項目**++</span>、<span class="c">綠色粗體代表 ++**條件項目**++</span> )*
- <span class="m">系統名稱</span>
- <span class="m">ISMS編號</span>
- 填 ISMS 程式新增/異動申請單流水編號
- <span class="c">功能編號</span>
- 填管制表項目編號，如果「 二. 功能描述/說明」 所規劃的功能有上層功能，這裡填上層項目編號
- <span class="c">功能名稱</span>
- 填管制表項目名稱，如果「 二. 功能描述/說明」 所規劃的功能有上層功能，這裡填上層項目名稱
- <span class="c">功能描述/說明</span>
- 填功能的描述/說明，如果「 二. 功能描述/說明」 所規劃的功能有上層功能，這裡填上層功能的描述/說明
- 附加說明
- <span class="m">作者</span>
- <span class="m">建立日期</span>
- <span class="m">規格負責人</span>
- 確認規格人員(Key User)
- 驗收負責人
---
- <span class="m">++**功能目的**++</span>
- <span class="m">++**功能描述/說明**++</span>
- 一個功能或多個相關功能清單，填寫內容包含 : 項目編號、項目名稱、描述/說明
| 功能編號 | 功能名稱 | 功能描述/說明 |
| --------------- | --------------- | ----------------------- |
| *填管制表項目編號* | *填管制表項目名稱* | |
- <span class="m">++**處理過程**++</span>
內容會包含以下資訊，並依狀況將它們套用到所規劃的功能或使用情境中：
- 處理的 **資料** (欄位)，定義與之間的關係
- **畫面** 所要呈現的資料、排版與將提供的互動方式
- 必須遵守的 **規則** 、 **限制** (大多是程度上的限制)
- 必須遵守的 **流程** (包含邏輯、步驟)
- ++**性能需求**++
- 例如 : 頁面載入時間限制、搜尋的時間限制…等。
- ++**安全需求**++
- 例如 : 驗證授權機制、用戶資料的加密、防止資料竄改、防止SQL injection…等。
- ++**相關附件**++
- 客戶確認簽章
- 規劃人員確認簽章<div class="newline2"></div>
- 需求規格中所規劃的功能，必須是**滿足需求**，**規劃出具必要性、可行性的功能**。<div class="newline"></div>
- 需求規格中表達的方式除了一般使用得**純文字描述**外，可配合使用 **條例式**、**圖形或表格**來呈現，讓所規劃資訊更**正確**、**清楚**、**足夠**得被表達，更重要得是讓 客戶與 <font class="pg">PG</font> 看得懂這份文件，實務上還是要再搭配面對面口頭的說明與溝通。<div class="newline"></div>
- **需求規格開好後，非常建議可以使用情境模擬（使用者故事）的方式來協助自己確認規格是否明確，就想像使用自己所開的規格，是否可以正確且順利的模擬各種所規劃的使用情境。**

<div class="newline2"></div>

::: info
[:memo: <code class="red" style="background-color: transparent !important;">**2-1.需求規格書範本(docx)**</code>](https://docs.google.com/document/d/1zWZbc_mQ1nKFVWFBI4wY_XoYG4Sgdtkc/edit?usp=share_link&ouid=114427043985348386648&rtpof=true&sd=true)
:::

<br><br><br>

:clock6: 工項管制表
---
- **工項管制表是有助於開發進度管控，避免事情都擠到後面做，也讓執行進度透明化**<div class="newline"></div>
- 工項管制表的項目，它通常包括 : *( <span class="m">紅色粗體代表 ++**必要項目**++</span> )*
- <span class="m">系統標的</span>
- <span class="m">項目編號</span>
- <span class="m">狀態</span>
- 功能或單元名稱，由專案處負責人定義，搭配所要提供技術處的需求規格文件
- <span class="m">項目名稱</span>
- <span class="m">需求來源</span>
- 基本來源 :
- RFP(專案需求)
- 需求訪談
- 會議要求
- Key User提出
- <span class="m">需求類型</span>
- 主要是定義工項的處理方式 :
- ISMS(專案期程需完成的工項)
- None(不外顯or不需要)
- Maintain(須視專案需求採取維護單處理的工項)
- <span class="m">需求規格</span>
- 放URL(檔案在公司雲端硬碟)或註明以檔案提供技術處
- <span class="m">ISMS申請單</span>
- 寫編號加超連結
- Key User
- 負責此項目的特定客戶
- <span class="m">專案處提出日期</span>
- <span class="m">希望完成日期</span>
- 契約明訂，或答應客戶日期，專案處負責人需以此回推各作業時間
- <span class="m">契約要求交付日期</span>
- 契約明訂，或答應客戶日期，專案處負責人需以此回推各作業時間
- <span class="m">實際完成日</span>
- 已完成：專案處負責人確認完成
- 已結案：ISMS單結束
- <span class="m">開發優先順序</span>
- 希望技術處進行的順序，或是已與技術處討論後的順序
- M-Day
- 是工程師所估的工時 : 是與工程師討論後估出來的 M-Day ，以利後續用這工時來判讀工項先後順序的調整依據。
- 技術處負責工程師
<div class="newline2"></div>

::: info
[:memo: <code class="red" style="background-color: transparent !important;">**2-2.專案工項管制表範本(xlsx)**</code>](https://docs.google.com/spreadsheets/d/10DSZILg9lxg36IaD28rxiUe6n7uU-V0B/edit?usp=share_link&ouid=114427043985348386648&rtpof=true&sd=true)
:::

<br><br><br>

:link: 參考
---

<br><br><br><br><br><br>

<style>
/*- RFP
- LINE
- Meeting
- File
- Other*/
code.red {
color: #e91e63 !important;
font-size: 1.6rem !important;
/*background-color:#FFFFBB !important;*/
}
code.blackred{
color:#900000 !important;
font-size: 1.6rem !important;
}
code.blue {
color: #337AB7 !important;
font-size: 1.6rem !important;
}
code.orange {
color: #F7A004 !important;
font-size: 1.6rem !important;
}
font.pm{
color: #bd0000 !important;
}
font.pg{
color: #006700 !important;
}
.newline{
height:1rem;
}
.newline{
height:1rem;
}
.newline15{
height:1.5rem;
}
.newline2{
height:2rem;
}
/*「必要項目」（Mandatory，M）*/
.m{
color: #ff0000;
/*background-color: #3b82f621;*/
font-weight: bold;
}
/*「條件項目」（Conditional，C）*/
.c{
color:#017601;
/*background-color: #3b82f621;*/
font-weight: bold;
}
/*「選擇項目」（Optional，O）*/
.o{
color:#ff8100;
/*background-color: #3b82f621;*/
font-weight: bold;
}
</style>