編輯導語：西安一碼通連續崩潰，除了軟件開發方有責任，產品經理也需要寫清楚要求，否則很有可能“背鍋”。本篇文章中，作者分析和解答了產品經理如何定義清楚一碼通的非功能需求，以及如何寫文檔才能不背鍋等等問題，推薦想要學習如何寫一碼通功能需求的群體閱讀。

2022年1 月 4 日9 時，西安一碼通又崩潰了。這是半個月內，一碼通第二次出現故障。

一方面，軟件開發方有責任，開發的系統可用性太差。而另一方面，軟件的需求方也需寫清楚要求，這也往往是產品經理的工作，具體而言就是定義清楚產品需求、驗收標準、違約責任。

否則研發只需一句話——“是產品經理沒有定義清楚需求，所以責任不在我”，這就可將責任推掉。而我們如做好這些工作，就能分清責任，明確義務，避免背鍋。

這些工作涉及面很廣，本文僅探討其中的非功能需求的部分，也就是產品經理如何定義清楚一碼通的非功能需求。

一碼通的功能需求很簡單，就是查詢自己的核算檢測信息，個人健康信息。難是難在了非功能需求，下面我們就用3000字來逐一說明。

一、需求的全貌

產品經理要明確的需求眾多，在我的書《圖解產品》中，我將這些需求做了歸類，并命名為PURPS+模型，具體就是：

• 主要需求（Primary）：體現了功能、內容、安全性需求；
• 可用性需求（Usability）：體現了用戶體驗、幫助和培訓文檔等需求；
• 可靠性需求（Reliability）：體現了故障率，維修時間等需求；
• 性能需求（Performance）：體現了響應時間、并發數、吞吐量等需求；
• 可支持性需求（Supportability）：體現了可維護性、可擴展性等需求；
• 其他需求（+）：如數據統計、授權、接口、包裝等需求。

而產品經理需逐一定義這些需求，才能將文檔寫全面。下面我們重點說說其中的可用性、可靠性、性能和可支持性需求如何寫，這些內容在《圖解產品》中有更多說明。

二、可靠性需求

可靠性定義了系統的健壯性，如可靠性高則說明產品的軟件、硬件故障少，能正常運行。而這些故障常常會嚴重影響用戶的使用。

具體到西安一碼通則需定義清楚四個指標，分別是：平均無故障時間 （MTBF）、可靠性、維護響應時間、平均維護時間。

（1）平均無故障時間 （MTBF）

該時間是指產品出現一次故障的平均時間。如電腦的MTBF 為 15 年， 就是說有的電腦第 1 年出故障，有的電腦第 30 年出故障，平均算起來第15 年出故障。一般可用經驗數據和實驗數據，大致預估硬件的MTBF。

而軟件的故障多是因為軟件BUG，因此很難預估MTBF值，有時會給個承諾值。

（2）可靠性

軟件的故障次數越少越好，但如不幸出現了故障，則希望有故障的時間盡可能短，這個指標就是可靠性。

如可靠性為99.999%，就是指在1年時間里，該業務會中斷5.26分鐘，計算公式為（1-99.999%）× 365 × 24 × 60，其中365 × 24 × 60為全年的分鐘數。

同樣該值也較難預估，慣例是廠商會承諾99.99%或99.999%的可靠性。

（3）維護響應時間和平均維護時間

當產品出現故障后，很多時候要維修，而維修包括維護響應時間、平均維護時間。

（4）維護響應時間

是指從發現故障到開始維修所需要的時間。對于西安一碼通業務來說，可要求開發方支持7×24小時的隨時響應，并要求10分鐘內開始維修。

（5）平均維護時間 （MTTR）

雖然開發方能夠快速響應，但是要修好還需時間，由此需要定義平均維護時間，這個時間包括在途時間（如需要）和到達現場維修好的時間。該指標也需要根據業務情況定義，如要求必須1小時內修好。

以上就是平均無故障時間 （MTBF）、可靠性、維護響應時間、平均維護時間指標的定義和建議值。這些值多數無法精準給出，更多地是開發方對可靠性的一個承諾。

三、可用性需求

可靠性是從系統角度看的，也就是反應了軟件有沒有問題；而可用性則是從人的角度看的，也就是人覺得產品可用不可用。有時兩者是一回事，但有時兩者不是一回事。

之前我曾負責的一款產品，其可靠性很差，硬件和軟件總出問題。但是有些情況下卻不太影響用戶的使用，因為用戶大不了重新撥打一次電話，或重新連一次網絡，也能用。

