文/秋之川
這是《落葉》文集里第 323 片落葉简识，希望你能喜歡拔妥，不為別的忿危，只為這份堅持。
第九章 理解了什么是需求之后該如何做好需求評審呢没龙？
在真正理解了什么是軟件需求之后铺厨，我通過學(xué)習(xí)和回顧，對如何做好需求評審做了一些補充理解硬纤。
需求評審的形式：
- 郵件評審：多用于產(chǎn)品經(jīng)理解滓、研發(fā)團隊等相關(guān)干系人不在同一個辦公地點，或者是需求剛剛出了框架筝家，或比較粗的規(guī)劃洼裤，可通過郵件發(fā)給相關(guān)干系人初評，收集反饋意見溪王。
- 會議評審：相對郵件評審腮鞍，比較系統(tǒng)化、嚴密的一種集體評審方法莹菱，過程一般包括制定評審計劃準備和組織會議移国、跟蹤和分析結(jié)果等，是最正式芒珠，也是最常見的一種評審形式桥狡。
評審會議基本流程
需求評審的層級
-
High-Level 評審搅裙，也就是我們常說的初評皱卓。
（1）通常是產(chǎn)品經(jīng)理在有了基本的需求框架之后，召集相關(guān)干系人部逮，主要是項目里各個角色的負責(zé)人展開的評審娜汁；
（2）他們需要一起明確用戶是誰，站在用戶的角度去看問題兄朋，去挖掘用戶的真實期望掐禁，理解用戶的業(yè)務(wù)流程或應(yīng)用場景，檢查需求是否全面、合理和可行傅事； -
Middle-Level 評審缕允，也就是我們常見的正式需求評審。
（1）這時候需求文檔和原型應(yīng)該都已基本完備蹭越，需要項目里的相關(guān)干系人一起從用戶的業(yè)務(wù)流程和邏輯關(guān)系出發(fā)分析需求障本；
（2）檢查是否遺漏了某個業(yè)務(wù)節(jié)點；
（3）檢查是否遺漏了某個用戶角色响鹃；
（4）檢查是否有完整的業(yè)務(wù)規(guī)則驾霜、業(yè)務(wù)數(shù)據(jù)的輸入和輸出規(guī)范；
（5）檢查最終的功能需求是否能滿足用戶的需求买置，且合理粪糙，并已劃分了優(yōu)先級；
（6）從用戶場景出發(fā)忿项，檢查功能模塊之間是否有沖突蓉冈；
（7）檢查非功能性需求的描述是否清晰合理； -
Low-Level 評審轩触，一些跟業(yè)務(wù)邏輯無關(guān)的微小細節(jié)的檢查洒擦。
（1）需求文檔和原型中的術(shù)語或圖例是否一致；
（2）需求文檔中的提示語文案是的語氣是否合適怕膛，語法是否正確熟嫩，是否有錯別字；
（3）需求文檔中是否存在二義性描述褐捻，或含糊不清的定義掸茅；
需求評審檢查表
為了保證不論是同一個人，還是不同的人柠逞，每次參與需求評審都能高質(zhì)量和高效率地完成評審工作昧狮，作為測試項目管理者，有一個不錯的工具可以利用，那就是將需求文檔，包括原型的質(zhì)量標準和檢查點罚拟，制作成一個檢查表（Check-list）蹦玫，供評審人使用。
參考樣例：
| 序號 | 質(zhì)量標準 | 檢查點 | 檢查結(jié)果 |
|---|---|---|---|
| 1 | 正確性 | 所有的功能邏輯描述是否都正確答朋？ | |
| 1 | 完整性 | 是否有業(yè)務(wù)節(jié)點被遺漏？ | |
| 1 | 是否有功能的業(yè)務(wù)規(guī)則描述不完整？ | ||
| 1 | 是否有遺漏業(yè)務(wù)數(shù)據(jù)的輸入和輸出規(guī)范卿樱？ | ||
| 1 | 一致性 | 是否有使用圖例不一致？ | |
| 1 | 是否有使用術(shù)語不一致硫椰？ | ||
| 1 | 易測性 | 每個功能需求是否可以被測試或如何測試繁调？ | |
| 1 | 對于性能上的需求萨蚕，應(yīng)該如何測試？是否有標準可參考蹄胰？ | ||
| 1 | 可行性 | 每個功能是否都具有可行性或可操作性岳遥？ | |
| 1 | 可靠性 | 當(dāng)系統(tǒng)報錯時，是否有相應(yīng)的裕寨、正確的提示信息寒随？ |
擴展知識補充：
在敏捷里，其實需求已經(jīng)被用戶故事（User Story）所取代帮坚，所以在評審敏捷里的 User Story 時妻往，除了本文中提到的需求質(zhì)量標準之外，還要關(guān)注 User Story 所應(yīng)該符合的 INVEST 標準试和。
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
- 每個 User Story 都是獨立的讯泣，彼此沒有依賴的；
- 每個 User Story 的內(nèi)容都是可以協(xié)商的阅悍；
- 每個 User Story 都是有價值的好渠；
- 每個 User Story 都是可以估算的；
- 每個 User Story 都是足夠小的节视；
- 每個 User Story 都是可測試的拳锚；
《告訴你如何從執(zhí)行測試到管理測試》帶你邁出第（9）步！寻行，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
