別忘了先決定「要幾秒才滿意」── 用 IPA「非功能要求分級」整理非功能需求

「客戶反映畫面切換太慢，但合約書和規格書裡都沒有約定回應時間」

「夜間批次作業變得無法在早上前完成，但當初誰也沒有估算過資料量會以多快的速度增加」

「伺服器故障導致系統停擺半天，這時才發現，發包當時根本沒有確認過『用現有架構，幾小時內能夠復原』」

提到系統開發的糾紛，大家往往先想到的是功能認知上的落差，但實際上系統開始運作之後真正引發糾紛的，往往是這類功能以外的需求──也就是所謂的非功能需求──被遺忘而沒有事先決定。

為了防止這種遺漏而存在的官方工具，就是 IPA（獨立行政法人資訊處理推進機構）的非功能要求分級。本文將用發包方也能理解的語言，整理其具體內容，以及在中小企業業務系統中現實可行的使用方法。

1. 先講結論

• 非功能需求指的不是「要做什麼」，而是「要以怎樣的品質・條件運作」的需求。依 IPA 的分類，可歸納為可用性、效能・擴充性、維運・維護性、遷移性、安全性、系統環境・生態這六大項目
• 非功能要求分級，是 IPA 提供的一套（免費）工具，將這六大項目的需求項目做成完整清單，讓發包方與開發方以0 到最高 5 級的六個階段逐項達成一致。實際的等級定義摘錄於 3.1 節
• 不需要填滿全部項目。其設想的使用方式，是先選擇與自家公司相近的「模型系統」，再從重要項目開始，依自家實際情況逐一調整
• 非功能的等級愈高，費用也愈高。不應「憑感覺要求高水準」，而應從業務影響倒推，選擇合適的等級
• 決定的結果要寫入需求定義文件。這裡確定的前提，有助於比較報價，也能在系統開始運作後防止「有說・沒說」之類的爭執

2. 什麼是非功能需求 ── 介於「能動」與「能用」之間的東西

功能需求指的是「能夠登錄訂單」「能夠列印報表」這類系統要做什麼的需求。開發討論自然而然會集中在這類話題上。

另一方面，以下這些問題不會出現在功能清單裡。

• 這套系統需要從幾點運作到幾點？週末呢？夜間批次作業期間呢？
• 故障停機時，必須在幾小時內復原，業務才不會停擺？資料復原到哪個時間點為止是可以接受的？
• 會有多少人同時使用，一天要處理多少筆？5 年後資料量會增加到多少？
• 由誰負責監控、備份，以及在故障發生時第一時間接到通報？
• 舊系統的資料，要延續到新系統的哪個範圍？

這些就是非功能需求。麻煩的是，即使沒有事先決定，系統也大致上「能動」。問題往往要到系統開始運作、負載增加、發生故障之後才會浮現出來。而到了那個階段，因為牽涉到伺服器架構與設計的根本，要修正就得付出很大的成本。

3. 什麼是非功能要求分級

非功能要求分級，是 IPA 為了防止發包方與開發方在非功能需求上出現認知落差而公開的一套工具。初版於 2010 年 4 月公開，目前最新版本是反映了安全性與虛擬化（雲端）相關變化的「非功能要求分級 2018」（2018 年 4 月公開）。目前它被收錄在 IPA 網站的封存頁面中，但作為檢查非功能需求有無遺漏的基準，在實務上至今仍是常用的標準做法。

其內容由以下這些工具構成。

每一項指標都定義了分階段的等級選項，其特點在於，可以用「選擇某個等級」的方式來表達需求，而不必依賴「高／低」這類含糊的說法。

3.1. 等級是什麼 ── 來看看分級表的實物

光說「分階段的等級」不容易有具體概念，這裡就來看看實物。等級是0 到最高 5 級的六個階段，數字愈大，實現的難度愈高，一般開發・維運的成本也愈高。不過並非所有指標都有六個階段，也有一些項目只有 3 個選項（0～2）。

例如可用性的第一個項目「運作時間（一般）」（項目編號 A.1.1.1）定義如下。括號內的時間僅為範例，並非選定等級的條件本身。

「希望我們的系統能 24 小時運作」這種模糊的期望，在這張表上就會變成「選擇等級 5」這個具體的選擇。而選擇的當下，也能同時看見輪班人員與備援架構的費用會隨之而來。

