拯救人生的軟體需求規格書

前陣子逛 FB 時看到 Udemy 上面這堂原價 7800 的課程 “How to write technical IT requirements to get what you need” 正在限時免費，剛好銜接看板方法不足的需求說明這塊，講師 Anca Onuta 是位非常有經驗的專案經理以及 Scrum Master，課程中同時以三種軟體產品：網站、Mobile App 以及聊天機器人為範例來說明需求文件該如何撰寫。

滿喜歡講師以邊口述邊打字的方式來進行授課，這樣的模式比較容易進入情境，聽不懂英文的的部分也還有重點可以看，雖然 Udemy 有自動字幕的功能，卻因為講師的口音而常常翻譯錯誤，邊聽邊看講師打下的筆記還比較容易理解些。

課堂中也有作業練習，講師也都會幫忙解決疑難雜症，或是想要開發的產品類型並未出現在課程之中，只要跟講師反應她都會再新增相關的範例，只能說現在線上課程好競爭，而 Udemy 更是常常有這種限免或是跳樓大拍賣的優惠，我自己就買了一堆根本沒時間看，只能乖乖找時間補上了～

推薦大家這個粉絲團–>https://www.facebook.com/softdevtools/，這邊常常都會有一堆免費課程的訊息，把他加到 FB 的搶先看就能隨時掌握最新的優惠課程資訊。

“How to write technical IT requirements to get what you need” 這堂課程主要分為八大單元，從介紹需求文件類型開始，到如何組織文件內容、工具介紹以及在撰寫文件時需要注意的問題都非常詳盡，以下就各單元做重點摘錄：

一、需求文件類型

商業需求文件：
描述整個商業計畫、商業目標、所需資源、商業模式等等商營營運各面相的文件，通常是企業經營階層需要的文件，如果是要自己新創事業也會需要。

產品需求文件：
描述特定產品的產品計畫、產品目標、產品規格，產品可能有很多個，每個產品都有自己的產品需求文件。

軟體需求文件：
描述產品內軟體的規格、功能、特色，也就是本課程主要介紹的需求文件。

用戶需求文件：
描述產品使用者的目標、使用行為，以設計出更友善的系統操作介面。

在介紹這些不同文件類型的時，講師有提到 Functionality 以及 Feature 這兩個容易令人搞混的名詞， Functionality 指的是介面背後的行為以及使用流程，是以比較宏觀角度來描述功能，而 Feature 指的是介面的互動方式，像是點擊按鈕改變字體大小，比較偏細部的具體操作步驟。

另外一個重點是，只有在軟體開發的領域時「產品需求文件」會等於「軟體需求文件」因為軟體即為產品本身。

二、將想法具體化成可執行項目的方法-草稿階段

High Level Vision – 把想法寫下來，並說明這些想法想要達成的目標
Scope – 透過哪些功能或內容來達成目標
User Journey – 描述每一個功能的使用步驟以及互動狀態，越細越好，包含顯示欄位、操作流程

下圖為講師示範以網站專案為範例的需求文件範本：

High Level Vision 是希望可以更容易接觸到客戶、讓客戶找到並瞭解公司的服務項目、並直接與客戶取得聯繫，Scope 則是根據以上目標來列出網站可以放的內容，像是產品或服務列表、團對介紹、顧客回饋、訓練課程以及研討會等等，

然後再逐一發展每個內容裡面的細項，像是團隊介紹裡面可以放團隊成員列表、大頭照、成員簡介，服務列表放入每個服務的名稱與說明，條列完成後，則是根據每個內容去定義的使用歷程，也就是 User Journey。

以訓練課程為例，其內容有免費預覽、付費觀賞、線上 QA 等內容，在 User Jourey 的部分則是去思考不同的使用者進入該區塊之後會有的操作，像是以新用戶來說，會先看到訓練課程列表 -> 預覽課程 -> 選擇他想上的課程 -> 付費 -> 取得付費課程 -> 提供小禮物 -> 感謝頁面或是其他課程推薦，而舊用戶也有相對應的操作流程，逐一把它列出。

在草稿階段，我自己做網站企劃的實務經驗，通常是先去爬數家競品網站以及同類型非競品網站後，畫下每個站的網站架構，以及紀錄特定行為的操作步驟流程，像是加入會員、購買商品等等，然後把這些蒐集好的資料做分類，最後把它匯集成客戶網站需求文件的草稿，客戶有了草稿後，再協助他們訂出 High Level Vison、 Scope 以及 User Journey，不然客戶常常也不知道做網站的目的是什麼，裡面要放什麼內容。

三、整理需求文件的工具

