Bug 對於軟件來說是顯而易見的，程序員犯了一絲毫的錯誤就會帶來 Bug。
需求則不同，不適當的需求往往並不是那麼明顯，而且暴露的很晚。錯誤的需求往往不會責備需求的提出方，因爲互聯網時代需要快速 “試錯”，而糾正需求所產生的工作卻落到了工程師頭上。
顯然，這似乎不太公平。錯誤的需求難以被質疑，這也帶來了需求的肆意膨脹，是軟件設計不加以剋制的原因。
下面是一個檢查清單，用於軟件工程師在接受需求時來評審需求是否合理。
原則
屁股決定腦袋，產品經理和軟件開發者之間的立場不同，則關注點不同，這是需求產品經理和開發之間的矛盾的主要原因。好的產品經理思考的是軟件的市場和背後的生意而不是用戶交互；好的軟件工程師思考的是軟件模型和整體設計，而不是某項技術的偏好。
如果軟件開發和建築行業一樣，產品經理就是設計院，設計院輸出的圖紙，如果在施工方無法實施時，設計院會承擔巨大的責任。
互聯網時代，軟件和建築一樣隨處可見。
軟件給人一種容易修改的錯覺。產品經理隨意調整需求被質疑後感到無辜，不就是改一點代碼的事情嗎，爲啥說的那麼難，這人肯定是技術不行。
簡單的軟件確實容易修改，同理，在農村搭一個窩棚也是，但複雜的軟件和摩天大廈不在此列。
複雜的軟件因爲承載了大量的業務模型，以及各種存量的用戶數據，修改運行中的軟件，數據遷移的工作往往比預想要大很多，同時還要考慮已經發布出去的軟件兼容性。
需求變更應該是一個嚴肅和慎重的事情，這是原則。
提前
《一本小小的紅色寫作書》是我最喜歡的一本關於寫作的入門書籍，作者布蘭登·羅伊爾給新手提供了一個寫作建議：當你想到一個絕妙的主題，完成寫作併發布出去等待人們的讚美時，不妨先放一放。當一個好點子蹦出來時，人們往往把所有的美好都寄託在這個點子上，而絲毫看不到不合理之處，其實需要時間讓人冷靜下來。
產品經理往往會蹦出一些“絕妙” idea，自我美妙的 “上頭”。實際上在落地時，會遇到各種問題。
提前準備需求就顯得非常重要，提前三五個星期設計好的需求，隨着時間的推移，實際上每週都能有優化的點，到開始實施時也想的八九不離十了。
軟件工程師應該建議產品經理提前準備需求，如果是 2-3 天內的需求，就需要警覺起來。
雖然互聯網時代變化很快，但不是慌張的理由。
系統性
剛入行的人，多少可能對“系統”這個詞感到奇怪，我們明明只是做了一個軟件、網站或者小程序，但是爲什麼會被稱作爲系統。
我們之所以稱這些軟件爲系統，是因爲現代軟件不像單機桌面軟件，它們有很多組成部分。Web、APP、管理後臺、開放 API、定時任務等各種組件構成。
系統性，帶來的就是牽一髮而動全身。
一次產品經理提出需要收集用戶的公司信息，因此在註冊表單增加了一個字段，但是在管理後臺創建用戶時，並沒有相應的字段，造成數據的混亂。
當產品經理提出一個 web 端的需求時，參考檢查項：
- 對應的後臺是否有相應管理功能？
- APP、小程序等其他端是否有類似需求？
- 開放出去的 API 是否受到影響？
- 已有數據是否需要遷移？
- 是否和其他功能衝突造成邏輯矛盾？
產品經理或 BA 需要知道當前系統的運行狀態，一個將軟件系統視爲黑盒的產品經理，不太能提出嚴密的需求來，只能用創新作爲託詞。
遵守慣例
不遵守業界操作慣例的軟件使用起來讓人非常難受，索尼微單的軟件操作方式比主流相機顯得怪異，即使很多人認可它的拍攝性能，也不願意買單。
不遵守業界操作慣例，而美其名曰創新的需求，往往都會經歷來回改的結果。
按照慣例，信息系統的列表頁都會有分頁、搜索、篩選、排序等組成部分。如果設計上列表頁沒有分頁，在可以預見的情況之下，性能會非常差。
對於表單控件來說，每一種控件元素都有它背後的交互邏輯，刻意改變用途，不僅不能帶來創意效果，反而會讓用戶感到困惑。表單有四種基本元素，缺少了說明需求不合理，需要調整：
- 標籤
- 表單域
- 提示信息
- 操作按鈕
另外表單設計還需要考慮數據回填視圖，這種視圖下可能交互和 UI 有所不同。
一致性
需求的一致性體現一個軟件是否專業，影響用戶的主觀感受。
一致性有幾個維度：
- 操作邏輯上的一致性
- 組件 UI 一致性
- 文案的一致性
同類的交互使用同一個控件，避免出現多種組件。比如上傳文件的邏輯，文件大小、交互方式、允許的文件類型，都應該保持一致。
在之前一個產品中，領導要求 UI 的設計稿還原接近 100%，我們採用將設計稿疊加在瀏覽器中實現的。然而，中途設計師離職，新的設計師無法做到和原來的設計師保持完全一樣的設計尺寸、顏色。
這種情況繼續堅持 100% 的還原度，後果是前端代碼中所有的頁面都有自己的樣式文件，組件幾乎無法複用。
大的團隊往往有自己的設計規範、設計系統等，這樣也減少了高保真的輸出，使用設計系統，不必輸出高保真。開發人員使用原型圖 + 設計系統中的組件即可做出統一美觀的軟件界面來。
使用原型圖表達整個系統的交互邏輯，不用關係 UI 細節，UI 細節交給設計系統來完成。
文案的一致性，要求系統所有的地方使用同樣的名詞概念、表述方式，避免給用戶帶來困惑。
非功能性需求
評審需求時，非功能需求是最容易遺漏的需求，也是需求的冰山。下圖是一個添加文章的需求，背後有交互、性能、UI等多方面的非功能性需求。
有大量的文章敘述非功能需求，這裏簡單給出一個清單：
- 交互體驗相關
- Loading
- 表單的二次提交
- 輸出格式化
- 請求用戶確認和提示
- 安全相關
- 身份校驗和權限
- 表單驗證
- 性能相關
- 響應時間
- 生效時間（比如，權限相關允許重新登錄生效）
- 可用性相關
- 兼容性
- 特殊設備適用性
- 本地化和國際化
- 升級策略
性價比
最後一項是性價比。
有一些需求不符合當前的軟件模型，改動成本極其高昂。但是如果產品經理做出一些取捨，根據當前的技術模型和架構進行調整，可以維持現在技術模型的一致性，降低開發成本。
比如，用戶的會員信息是存放在 session 中，這樣每一次請求的權限檢查可以非常高效的完成。但是，代價是用戶的會員過期後，需要重新登錄纔會生效，大多數系統都這樣處理，因爲會員過期是一個極其低頻的事件。
如果產品經理要求，會員過期及時的告訴用戶，並進行續費，而不是在重新登錄時觸發這個行爲。即使在技術上能完成，但是付出的代價非常大，也應該在評審時對此類需求進行質疑。
文/Thoughtworks 林寧
原文鏈接：https://insights.thoughtworks.cn/how-to-make-requirements-review/