再來看另一個發包方容易用數字來理解的項目——「運轉率」（項目編號 A.1.5.1）。分級表的備註中，甚至寫出了各等級對應的年度停機時間參考值。

你可能會覺得「99% 和 99.9% 幾乎一樣吧」，但從年度停機時間來看，87.6 小時和 8.76 小時，是整整 1 天與不到半天的差別。非功能要求分級真正的效果，就在於把「用語言表達很接近，但業務影響差 10 倍」這件事，用數字並排展示出來。

此外，分級表中也已經預先填好了各模型系統對應的參考等級。以上述兩個項目為例，內容如下。

以最接近自家公司的模型欄位為出發點，「因為我們有夜間批次作業，所以要再高一級」「相對地運轉率不需要到這麼高」，這樣逐項上下調整——這就是分級表的使用方法。

3.2. 三種模型系統

另一個特點，是依系統停機時對社會造成的影響大小，劃分出的三種模型系統。

• 幾乎沒有社會影響的系統
• 社會影響有限的系統（如企業核心系統等）
• 社會影響極大的系統（如社會基礎設施等）

分級表中已預先填好各模型對應的參考等級。也就是說，不必從零開始討論，而是可以先大致判斷「我們接近這個模型」，再依實際情況上下調整。

4. 六大項目 ── 翻譯成發包方的語言

把非功能要求分級的六大項目，換成發包方能夠回答的問題，大致如下。

這樣看下來就會發現，六大項目中的大部分並不是技術問題，而是業務問題。能夠回答「如果月底的請款作業延遲半天會發生什麼事」的，不是開發公司，而是發包方。非功能需求的主導權，其實掌握在發包方手中。

5. 現實可行的使用方法 ── 不要試圖填滿 238 個項目

項目一覽表中共有 238 項指標，但對中小企業的案件而言，逐一討論全部指標並不現實，使用指南本身也沒有假定這樣的用法。設想的流程如下。

1. 選擇模型系統
   （自家系統接近哪種影響程度）
        ↓
2. 針對分級表中的重要項目，
   以模型的參考等級為出發點，依自家實際情況調整
        ↓
3. 只對必要的部分，用項目一覽表做進一步細化

若是中小企業的業務應用程式，光是步驟 2 的「重要項目達成共識」，效果就已經足夠。根據經驗，我們建議至少把以下幾點寫入需求定義文件。請注意，開頭列舉的三個案例，都是因為跳過了這張表裡的某個環節才發生的。

這時不能忘記的是等級與成本之間的取捨。舉例來說，若追求「絕對不會停機的系統」，伺服器的備援化與監控體制會讓費用急遽上升。若能判斷「只要業務能撐到隔天早上，當天內復原就足夠」，就可以把這部分預算用到別處。非功能要求分級的等級，不該被當作提高要求的工具，而應作為討論業務影響與費用平衡的共通語言來使用，這才是恰當的距離感。

6. 與合約・報價的關係

非功能需求，也與合約直接相關。

首先是報價的比較。若沒有先統一非功能方面的前提就向多家公司詢價，A 公司可能是按備援架構報價，B 公司則可能只按一台伺服器報價。這樣一來，發包方就無法判斷金額的差異究竟來自架構的不同，還是估算過於樂觀。

其次是驗收以及開始運作之後。若回應時間與備份的約定已寫入文件，「太慢」「超出預期」這類各說各話的爭論，就會轉變為對照基準的事實確認。

IPA 的「資訊系統・模式交易・契約書」中，也把非功能需求視為需求定義階段的交付物之一，設想加以文件化。在「需求定義以準委任方式進行，待內容確定後再以承攬方式簽訂開發合約」這種多階段合約流程中，非功能要求分級可以很自然地融入其中。關於合約的具體形式，請參閱IPA「模式交易・契約書」解說文章。

總結

整理一下 IPA「非功能要求分級」的重點。

• 非功能需求是「要以怎樣的品質・條件運作」的需求。不決定也能動，但會在系統開始運作後浮現並引發爭議
• 非功能要求分級，是 IPA 提供的免費工具，用分階段的等級，讓可用性、效能・擴充性、維運・維護性、遷移性、安全性、系統環境・生態這六大項目、238 項指標逐項達成共識
• 等級是 0 到最高 5 級的六個階段。以運轉率為例，99%（年停機 87.6 小時）是等級 2，99.99%（年停機 52.6 分鐘）是等級 4，像這樣，用語言表達很接近的需求差異，會用數字並排呈現出來（第 3 章）
• 以三種模型系統的參考等級為出發點，從重要項目開始調整。不需要填滿全部項目
• 六大項目的內容大多是業務問題，掌握答案的是發包方
• 等級愈高，費用也愈高。應從業務影響倒推，選擇合適的平衡點，並把結果寫入需求定義文件

