我們在審批case的時候，最容易忽略的部分就是非功能性需求。非功能性需求分析不透徹，或者被忽略，常常給專案埋下巨大無比的坑。這個坑，想必大家都或多或少遇到過吧。比如專案要交付的時候，互動或需求不明確或者有歧義導致專案返工或延期，安全問題考慮不周導致生產環節被攻擊者惡意攻擊，沒有考慮效能導致遇到高流量的時候就悲劇了等場景。今天的話題，我們就來聊聊《非功能性需求，不要成為專案的坑》。
原文地址：非功能性需求，不要成為專案的坑
部落格地址：blog.720ui.com/
易用性需求
顧名思義，使用者在使用過程中易理解，易操作等。頁面描述要清晰，最高境界就是“零手冊”，不能讓使用者理解有歧義，此外，一致性也是很重要的，比如輸入內容校驗規則，頁面展示風格，類似模組的互動等等。比如，一個系統，有的地方是用瀑布式風格，有的地方使用正常的分頁，在頁面展示上就會有點奇怪，不是麼？
頁面互動
換句話說，就是頁面互動中我們需要確認的一些常常容易忽略的問題。這裡面的坑太多了，我舉幾個案例作為引子，希望引起大家的注意。
案例一 有效性校驗
有效性校驗，有什麼特別之處麼，我們正常都會考慮到的 ? 我想說“Are you sure？”，我們來看看下面兩個場景。
首先，看看新浪微博的釋出文章功能，並不是我們理解的所有中文，字母，數字，符合分別都算1個字喲，這裡的2個數字才算1個字。所以，我們的產品中有存在這種場景，就需要和策劃/需求人員確認清楚規則，而不是想當然咯。
然後，我們再看看微信公眾號釋出文章功能，正文內容限制是2萬字，超過2萬字就不讓提交了。這也是一個非功能性需求，需要和策劃/需求人員確認清楚文章字數限制，如果他們說希望無窮大，然後你答應了，請挖好坑把自己埋了吧。
案例二 潛在預設值規則
很多情況下，存在如果不填寫會設定預設值的場景，此時你要確認清楚具體的預設值規則。比如，釋出一個應用，預設是下架還是上架狀態？設定權重，是否有預設值場景？再比如，文章摘要的場景也是一個很好的例子。微信公眾號，摘要的規則就是如果不填寫會預設抓取正文前54個字。
案例三 註冊使用者與遊客使用者的區分
如果是遊客使用者，下面的收藏、評論、點贊，互動場景如何呢?是遮蔽讓遊客使用者無法看到，還是置灰禁止操作，還是彈出登入頁面，讓使用者註冊或者登陸。
功能邏輯
功能邏輯，也是一個很經常考慮的問題。這裡面的坑也很多，我舉幾個案例，看看是否引起大家的共鳴。
案例一 涉及自身
比如，生日祝福功能，是否可以給自己祝福呢? 關注使用者功能，可以不可以關注自己哈？這些都是需要考慮的，雖然從產品的角度而言沒太大問題，但是從使用的角度，就存在一定的業務問題。
案例二 敏感資訊
比如，服務端傳送訊息給客戶端，如果單單從客戶端的角度進行敏感資訊的過濾，安全性上面就存在很大的風險。之前，我抓包分析過一些產品的介面資料，有的產品介面層面沒有做遮蔽，只是簡單的在頁面加”*“符號替換，當然這些資訊，被一覽無餘。
可靠性需求
例如，是否考慮容錯性，是否考慮灰度環境，是否服務降級，是否考慮故障轉移等。
相容性需求
Web端是否考慮相容市面上主流瀏覽器，比如是否需要相容IE8、IE9，這也是比較頭大的問題，需要一開始就要確認清楚，而不是開發過程中再去考慮。因為，IE8、IE9涉及技術選型上的問題，比如是否要用HTML5，跨域問題要如何處理，需要採用什麼框架，是使用原生的方式，還是使用單頁面框架React/Vue？
Android端，需要相容哪些主流版本，4.x? 5.x? 6.x? 需要考慮哪些裝置等。
效能需求
效能需求，也是一個非常重要的非功能性需求。簡單的理解，效能就是在空間和時間資源有限的條件下，軟體系統工作的如何？系統效能需求，有幾個典型的指標：響應時間，併發使用者數，TPS，資源利用率等。
試想，如果是電商系統，我們不去考慮效能，那麼生產環境遇到稍微高一些的併發場景，伺服器可能就奔潰了。
此外，業務方對效能指標有要求的場景，也需要去確認這個指標是否合理。現在，回頭想想，我很早之前參與的網考系統，那時候要求併發使用者要達到1萬，實際上它的指標更像是線上使用者數，而併發使用者數不會達到這個峰值。
效能需求，還涉及是否需要負載均衡和叢集，session的處理方案，對於這個有狀態的session，是單獨部署伺服器，還是去session化，是考慮單應用模式，還是使用微服務模式等。
安全性需求
安全問題，一直是我們重視的問題。例如，是否存在SQL隱碼攻擊，如何防範XSS攻擊等，詳細內容可以參考我之前的文章《如何防範常見的Web攻擊》。
最容易忽略的部分就是水平許可權管理，水平許可權問題在同一個角色上，系統只驗證了訪問資料的角色，沒有對角色內的使用者做細分，由於水平許可權管理是系統缺乏一個資料級的訪問控制所造成的，因此水平許可權管理又可以稱之為“基於資料的訪問控制”。舉個例子，比如我們之前的一個助手產品，客戶端使用者刪除評論功能，如果沒有做水平許可權管理，即設定只有本人才可以刪除自己的評論，那麼使用者通過修改評論id就可以刪除別人的評論這個就存在危險的越權操作。這個層面，基本需要我們業務層面去處理，但是這個也是最為經常遺落的安全點。
此外，一些產品對安全問題還有其他要求。例如，我剛參與完成的某導航系統，要求進行漏洞掃描，安全生命週期的梳理，威脅建模，防止TLS降級攻擊等。
所以，在產品開發之處，建議把產品需要考慮的安全問題列一個清單，而不是再開發完成之後，再去梳理應該要去考慮什麼安全問題。
（完）
更多精彩文章，盡在「服務端思維」微信公眾號！