---
# System prepended metadata

title: 需求訪談/需求規格/工項管制表
tags: [看]

---

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

==理想很美好==
```graphviz
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"];
  
  "需求訪談
  (需求收集)"
  "需求訪談
  (需求收集)" -> 彙整分析規劃
  彙整分析規劃 -> 產出規格書與工項管制表
  產出規格書與工項管制表 -> 程式撰寫;    
  程式撰寫 -> 產出系統功能; 
}
```


==現實很殘酷== 
![https://imgur.com/a/9lkAXAU](https://i.imgur.com/yAwrcUO.png) 

<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>