心智圖：這也是我最常用的發想工具，有時候還直接拿心智圖去跟客戶做討論，因為很方便可以看到全貌，也可以專注在細節，我是用 Xmind，講師分享的是 Coggle。
試算表：用 excel 或是 google 文件的試算表來整理草稿，方便的地方是可以進行排序，快速的找到要先進行開發的內容。
Word 文件：比較正式的需求文件，可以提交給客戶當交付物。

使用試算表的整理要點如下：

依照草稿區分 scope 裡面的頁面 / 內容 / 描述 / 顯示資訊 / 使用者歷程 / 技術需求 / 驗收標準 / 優先順序 / 重要性等等的欄位
依照草稿提到的內容來動態決定欄位，並整理成精準的文字
可以視覺化的顯示還有哪邊的內容有缺少
加入優先等級與重要性欄位，就可以使用排序功能優先顯示要開發的項目

下圖為講師的 excel 需求文件範例

先把 Scope 貼上，就成為 Page/Seciton 的項目，然後每個 Scope 裡面的內容，放在第二欄的 Content/Functionalities，其他欄位可以視需要新增刪減，

最後面三個欄位在開發上非常重要，驗收標準、優先度以及重要性，用 Excel 最大好處就是可以進行排序。

由於我有 Word 恐懼症，每次都會被他的排版給搞瘋，但如果是比較有規模且制度完善的公司，提交一份 Word 文件應該還是免不了的。整理邏輯跟 Excel 雷同，只是把欄位換成標題，然後把每個內容細項變成是清單目錄。

心智圖的整理方式較為直覺且不必擔心太多格式排版的問題。

四、需求文件的基本框架

1. Description 描述功能的用途、內容
列出 Pages 項目裡面應有的內容，以及進一步說明這些內容的欄位、互動功能會如何實現。

2. Action 功能操作的細節 ( User Journey )
需要使用者操作的步驟，像是輸入的資料欄位、資料驗證方式、發送電子郵件、如何取得登入授權。

3.Deliverable 該功能預期的產出物、交付物
完成這個 Page 應該會有哪些產出，像是加入會員的表單、註冊會員的頁面、忘記密碼功能等等。

**4.Acceptance Criteria 確認完成的標準
**如何說明這個 Page 或功能已經完成，像是會員可以成功登入、註冊帳號、可以使用忘記密碼功能收到密碼重設的連結。

課程提到的文件基本框架的部分我覺得是比較彈性的，可能依照 Scope 裡面 page 或 functionality 的不同而會有不一樣的欄位，但基本上離不開這四大範疇，第三與第四點實務上常忽略的地方，所以每次請客戶驗收時總是會發現自己漏掉頁面，或是工程師開發好的功能卻不是客戶需要的，這就是在前置溝通時期沒有對於完成標準有一致性的認知而造成的誤會，最後的結局總是只能苦命的打掉重做，所以好的需求文件規格書真的可以拯救人生啊。

五、需求文件的技術說明

描述開發這個產品需要的所有所以技術細節：

程式語言相關：像是使用什麼語言、程式面的特殊需求、可以擴充、方便移轉、需要支援哪些裝置等等
主機相關：主機規格、機房位置、備份機制、部署流程
第三方整合相關：需使用到的第三方 SDK 或是 API 介接
管理者相關：管理者權限、管理層級、可使用功能

這部分就是把想得到的技術細節寫下來，但常常會發生邊做邊產生新的技術應用，就要更新這份需求文件，常保這份文件保持在最新狀態是非常重要的。

六、法律要求

這是最容易被忽略但也最關鍵的部分，如果網站花了大筆時間人力開發，最後卻因為法律問題而導致必須下架，這會是非常嚴重的損失，所以一開始先了解相關的法律規定以及必須揭露的資訊，甚至是需要讓使用者同意的規範，這些都要在寫需求文件階段時一併考量進去。

七、撰寫需求文件的要點

整理需求通常會從草稿開始，然後整理成可以讓別人看得懂的文件，再透過溝通討論逐步發展出細節，有了細節後繪製 wireframe -> User Flow -> Prototype，可以更方便團隊成員理解產品的內容，但有一點要注意，在還沒有草稿階段時直接進入 wireframe 的繪製很容易會迷失方向，會拘泥在細節上而忘了整體目標，所以較好的作法還是先把 High Level Vision、Scope、User Journey 整理出來，wireframe 當成是輔助溝通的工具為佳。

此外，在整理正式文件的過程中，必須仔細選擇用字遣詞，確保團隊成員可以正確理解，減少假設性的問題，並寫下具體的說明跟解釋，搭配圖片的使用以及有系統的格式整理，在第一次發出這份文件時不要讓他們自己看，而是可以召開會議口頭解釋文件內的所有內容，確保團隊成員都能正確的理解進而減少誤會的產生。