常見的非功能性需求和應對方式

非功能性需求，指的是隱藏在功能需求背後以及開發需要考慮的的需求，也叫作“跨功能需求”。

工作這麼幾年來，見得最多的場景是 QA 小夥伴滿辦公室追着開發報 bug，有時候開發會不樂意，“當時可沒說要 XXX，要做 XXX。”

好像 QA 小夥伴永遠比開發多一點心眼，即使單元測試覆蓋率達到 80%，QA 還是變着法都能找出問題。

這其中很大一部分原因都來自於“需求背後的需求”，BA、QA 小夥伴以爲你考慮到了，或者默認開發需要考慮到。

比如 CMS 系統中一個新建文章的需求，不太可能寫出需要防止表單二次提交的 AC（Acceptance Criteria，驗收條件），然而如果沒人提出來誰會知道呢？

（最近很火的冰山圖）

最終 QA 或者線上的用戶會通過報 bug 告訴我們。

我們把這些隱藏在功能需求背後或 BA 默認認爲開發需要考慮的需求稱爲非功能性需求，有時候又叫跨功能需求。

下面就來說說在工作中常見的非功能性需求和應對方式。

一、交互體驗相關

Loading 加載狀態是最容易被忽略的一個需求，尤其是在現在富客戶端開發的模式下，數據的獲取都是異步加載的。如果忘了考慮這條需求，在網絡條件較好時會出現閃爍的情況，而在網絡情況差的條件下又看起來會卡頓和沒有響應。

實現統一的 Loading 可以在前端的網絡請求庫中增加攔截器，不過需要注意使用計數器讓多次網絡請求中途的 Loading 圖標不會間斷，否則會有閃爍的問題。

1. 表單的二次提交

有一些 QA 會使用極端的測試方法，例如快速點擊按鈕多次，如果頁面沒有進行處理，會觸發表單多次提交的問題。即使後端 API 增加限制則可能同時出現成功和失敗的提示，會讓用戶感到更加迷惑。處理這個問題有幾種途徑：

• 使用蒙層的 Loading 就會自帶阻塞用戶的操作的效果
• 點擊後禁用表單事件或在程序中增加請求中的狀態
• 依賴後端配置一次性表單令牌（通常用來防 CRSF）

2. 輸出格式化

需求中一般會告訴開發怎麼展示數據，但是往往會忘記如何格式化數據。

例如我們想讓數字使用千分位分隔或其他顯示方式，讓數字閱讀不那麼困難；字符串溢出的處理截取方式；時間的格式化方法，有一些項目會使用“一小時前”，“一天前”或者具體日期等更爲人性化的顯示方式；圖片的輸出需要寬度進行縮放，如果是封面圖需要非拉伸截取等。

3. 請求用戶確認和提示

這兩項專業 BA 一般都會考慮到，也會通知 UX 設計對應樣式。不過這裏面的細節還是值得討論。

• 如果在一系列操作的中途提示用戶確認，需要明確用戶點擊取消後，應該回退到用戶的哪一步操作狀態。有很多的 APP 在用戶編輯好數據後，點擊提交然後系統提示是否繼續，如果用戶點擊取消，頁面上的數據會被清除。開發需要和 BA 確認好具體的交互以及提示文案。
• 成功和錯誤的提示除了文案之外，和 BA 需要確認的還有：是獨立的提示頁還是返回到來源頁面？提示需要自動關閉還是等待頁面刷新後關閉？用戶可以主動點擊關閉嗎？

交互體驗這部分還有一個需求噩耗就是，保持統一！！！我想這個是交互體驗上最爲致命又不會寫在需求中，但是 QA 往往能從中找到 bug。

二、安全相關

1. 身份校驗和權限

URL 上資源可以被枚舉和請求的資源沒有驗證用戶權限，這屬於致命而低級的安全問題，當然 BA 會默認開發要去做這些。不過現實就是在一些遺留項目中這種例子太多了，例如通過修改 URL 上的資源 ID 甚至 userID 此類參數進而修改其他用戶的數據。