而所采取的手段是，當疑似有問題后，該系統會自動重啟系統或重啟某進程。所以從用戶的角度看，其可用性尚可；但從系統角度看，其可靠性很差，系統總是壞掉。

現在的互聯網系統也多是分布式部署，從而將單點故障的影響降到最低，提升用戶的可用性。

而西安一碼通也需定義清楚可用性。如當軟件、硬件出現故障后，系統應盡可能支持一定的恢復手段，同時也要實現分布式部署等。

但從本次一碼通的故障看，主要是性能問題，此時靠重啟進程等手段是不能解決問題的，由此需要定義清楚性能需求。

四、性能需求

性能需求要先定義用戶訪問情況，再定義系統的響應時間、新建數、并發數、吞吐量。

1. 用戶訪問情況

用戶訪問情況需確認峰值訪問量、平均訪問量和訪問的業務。對于一碼通業務，需依據歷史數據做預估。如預估每日10點-11點為峰值訪問，且同時使用的人數是多少人，并應盡可能精確到每秒的峰值。

2. 響應時間、新建數、并發數和吞吐量

定義清楚了用戶訪問情況后，就要再從軟件角度定義性能指標，如能定義清楚這些指標，就可避免不合適的軟件架構設計，這些指標如下。

（1）響應時間

指標反映了網站響應用戶請求的速度，也就是我們日常所說的網絡快慢。影響響應時間的因素有系統延遲、網絡延遲和用戶端的延遲，一般可由開發方給個響應時間。

（2）新建數

每個用戶使用一碼通查看信息時，系統都會新建建立一個連接。該指標與用戶訪問指標比較類似。比如登錄要新建、查詢要新建，這就是兩個新建。有時一次查詢需要幾個新建，需由研發確認。

（3）并發數

定義了當訪問系統的特定應用時，能同時維持的連接數量。據統計西安有1300萬人口，按照最大10%的市民同時掃碼（已經很大了），也就是要支持百萬的并發量。

（4）吞吐量

該系統定義清楚吞吐量，很多性能問題就可避免。

按照一些研發的分析，認為一碼通的問題集中在該系統所有的 js/css/img 靜態資源全都從一個出口進行提供，沒上 CDN。

粗略估算了一下，js/css/img 數據總共約 500kB。而按照某個群里得到的數據（暫且認為是準的），健康碼的請求量峰值達到了 3.3w qps，也就是吞吐量要 33000 x 500 x 8 bps ≈ 125Gbps 這個出口量級很難用單機房承載，由此系統掛掉。

該指標和系統實現方案有密切關系，需要由經驗豐富的研發來分析、明確。

五、可維護性需求

可維護性需求可分為可支持性需求和可移植性需求。這些需求涵蓋的內容較多，與一碼通相關度高的需求如下：

（1）可支持性需求

定義了開發人員是否可以方便地升級系統、用戶是否可以很方便地升級。

而據每日經濟新聞報道，一碼通的升級需要人工刪除小程序，并清除數據。這就是沒有做好可支持性需求。

（2）可移植性需求

括用戶的增長和數據量的增長。用戶量的增長是指當用戶量增加后，系統應能方便地擴容。數據量的增長是指當存儲的數量增加后，系統也能很好地支持。而一碼通半個月后又出故障，由此可看出其可移植性需求做的并不好。

六、總結

以上就是一碼通需定義的主要非功能需求，而這些需求涵蓋面又廣又重要。除了這些指標外，還有一些次要需求，本文就不再贅述，你可參考《圖解產品》繼續完善。

其實該系統的實現不算難，實現方案也頗為成熟，甚至優秀的應屆生都能搞定，確實不該出問題。

有人可能會問，工作中我沒有定義這些內容，研發一樣工作。是的，對于互聯網公司的自研產品多數不需這么詳細，但對于這種關系民生的定制開發則必須明確，從而避免上線失敗。

如一些實現細節不清楚，需求方也可列出框架，由開發方填寫。

而需求方還應基于以上指標，再定義驗收標準，違約責任，并進行壓力測試，由此來約束開發方的行為。這樣開發方就不至于敢派經驗不足的研發來應付事，更可避免扯皮，分清責任。

#專欄作家#

擎蒼，微信公眾號：圖解產品設計，人人都是產品經理專欄作家?！秷D解產品》作者。專注B端產品，擅長UML建模、領域建模；專注企業數字化，有多個明星數字化產品構建經驗；另有多年產品經理、企業數字化企培經驗。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議