和「要做什麼」同樣重要的是，先決定好「要以怎樣的品質持續運作」。這是預防能動卻不好用的系統、以及後續爭議，最省成本的方法。

參考連結

非功能要求分級收錄在 IPA 網站的封存頁面中，用搜尋不容易找到，這裡附上直接連結。全部都是免費的，透過使用條件頁面下載。

• 系統建置上游工程強化（非功能要求分級） ─ IPA 封存區內的入口頁面，可從這裡連結到各項資料
• 非功能要求分級 介紹頁面 ─ 說明工具組成，以及從選定模型系統到決定重要項目等級的使用步驟
• 非功能要求分級本體（日文版）使用條件 ─ 可下載使用指南（解說篇・使用篇・活用篇）、分級表、項目一覽表、樹狀圖、活用表（Excel）全套資料。應該優先下載的就是這個
• 非功能要求分級 2018 使用指南「活用篇」第 2 版 使用條件 ─ 2019 年 3 月修訂的活用篇
• 非功能要求分級研習教材 使用條件 ─ 可用於公司內部讀書會的整套教材
• 資訊系統・模式交易・契約書 ─ 第 6 章提到的、探討契約與需求定義關係的 IPA 資料

本文第 3 章引用的等級定義與年度停機時間參考值，依據的是上述「本體（日文版）」中所含的活用表（項目編號 A.1.1.1「運作時間（一般）」以及 A.1.5.1「運轉率」）。

給正為業務系統需求整理所困擾的您

梳理非功能需求，需要在業務的實際情況（尖峰時期、資料量、停機時的影響）與實現這些要求的系統架構之間反覆權衡。

合同會社小村軟體在承接 Windows 業務應用程式與 Web 系統的委託開發・改造諮詢時，會依照本文介紹的思路，在需求階段就一起整理效能・維運・故障時的行為表現。即使您目前還處於「現有系統的處理速度逐漸變慢」「想趁更新的機會重新檢視維運方面的約定」這樣的階段，也歡迎隨時洽詢。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

什麼是非功能需求？

這是系統「要做什麼」（功能需求）以外，關於「要以怎樣的品質・條件運作」的需求。例如，系統要在什麼時候能夠使用（可用性）、多少人使用、幾秒內回應（效能・擴充性）、由誰以什麼方式維運・維護（維運・維護性）、如何從舊系統延續資料（遷移性）、要有哪些防護（安全性）、要安裝在什麼環境中（系統環境）等都屬於此類。若忘記事先決定，就容易變成「能動卻不好用」的系統。

非功能要求分級可以免費使用嗎？在哪裡可以取得？

可以從 IPA 的網站免費下載。內容包含分級表・項目一覽表・樹狀圖・活用表，以及使用指南（解說篇・使用篇・活用篇），最新版本是 2018 年 4 月公開的「非功能要求分級 2018」。目前收錄在 IPA 網站的封存頁面中，但作為確認非功能需求有無遺漏的基準，在實務上至今仍被廣泛使用。

238 個項目全部都必須決定嗎？

不需要。使用指南本身也沒有假定要逐一討論全部指標。它示範的是一種分階段的使用方法：先選擇與自家公司相近的模型系統，決定整體的參考標準，再以分級表中的重要項目為中心，依自家實際情況調整，只在必要範圍內用項目一覽表做進一步細化。若是中小企業的業務系統，光是重要項目達成共識，就能防止大部分「因忘記決定而引發的爭議」。

非功能需求應該什麼時候決定？

是在需求定義的階段。可用性與效能的目標，關係到伺服器架構與設計的根本，一旦開發進行到一定階段後再變更，會對費用與工期造成很大影響。IPA 的「資訊系統・模式交易・契約書」中，也將非功能需求（而不只是功能需求）視為需求定義的交付物之一，設想加以文件化。若在比較報價的階段沒有先統一非功能方面的前提，就會無法判斷金額的差異究竟是架構上的不同，還是估算過於樂觀。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。