非功能性需求，不要成爲項目的坑

咱們在審批case的時候，最容易忽略的部分就是非功能性需求。非功能性需求分析不透徹，或者被忽略，經常給項目埋下巨大無比的坑。這個坑，想必你們都或多或少遇到過吧。好比項目要交付的時候，交互或需求不明確或者有歧義致使項目返工或延期，安全問題考慮不周致使生產環節被攻擊者惡意攻擊，沒有考慮性能致使遇到高流量的時候就悲劇了等場景。今天的話題，咱們就來聊聊《非功能性需求，不要成爲項目的坑》。

原文地址：非功能性需求，不要成爲項目的坑
博客地址：blog.720ui.com/

易用性需求

顧名思義，用戶在使用過程當中易理解，易操做等。頁面描述要清晰，最高境界就是「零手冊」，不能讓用戶理解有歧義，此外，一致性也是很重要的，好比輸入內容校驗規則，頁面展現風格，相似模塊的交互等等。好比，一個系統，有的地方是用瀑布式風格，有的地方使用正常的分頁，在頁面展現上就會有點奇怪，不是麼？

頁面交互

換句話說，就是頁面交互中咱們須要確認的一些經常容易忽略的問題。這裏面的坑太多了，我舉幾個案例做爲引子，但願引發你們的注意。

案例一 有效性校驗

有效性校驗，有什麼特別之處麼，咱們正常都會考慮到的 ? 我想說「Are you sure？」，咱們來看看下面兩個場景。

首先，看看新浪微博的發佈文章功能，並非咱們理解的全部中文，字母，數字，符合分別都算1個字喲，這裏的2個數字纔算1個字。因此，咱們的產品中有存在這種場景，就須要和策劃/需求人員確認清楚規則，而不是想固然咯。

而後，咱們再看看微信公衆號發佈文章功能，正文內容限制是2萬字，超過2萬字就不讓提交了。這也是一個非功能性需求，須要和策劃/需求人員確認清楚文章字數限制，若是他們說但願無窮大，而後你答應了，請挖好坑把本身埋了吧。

案例二 潛在默認值規則

不少狀況下，存在若是不填寫會設置默認值的場景，此時你要確認清楚具體的默認值規則。好比，發佈一個應用，默認是下架仍是上架狀態？設置權重，是否有默認值場景？再好比，文章摘要的場景也是一個很好的例子。微信公衆號，摘要的規則就是若是不填寫會默認抓取正文前54個字。

案例三 註冊用戶與遊客用戶的區分

若是是遊客用戶，下面的收藏、評論、點贊，交互場景如何呢?是屏蔽讓遊客用戶沒法看到，仍是置灰禁止操做，仍是彈出登陸頁面，讓用戶註冊或者登錄。

功能邏輯

功能邏輯，也是一個很常常考慮的問題。這裏面的坑也不少，我舉幾個案例，看看是否引發你們的共鳴。

案例一 涉及自身

好比，生日祝福功能，是否能夠給本身祝福呢? 關注用戶功能，能夠不能夠關注本身哈？這些都是須要考慮的，雖然從產品的角度而言沒太大問題，可是從使用的角度，就存在必定的業務問題。

案例二 敏感信息

好比，服務端發送消息給客戶端，若是單單從客戶端的角度進行敏感信息的過濾，安全性上面就存在很大的風險。以前，我抓包分析過一些產品的接口數據，有的產品接口層面沒有作屏蔽，只是簡單的在頁面加」*「符號替換，固然這些信息，被盡收眼底。

可靠性需求

例如，是否考慮容錯性，是否考慮灰度環境，是否服務降級，是否考慮故障轉移等。

兼容性需求

Web端是否考慮兼容市面上主流瀏覽器，好比是否須要兼容IE八、IE9，這也是比較頭大的問題，須要一開始就要確認清楚，而不是開發過程當中再去考慮。由於，IE八、IE9涉及技術選型上的問題，好比是否要用HTML5，跨域問題要如何處理，須要採用什麼框架，是使用原生的方式，仍是使用單頁面框架React/Vue？

Android端，須要兼容哪些主流版本，4.x? 5.x? 6.x? 須要考慮哪些設備等。

性能需求

性能需求，也是一個很是重要的非功能性需求。簡單的理解，性能就是在空間和時間資源有限的條件下，軟件系統工做的如何？系統性能需求，有幾個典型的指標：響應時間，併發用戶數，TPS，資源利用率等。

試想，若是是電商系統，咱們不去考慮性能，那麼生產環境遇到稍微高一些的併發場景，服務器可能就奔潰了。

此外，業務方對性能指標有要求的場景，也須要去確認這個指標是否合理。如今，回頭想一想，我很早以前參與的網考系統，那時候要求併發用戶要達到1萬，實際上它的指標更像是在線用戶數，而併發用戶數不會達到這個峯值。

性能需求，還涉及是否須要負載均衡和集羣，session的處理方案，對於這個有狀態的session，是單獨部署服務器，仍是去session化，是考慮單應用模式，仍是使用微服務模式等。

安全性需求

安全問題，一直是咱們重視的問題。例如，是否存在SQL注入攻擊，如何防範XSS攻擊等，詳細內容能夠參考我以前的文章《如何防範常見的Web攻擊》。

最容易忽略的部分就是水平權限管理，水平權限問題在同一個角色上，系統只驗證了訪問數據的角色，沒有對角色內的用戶作細分，因爲水平權限管理是系統缺少一個數據級的訪問控制所形成的，所以水平權限管理又能夠稱之爲「基於數據的訪問控制」。舉個例子，好比咱們以前的一個助手產品，客戶端用戶刪除評論功能，若是沒有作水平權限管理，即設置只有本人才能夠刪除本身的評論，那麼用戶經過修改評論id就能夠刪除別人的評論這個就存在危險的越權操做。這個層面，基本須要咱們業務層面去處理，可是這個也是最爲常常遺落的安全點。

此外，一些產品對安全問題還有其餘要求。例如，我剛參與完成的某導航系統，要求進行漏洞掃描，安全生命週期的梳理，威脅建模，防止TLS降級攻擊等。

因此，在產品開發之處，建議把產品須要考慮的安全問題列一個清單，而不是再開發完成以後，再去梳理應該要去考慮什麼安全問題。

（完）

更多精彩文章，盡在「服務端思惟」微信公衆號！