幾年前，可以發現很多此類漏洞，甚至在我學生時期用某電信運營商的權限漏洞得手了不少付費遊戲。如果系統設計了權限管理模塊，在開啓新功能時也應該和 BA 確認是否納入權限管理。

2. 表單驗證

用戶輸入的數據如何驗證這部分也是經常在需求上忘記體現出來的地方，而且這部分 QA特別容易給出 Bug，數據驗證充滿了大量的條件邊界。

還有一個老生常談的問題，表單驗證應該服務器端還是前端做？

這很顯然， 後端爲了安全必做，前端爲了體驗選做 。

3. SQL 注入和 XSS 攻擊

SQL 注入這兩年隨着成熟的 ORM 框架普遍使用幾乎沒有了，但是 XSS 可以說還是有很多。

處理 SQL 注入和 XSS 攻擊的共同點是不要相信任何用戶的輸入、任何來源。

在瀏覽器中用戶輸入不僅有表單還有 URL，而往往 URL 輸入參數很容易被數據校驗忽略。

4. 文件上傳

文件上傳背後的需求有上傳文件的類型、大小限制；需要和 BA 確認是否能批量上傳，上傳前是否需要預覽；上傳後如何命名，是否需要在上傳過程中對圖片或視頻進行壓縮。

這裏的安全需求是，不應該上傳可執行文件；需要獲取文件真實的類型信息而非後綴名。

文件上傳的一個陷阱就是使用了客戶端來源的文件名作爲文件存儲的文件名，這是極爲不可靠的，在上傳後的文件系統中需要使用內建的唯一命名，並通過數據庫來記錄用戶上傳的文件名。

三、性能相關

1. 響應時間

說實話，沒見過那張卡上有明確的指標那些功能需要在多久之內完成響應。但是如果不在分析業務需求的階段提出來，響應時間過長肯定通不過 QA 測試。在需求分析階段的響應時間包含了三個注意點：

• 系統性能設計要求。 對一般需求而言，技術上應該達到基本的性能指標，當然實現的方式不盡相同，例如優化 SQL、優化靜態資源等。
• 該功能是否適合同步操作。 然而有一些部分的需求是根本不適合使用同步的操作，例如數據導入這類耗時很長的操作，服務器應該接受用戶請求然後不斷返回任務處理的狀態，而不是讓用戶端等待完成。實現上可以使用一些消息系統，例如 JMS 等。
• 第三方系統集成。 如果和第三方系統集成，需要和資源提供方溝通是否需要增加批量的數據操作，避免循環獲取數據。例如 JSON API標準中提供了 include 方法聚合多個資源到一次請求中。另外調用方可以注意使用一些非阻塞的網絡請求方法，如 RxJava 或AsyncRestTemplate。

2. 實時消息通知

我們在做一些類似站內信、系統消息的功能時，有時候 BA、QA 容易默認消息的狀態和數量（小紅點）應該實時的顯示在頁面上，並及時更新。

但開發小夥伴可能認爲 web 上的一些信息需要用戶刷新後可見，這個很容易達成理解不一致。

如果實時刷新作爲需求確實需要的話，從技術上需要做一些調整才能實現，比如使用輪詢、HTTP 長連接、websock 等方法才能實現，這會帶來額外的工作量。

3. 遊離數據管理

從事服務器開發的小夥伴可能有這種體會，有一些數據一旦創建了，用戶或者管理員就沒法找到或者跟蹤了。比較明顯的例子有兩處：

• 新建資源處，異步上傳的圖片或者其他資源。比如在用戶操作新建文章頁面，這個時候文章表可能還沒有寫入數據，但是需要允許用戶上傳一些封面或者其他圖片。如果用戶體完成了整個操作，圖片會和文章關聯，但是假如用戶放棄了操作，圖片就會變成遊離狀態無法繼續管理，造成大量垃圾數據佔用系統資源。
• 刪除操作，沒有刪除一些關聯數據。例如商品表和商品屬性表關聯，如果刪除操作不是事務性的一起刪除，就會造成數據空間浪費，且可能影響後續的統計功能。

對於新建資源的圖片上傳，可以和 BA 溝通使用草稿的方式在用戶進入創建頁就完成數據插入操作，也可以設計一個圖片空間來提醒用戶使用已經上傳的圖片；對於刪除操作，系統不復雜可以設計爲數據庫表標記刪除，而不是真的刪除，也可以設計回收站功能統一移動到備份表。

4. 分佈式系統延遲

由於現在稍大的系統都是用了分佈式或微服務設計，系統之間存在系統存在同步延遲，比如數據庫主從同步，靜態資源服務器同步等。

在一些對文案要求比較嚴格的項目中一個隱藏的需求是，需要提醒當前的信息可能存在延遲，請稍後再試。或者前端增加定時刷新頁面的或者資源的回退策略。

在我經歷的一個項目中，上傳圖片成功返回圖片 URL 後，前端可能會延遲 2s 左右才能從正常打開圖片，因此需要增加 onload、onerror 進行重試或後續操作。

四、其他非功能性需求

1. 兼容性

瀏覽器兼容性是前端開發中頭疼的事情，從 IE6 到微信 webview，無論技術發展到哪個時代都逃不掉。那麼那些事情是需要和BA確認的呢？

• 各種瀏覽器內核具體的型號，而不是討論搜狗、360 這類殼瀏覽器。如果是 APP 內部的webview，這就需要收集相關安卓或 IOS 的版本號。
• 是否允許一定程度上的降級策略？比如在老式的安卓手機中大量的 CSS3 特性不支持，可能會造成動畫失效，是否我們可以不在老式的手機中要求過渡動畫等。

2. 升級策略

前端有兼容性問題，那麼服務器端就沒有了麼？

不幸的是如果 APP 不是同步發佈的話，API 的修改需要照顧老的客戶端。即使是同步發佈的 APP 很難強制用戶升級。在服務器端開發的時候保持一定兼容性的同時，更重要的是需要和 BA 一起設計出合理的升級方案。

我的經驗是設計API 時，需要在URI路徑中預留版本號，例如 V1/your-api/{id}。同時也需要增加契約測試來保證API 的修改不會破壞原來的邏輯。

3. 本地化和國際化

在一些國際化的項目中，這一點尤爲重要，不過有時候容易被忽略。

多語言和時區問題需要在項目之初就和 BA 確認，統一增加國際化方案。

而其他本地化則需要在每個功能上注意，例如日期、貨幣、單位、標點符號的輸出方式。

4. 用戶行爲分析埋點

越來越多的項目開始使用用戶的行爲分析工具了，例如 Google 的 Gtag 和更加專業的 dynatrace，使用這些工具會對系統造成一定的侵入性，需要對用戶的操作進行埋點。

如果項目有類似的需求，針對特定的功能很多用戶行爲分析的系統會提前定義一些標籤，那麼在開始一個新功能時需要確認用戶行爲分析的一些規則。

五、最後

寫作本篇的目的是分享在工作中開發在做一張卡背後需要考慮多少注意事項。在細節上想的越多，業務邏輯就會變得越完整，讓開發工作變得更爲順暢。

在參加公司某次培訓時，恰好也有很好的非功能性需求的課程，非常詳細，以至於長達數頁，但遺憾的是沒有非常詳細的解釋和應對方法。因此決定根據自己在工作中遇到過的場景作爲例子，給大家分享出來。

在敏捷團隊中一個痛點是我們很少有一個大而全的需求文檔，如果在開卡的時候有一些需求沒有被想到或者沒有在 AC 中體現出來，就需要反覆找 BA、UX 反覆確認。開發和 BA 溝通調整需求、交互的時候可能忘記知會 QA 或者 UX，或者沒有更新故事卡內容，就又會造成溝通的麻煩。

來源：https://mp.weixin.qq.com/s/jOJDd8Nn69DYeC_dpKpnVw

作者：林寧；公衆號： ThoughtWorks洞見

本文由@ThoughtWorks洞見 授權發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議

相關文章