簡(jiǎn)介一種標(biāo)準(zhǔn)的需求規(guī)格說(shuō)明書(SRS)模板面向軟件項(xiàng)目團(tuán)隊(duì)適用于項(xiàng)目經(jīng)理、需求分析師、開(kāi)發(fā)工程師和測(cè)試工程師快速撰寫規(guī)范化需求文檔。模板內(nèi)容覆蓋引言、任務(wù)概述、需求規(guī)定、運(yùn)行環(huán)境規(guī)定等核心章節(jié)其中引言細(xì)分為編寫目的、背景、定義、參考資料需求規(guī)定包含功能規(guī)定、性能規(guī)定、輸入輸出要求、數(shù)據(jù)管理能力要求、故障處理要求和其他專門要求并在性能規(guī)定下細(xì)化精度、時(shí)間特性要求與靈活性運(yùn)行環(huán)境規(guī)定涵蓋設(shè)備與支持軟件。文檔已預(yù)設(shè)章節(jié)標(biāo)題與目錄層級(jí)使用者只需替換具體描述即可能幫助團(tuán)隊(duì)統(tǒng)一文檔結(jié)構(gòu)、減少遺漏。資源為單個(gè)doc文件大小約61KB輕量易用。已有3400余人學(xué)習(xí)下載是項(xiàng)目初期規(guī)范需求描述、推進(jìn)設(shè)計(jì)評(píng)審的實(shí)用工具。1. 提到「軟件需求規(guī)格說(shuō)明書模板SRS」大多數(shù)團(tuán)隊(duì)的第一反應(yīng)是模板有什么好寫的找個(gè)現(xiàn)成的改改不就完了。但現(xiàn)實(shí)是一套能真正驅(qū)動(dòng)開(kāi)發(fā)、測(cè)試和驗(yàn)收的SRS模板比多數(shù)人想象的要難設(shè)計(jì)得多。寫SRS這件事很多團(tuán)隊(duì)的打開(kāi)方式就錯(cuò)了項(xiàng)目啟動(dòng)時(shí)趕一份文檔應(yīng)付立項(xiàng)評(píng)審評(píng)審一過(guò)就再?zèng)]人翻等開(kāi)發(fā)做完了再補(bǔ)一份交差。真正的軟件需求規(guī)格說(shuō)明書SRS應(yīng)該回答一個(gè)問(wèn)題——這份軟件到底要做什么做到什么程度算好。它服務(wù)的不是評(píng)審委員會(huì)而是三撥人三個(gè)月后接手代碼的開(kāi)發(fā)、寫測(cè)試用例的測(cè)試、以及驗(yàn)收時(shí)跟你扯皮的用戶。這篇不打算講虛的直接給一份能落地、能評(píng)審、能追蹤的SRS模板寫法以及我在多個(gè)項(xiàng)目里踩過(guò)的坑。新手照章填內(nèi)容熟手對(duì)照查漏項(xiàng)。2. 寫SRS前先想清楚讀者、邊界與需求分級(jí)2.1 先定讀者開(kāi)發(fā)、測(cè)試、驗(yàn)收誰(shuí)是這份文檔的最終用戶很多團(tuán)隊(duì)在動(dòng)筆前沒(méi)有回答一個(gè)基本問(wèn)題這份SRS的讀者是誰(shuí)。讀者不同文檔的語(yǔ)言風(fēng)格、詳細(xì)程度、甚至章節(jié)側(cè)重都會(huì)完全不同。如果讀者是開(kāi)發(fā)團(tuán)隊(duì)功能需求部分要寫到每條業(yè)務(wù)規(guī)則都能直接對(duì)應(yīng)到代碼邏輯如果讀者包含客戶或業(yè)務(wù)方術(shù)語(yǔ)要少用每個(gè)功能塊前面最好有一段白話描述讓不懂技術(shù)的人也能讀懂業(yè)務(wù)閉環(huán)。我的做法是文檔開(kāi)頭先用一小節(jié)寫明目標(biāo)讀者后面再統(tǒng)一按最苛刻的讀者來(lái)寫——通常是最較真的那個(gè)測(cè)試工程師。原因很簡(jiǎn)單測(cè)試是唯一會(huì)把文檔里每個(gè)字摳出來(lái)逐條驗(yàn)證的人。開(kāi)發(fā)看需求時(shí)可能會(huì)憑經(jīng)驗(yàn)?zāi)X補(bǔ)業(yè)務(wù)方看需求時(shí)可能會(huì)跳過(guò)細(xì)節(jié)測(cè)試不會(huì)。他們會(huì)拿著文檔問(wèn)這個(gè)等字等的是什么這個(gè)支持具體指什么操作。所以一份能讓測(cè)試不產(chǎn)生歧義的SRS大概率能讓所有讀者都不產(chǎn)生歧義。這里還要區(qū)分一個(gè)常見(jiàn)誤區(qū)SRS不等于產(chǎn)品需求文檔PRD。PRD往往面向產(chǎn)品團(tuán)隊(duì)描述用戶故事、交互流程和產(chǎn)品決策背景SRS面向開(kāi)發(fā)與測(cè)試描述系統(tǒng)的可驗(yàn)證行為。兩者的讀者和使用場(chǎng)景不一樣混在一起寫文檔會(huì)變得既不夠產(chǎn)品、又不夠工程最后誰(shuí)都不滿意。我一般建議團(tuán)隊(duì)把PRD當(dāng)成SRS的前置輸入而不是替身。2.2 需求分級(jí)Must / Should / Could / Wont 怎么定SRS最常見(jiàn)的翻車是需求清單上所有條目都寫著必須實(shí)現(xiàn)。當(dāng)所有東西都是最高優(yōu)先級(jí)的時(shí)候等于沒(méi)有優(yōu)先級(jí)。我在模板里強(qiáng)制要求每個(gè)功能需求標(biāo)注MoSCoW等級(jí)用四檔取代必須這種一棍子打死的描述。Must是缺失即失敗的硬需求系統(tǒng)沒(méi)有它就不能上線Should是重要需求但在資源不足時(shí)可以讓步Could是錦上添花的需求有精力才做Wont是明確本期不做的需求。前三個(gè)等級(jí)大家比較熟悉容易忽略的是Wont。我吃過(guò)這個(gè)虧有一次項(xiàng)目驗(yàn)收時(shí)客戶指著我們當(dāng)初討論過(guò)但沒(méi)做的功能說(shuō)這個(gè)當(dāng)時(shí)不是說(shuō)要做的嗎翻遍文檔也找不到一句不做的說(shuō)明最后只能加班補(bǔ)。從那以后我在SRS里專門留一節(jié)記錄Wont需求寫明不做的原因和可能的后續(xù)計(jì)劃。落地的操作方式并不復(fù)雜。需求評(píng)審時(shí)每個(gè)需求由提出人先自評(píng)等級(jí)然后與會(huì)者投票最終由項(xiàng)目負(fù)責(zé)人拍板。這里有一個(gè)建議我會(huì)在評(píng)審結(jié)束時(shí)統(tǒng)計(jì)各等級(jí)的需求數(shù)量如果Should和Could加起來(lái)超過(guò)40%就要和項(xiàng)目干系人重新討論范圍——要么砍需求要么調(diào)資源要么拉長(zhǎng)排期總之不能假裝看不見(jiàn)。這個(gè)比例不是硬性標(biāo)準(zhǔn)但它是一個(gè)很好的預(yù)警線。提示需求分級(jí)不是一次性的。迭代開(kāi)發(fā)中每個(gè)迭代開(kāi)始前要重新審視需求等級(jí)把新需求加進(jìn)來(lái)重新排序。優(yōu)先級(jí)是動(dòng)態(tài)的不是寫進(jìn)文檔就定型了。2.3 文檔邊界SRS不寫設(shè)計(jì)、不寫計(jì)劃、不寫實(shí)現(xiàn)細(xì)節(jié)新手寫SRS最容易越界把系統(tǒng)架構(gòu)圖畫進(jìn)來(lái)把數(shù)據(jù)庫(kù)表結(jié)構(gòu)列進(jìn)來(lái)把迭代計(jì)劃也寫進(jìn)來(lái)。SRS的邊界是做什么不是怎么做。界面原型、接口定義、數(shù)據(jù)庫(kù)設(shè)計(jì)、項(xiàng)目排期這些內(nèi)容各有各的歸宿硬塞進(jìn)SRS只會(huì)讓文檔變得臃腫。我對(duì)邊界的判斷方法是寫需求時(shí)如果出現(xiàn)通過(guò)XX實(shí)現(xiàn)采用XX技術(shù)數(shù)據(jù)庫(kù)使用XX這類句式停下來(lái)問(wèn)一個(gè)問(wèn)題——把這個(gè)句子刪掉開(kāi)發(fā)是否仍然清楚他要做什么如果答案是清楚這句話就不屬于SRS如果答案是不清楚說(shuō)明需求本身沒(méi)寫明白需要補(bǔ)充的是行為描述而不是技術(shù)選型。舉個(gè)例子。系統(tǒng)使用Redis緩存用戶session這句話是設(shè)計(jì)用戶登錄后30分鐘內(nèi)無(wú)需重復(fù)登錄超過(guò)30分鐘再次操作時(shí)跳轉(zhuǎn)登錄頁(yè)這句話是需求。前者是手段后者是行為。SRS寫后者就夠了具體用什么實(shí)現(xiàn)是設(shè)計(jì)文檔的事。這里容易引起爭(zhēng)議的是性能需求和一些強(qiáng)技術(shù)約束的場(chǎng)景比如必須兼容Windows Server 2022——這種約束是需求要寫用Java重寫舊系統(tǒng)是設(shè)計(jì)不要寫進(jìn)SRS除非它是客戶指定的硬性約束。邊界不清導(dǎo)致的直接后果是文檔維護(hù)困難。設(shè)計(jì)變了SRS里的實(shí)現(xiàn)描述過(guò)期了開(kāi)發(fā)不知道該信哪個(gè)干脆兩個(gè)都不看。所以我在模板開(kāi)頭明確聲明SRS不包含設(shè)計(jì)決策并提醒團(tuán)隊(duì)在評(píng)審時(shí)對(duì)照這個(gè)聲明檢查——發(fā)現(xiàn)實(shí)現(xiàn)細(xì)節(jié)就劃掉不留情面。3. 一份能落地的SRS模板10個(gè)章節(jié)逐節(jié)拆解3.1 引言部分目的、范圍、定義與參考文檔引言是SRS最容易變成廢話的地方。我見(jiàn)過(guò)不少文檔的目的節(jié)寫滿一頁(yè)為了規(guī)范軟件開(kāi)發(fā)流程提高軟件質(zhì)量增強(qiáng)團(tuán)隊(duì)協(xié)作效率——全是正確的廢話。目的這一節(jié)兩句話就夠一句話說(shuō)清楚軟件要解決什么問(wèn)題一句話說(shuō)明文檔的服務(wù)對(duì)象和適用范圍。范圍一節(jié)要同時(shí)寫在范圍內(nèi)和不在范圍內(nèi)兩個(gè)清單。不在范圍內(nèi)的價(jià)值經(jīng)常被低估。很多項(xiàng)目就栽在不做沒(méi)寫清楚到了驗(yàn)收階段扯皮的全是當(dāng)初沒(méi)明確說(shuō)不做的事。我給客戶審閱SRS時(shí)會(huì)特意讓他們?cè)谶@兩個(gè)清單上簽字確認(rèn)這個(gè)動(dòng)作能擋掉很多后續(xù)的需求蔓延。定義與縮寫列表要在文檔一開(kāi)始就建好后續(xù)所有章節(jié)引用時(shí)全文統(tǒng)一。不要一會(huì)兒寫用戶、一會(huì)兒寫客戶、一會(huì)兒寫操作者同一個(gè)概念在不同章節(jié)用不同名詞開(kāi)發(fā)很可能把一個(gè)概念當(dāng)成兩個(gè)實(shí)體去設(shè)計(jì)。我一般用下面這個(gè)框架作為模板的基礎(chǔ)結(jié)構(gòu)# 軟件需求規(guī)格說(shuō)明書SRS ## 1. 引言 ### 1.1 目的 本文檔定義XX系統(tǒng)的功能需求與非功能需求作為開(kāi)發(fā)、測(cè)試與驗(yàn)收的依據(jù)。 ### 1.2 范圍 在范圍內(nèi) - 用戶注冊(cè)、登錄與權(quán)限管理 - 工單的創(chuàng)建、分派、處理與關(guān)閉 - 基礎(chǔ)統(tǒng)計(jì)報(bào)表 不在范圍內(nèi) - 移動(dòng)端APP本期僅支持Web端 - 與第三方CRM系統(tǒng)對(duì)接排期未定 - 短信網(wǎng)關(guān)的接入依賴外部合同簽訂 ### 1.3 定義與縮寫 | 術(shù)語(yǔ) | 說(shuō)明 | | ---- | ---- | | 工單 | 用戶在平臺(tái)上提交的服務(wù)請(qǐng)求 | | 分派 | 將工單指派給具體處理人 | | 時(shí)效 | 工單從創(chuàng)建到關(guān)閉的時(shí)長(zhǎng) | ### 1.4 參考資料 ...這段模板的邏輯是先讓讀者在5分鐘內(nèi)判斷這份文檔跟我有沒(méi)有關(guān)系有關(guān)系再看下去。范圍一節(jié)的不在范圍內(nèi)清單是全文最重要的需求管理工具之一。參數(shù)說(shuō)明定義表里每個(gè)術(shù)語(yǔ)只給一個(gè)含義如果同一個(gè)詞在業(yè)務(wù)中確實(shí)存在兩種理解換一個(gè)詞描述其中一種不要買一送一。3.2 總體描述產(chǎn)品視角、用戶特征、運(yùn)行環(huán)境、約束與假設(shè)總體描述這一章給讀者建立全局畫面。產(chǎn)品視角用一兩段話描述系統(tǒng)在業(yè)務(wù)鏈路中的位置和它的核心價(jià)值不畫架構(gòu)圖——那是設(shè)計(jì)文檔的職責(zé)。這段文字是給新成員和外包團(tuán)隊(duì)快速了解業(yè)務(wù)用的寫法上以白話為主避免上來(lái)就堆功能清單。用戶特征用表格列出每類用戶的操作頻率、技術(shù)水平和使用場(chǎng)景。這個(gè)表格對(duì)后續(xù)交互判斷很有用如果用戶是每天8小時(shí)使用的內(nèi)部坐席人員界面密度可以高一些快捷鍵要有如果用戶是偶爾用一次的普通訪客界面引導(dǎo)就得做得更重。運(yùn)行環(huán)境寫服務(wù)器、瀏覽器、移動(dòng)端的支持范圍這里要具體不要寫支持主流瀏覽器要寫支持Chrome和Edge最近兩個(gè)大版本不支持IE。約束一節(jié)寫政策法規(guī)、技術(shù)選型限制、交付日期硬性要求。假設(shè)與依賴寫那些如果外部條件不成立就會(huì)出問(wèn)題的事項(xiàng)例如依賴短信服務(wù)商的接口SLA達(dá)到99.5%若低于該標(biāo)準(zhǔn)驗(yàn)證碼類功能時(shí)效性受影響。這一節(jié)在項(xiàng)目后期是排查責(zé)任邊界的重要依據(jù)寫的時(shí)候要細(xì)致不能含糊。3.3 功能需求編號(hào)、描述、優(yōu)先級(jí)、驗(yàn)收標(biāo)準(zhǔn)一個(gè)都不能少這是SRS的核心章節(jié)也是寫得最爛的章節(jié)。功能需求的粒度要控制在一條需求對(duì)應(yīng)一個(gè)可獨(dú)立驗(yàn)收的功能點(diǎn)每條需求有四個(gè)必備元素唯一編號(hào)、功能描述、優(yōu)先級(jí)、驗(yàn)收標(biāo)準(zhǔn)。編號(hào)是需求的身份證格式為FR-XXX遞增分配不刪號(hào)只作廢。這樣做的原因是追蹤時(shí)需要穩(wěn)定引用如果編號(hào)重排文檔里的交叉引用和測(cè)試用例里的關(guān)聯(lián)關(guān)系全部失效。### FR-001 工單創(chuàng)建 - 描述登錄用戶可以填寫工單表單并提交提交成功后生成唯一工單號(hào)。 - 優(yōu)先級(jí)Must - 驗(yàn)收標(biāo)準(zhǔn) 1. 給定已登錄用戶當(dāng)填寫所有必填字段并點(diǎn)擊提交時(shí)系統(tǒng)生成工單號(hào)并展示提交成功頁(yè) 2. 給定已登錄用戶當(dāng)必填字段為空點(diǎn)擊提交時(shí)表單在對(duì)應(yīng)字段下方紅字提示缺失項(xiàng)不生成工單記錄 3. 給定未登錄用戶當(dāng)訪問(wèn)工單創(chuàng)建頁(yè)面時(shí)系統(tǒng)跳轉(zhuǎn)登錄頁(yè)登錄成功后自動(dòng)返回原頁(yè)面。 - 依賴FR-002 用戶認(rèn)證這段模板的邏輯是驗(yàn)收標(biāo)準(zhǔn)全部用給定/當(dāng)/則的句式把前置條件、觸發(fā)動(dòng)作、預(yù)期結(jié)果拆開(kāi)寫讓不同讀者讀到同一句話時(shí)產(chǎn)生相同的理解。參數(shù)說(shuō)明優(yōu)先級(jí)一列在評(píng)審時(shí)如果所有人都是Must回到2.2的統(tǒng)計(jì)方法討論范圍驗(yàn)收標(biāo)準(zhǔn)條目數(shù)一般不超過(guò)5條超過(guò)5條說(shuō)明需求粒度過(guò)粗要拆分成多條獨(dú)立需求依賴字段幫助排期時(shí)判斷哪些需求必須同批次交付也用于變更影響分析。3.4 外部接口需求把對(duì)接X(jué)X系統(tǒng)寫成可實(shí)現(xiàn)的描述外部接口是SRS里最容易被忽略的部分。很多文檔只在功能需求里提到一句對(duì)接第三方支付平臺(tái)卻沒(méi)寫清楚對(duì)接什么能力、傳輸什么數(shù)據(jù)、超時(shí)怎么處理、失敗怎么提示。等開(kāi)發(fā)做到這一段才發(fā)現(xiàn)接口文檔還沒(méi)定、異常處理沒(méi)定、對(duì)接流程也不明確項(xiàng)目周期性停滯。接口需求分四類分別寫用戶接口描述人與系統(tǒng)的交互方式硬件接口描述設(shè)備型號(hào)、通信方式軟件接口描述被集成的外部系統(tǒng)、調(diào)用協(xié)議通信接口描述協(xié)議、端口、報(bào)文格式。每個(gè)接口需求的預(yù)期內(nèi)容接口用途、輸入數(shù)據(jù)、輸出數(shù)據(jù)、異常行為。這里不需要給出具體API設(shè)計(jì)——那是接口文檔的職責(zé)——但要寫清楚接口的約束和失敗時(shí)的行為。以對(duì)接短信網(wǎng)關(guān)為例SRS里應(yīng)該寫系統(tǒng)通過(guò)HTTP調(diào)用短信服務(wù)商接口發(fā)送驗(yàn)證碼短信當(dāng)接口響應(yīng)超時(shí)超過(guò)5秒時(shí)系統(tǒng)提示用戶稍后重試并記錄日志當(dāng)服務(wù)商返回發(fā)送失敗時(shí)系統(tǒng)提示用戶短信發(fā)送失敗請(qǐng)檢查手機(jī)號(hào)是否正確。這比支持短信驗(yàn)證碼發(fā)送多了三個(gè)維度調(diào)用方式、超時(shí)行為、失敗提示。開(kāi)發(fā)拿到這段描述不需要再問(wèn)超時(shí)了怎么辦測(cè)試也有明確的驗(yàn)證依據(jù)。3.5 非功能需求性能、安全、可用性與可維護(hù)性全部量化非功能需求寫得好不好決定了系統(tǒng)后面能否平穩(wěn)運(yùn)行。這一章的硬性原則每個(gè)指標(biāo)必須是可驗(yàn)證的數(shù)值。不要寫響應(yīng)快要寫常規(guī)操作95%響應(yīng)時(shí)間小于800ms99%小于2s不要寫支持大數(shù)據(jù)量要寫訂單數(shù)據(jù)量達(dá)到100萬(wàn)條時(shí)列表查詢接口在1.5s內(nèi)返回。非功能需求同樣需要編號(hào)我習(xí)慣用NFR-前綴加類別縮寫NFR-PERF-001是性能、NFR-SEC-001是安全、NFR-AVA-001是可用性、NFR-MNT-001是可維護(hù)性。每個(gè)非功能需求的結(jié)構(gòu)與功能需求一致描述、優(yōu)先級(jí)、驗(yàn)收標(biāo)準(zhǔn)。各團(tuán)隊(duì)最容易敷衍的是可維護(hù)性。我見(jiàn)過(guò)太多SRS在可維護(hù)性里只寫一句系統(tǒng)應(yīng)具有良好的可維護(hù)性。這句等于沒(méi)寫。可維護(hù)性可以落到具體條目日志需要記錄哪些關(guān)鍵操作、日志保留多久、錯(cuò)誤碼規(guī)范是什么、告警通知給誰(shuí)。這些條目不需要多每類寫兩三條可執(zhí)行的規(guī)定比十句正確的廢話有意義。4. 讓SRS可驗(yàn)證驗(yàn)收標(biāo)準(zhǔn)、追蹤矩陣與評(píng)審清單4.1 驗(yàn)收標(biāo)準(zhǔn)用Given-When-Then模板寫一條需求配3~5條功能需求部分已經(jīng)要求每條需求帶驗(yàn)收標(biāo)準(zhǔn)這一節(jié)深入說(shuō)說(shuō)怎么把它寫好。Given-When-Then模板來(lái)自測(cè)試領(lǐng)域用來(lái)寫需求驗(yàn)收標(biāo)準(zhǔn)非常順手。三條要素分別是Given前置條件When觸發(fā)動(dòng)作Then預(yù)期結(jié)果。以登錄場(chǎng)景為例給定一個(gè)已注冊(cè)且狀態(tài)正常的用戶當(dāng)輸入正確手機(jī)號(hào)和密碼時(shí)系統(tǒng)登錄成功并跳轉(zhuǎn)到首頁(yè)——這比一句用戶能夠正常登錄要好用得多。驗(yàn)收標(biāo)準(zhǔn)的三個(gè)覆蓋維度值得對(duì)照自查正常流程、異常流程、邊界情況。正常流程保證能干活異常流程保證出問(wèn)題時(shí)不至于白屏邊界情況保證數(shù)據(jù)臨界時(shí)不崩。很多需求文檔寫滿了正常路徑異常路徑全靠開(kāi)發(fā)自覺(jué)補(bǔ)充這是需求分析偷懶的表現(xiàn)。我見(jiàn)過(guò)一種寫法上的反面典型系統(tǒng)會(huì)提示錯(cuò)誤。這句話的主語(yǔ)模糊、行為模糊。驗(yàn)收標(biāo)準(zhǔn)應(yīng)該寫系統(tǒng)在輸入框下方以紅色12號(hào)字體提示驗(yàn)證碼錯(cuò)誤請(qǐng)重新輸入原輸入內(nèi)容保留。誰(shuí)提示、提示什么內(nèi)容、提示在哪里、原數(shù)據(jù)是否保留這些細(xì)節(jié)決定了開(kāi)發(fā)和測(cè)試對(duì)需求的理解是否一致。細(xì)節(jié)不是限制開(kāi)發(fā)自由而是避免理解偏差。4.2 需求追蹤矩陣需求變更時(shí)一分鐘找到所有受影響對(duì)象追蹤矩陣RTM是SRS真正管理起來(lái)的橋梁。矩陣的每一行對(duì)應(yīng)一條需求列一般包括需求編號(hào)、需求描述、優(yōu)先級(jí)、設(shè)計(jì)文檔位置、測(cè)試用例編號(hào)、測(cè)試結(jié)果狀態(tài)。這個(gè)表維護(hù)在Wiki或文檔管理工具中每次需求變更時(shí)同步更新。它的價(jià)值在于變更影響分析需求改了順著矩陣快速定位到受影響的測(cè)試用例和設(shè)計(jì)模塊然后按圖索驥逐個(gè)更新。需求編號(hào)需求描述優(yōu)先級(jí)設(shè)計(jì)位置測(cè)試用例測(cè)試結(jié)果FR-001工單創(chuàng)建Must設(shè)計(jì)文檔3.2TC-FR-001~003通過(guò)FR-002用戶認(rèn)證Must設(shè)計(jì)文檔4.1TC-FR-004~007通過(guò)FR-010報(bào)表導(dǎo)出Could設(shè)計(jì)文檔5.1TC-FR-021~022未開(kāi)始矩陣的維護(hù)時(shí)機(jī)有三個(gè)需求評(píng)審?fù)ㄟ^(guò)后建立初版每次需求變更時(shí)更新受影響的行每個(gè)迭代結(jié)束時(shí)核對(duì)測(cè)試結(jié)果。這里有一個(gè)常見(jiàn)誤解RTM是寫完文檔之后的工作。實(shí)際上RTM應(yīng)該在需求評(píng)審當(dāng)天就開(kāi)始建先有矩陣再補(bǔ)文檔而不是反過(guò)來(lái)。需求變更時(shí)有一種常見(jiàn)的失聯(lián)場(chǎng)景測(cè)試已經(jīng)按舊需求寫好了用例開(kāi)發(fā)按新需求完成了代碼兩邊對(duì)不上互相認(rèn)為是對(duì)方的錯(cuò)。有了RTM變更發(fā)起人可以提前看到這條需求綁定了哪些測(cè)試用例和設(shè)計(jì)模塊把更新任務(wù)派發(fā)給對(duì)應(yīng)的責(zé)任人而不是靠大家自覺(jué)。4.3 評(píng)審清單評(píng)審會(huì)就按這份清單逐條過(guò)SRS投評(píng)審之前我習(xí)慣先跑一遍自查清單。這里有一份可以直接抄進(jìn)團(tuán)隊(duì)流程的問(wèn)題清單覆蓋了文檔質(zhì)量的主要維度每條功能需求是否都有唯一編號(hào)編號(hào)是否無(wú)重復(fù)、無(wú)重排每條需求是否標(biāo)注了優(yōu)先級(jí)優(yōu)先級(jí)分布是否合理需求描述是否避免了快速友好等這類不可驗(yàn)證的詞每條需求是否覆蓋正常流程、異常流程、邊界情況三類驗(yàn)收標(biāo)準(zhǔn)非功能需求是否包含可測(cè)量的數(shù)值指標(biāo)范圍一節(jié)是否同時(shí)寫了在范圍內(nèi)和不在范圍內(nèi)術(shù)語(yǔ)全文是否統(tǒng)一定義表是否覆蓋所有縮寫是否存在把設(shè)計(jì)混進(jìn)需求的情況外部接口的異常行為是否有定義需求之間是否存在矛盾比如一個(gè)地方說(shuō)只允許管理員刪除另一個(gè)地方說(shuō)用戶可刪除自己的工單評(píng)審會(huì)的用法也很關(guān)鍵。我建議評(píng)審前每個(gè)人先對(duì)照清單自己過(guò)一遍評(píng)審會(huì)上只討論不通過(guò)的條目不從頭到尾朗讀文檔。朗讀式評(píng)審的效率和效果都很差大家坐下來(lái)兩小時(shí)真正有價(jià)值的討論其實(shí)集中在不到10%的內(nèi)容上。逐條過(guò)清單把有爭(zhēng)議的條目拉出來(lái)討論評(píng)審會(huì)才能控制在一小時(shí)以內(nèi)。5. 寫SRS的避坑指南5個(gè)高頻翻車現(xiàn)場(chǎng)5.1 把怎么做寫進(jìn)需求現(xiàn)象需求描述里出現(xiàn)系統(tǒng)使用Redis做緩存采用微服務(wù)架構(gòu)前端使用Vue框架。評(píng)審時(shí)沒(méi)人提出異議開(kāi)發(fā)按部就班實(shí)現(xiàn)結(jié)果到了后期發(fā)現(xiàn)技術(shù)選型不適合業(yè)務(wù)場(chǎng)景想換方案但需求文檔寫死了用Redis只能硬著頭皮做下去。原因?qū)懳臋n的人把自己預(yù)想的技術(shù)方案直接寫進(jìn)了需求混淆了做什么和怎么做。解決把實(shí)現(xiàn)細(xì)節(jié)從SRS中劃掉改成行為描述。系統(tǒng)使用Redis緩存熱數(shù)據(jù)改成系統(tǒng)需支持緩存熱數(shù)據(jù)在數(shù)據(jù)量100萬(wàn)條時(shí)熱點(diǎn)查詢響應(yīng)時(shí)間低于200ms。開(kāi)發(fā)自然會(huì)為這個(gè)指標(biāo)尋找最合適的方案如果最終選了Redis以外的方案只要指標(biāo)達(dá)標(biāo)文檔不會(huì)成為阻礙。5.2 形容詞型需求誰(shuí)都能讀誰(shuí)都不敢接現(xiàn)象系統(tǒng)應(yīng)擁有友好的用戶體驗(yàn)數(shù)據(jù)要快速加載頁(yè)面操作要流暢。評(píng)審時(shí)沒(méi)人反對(duì)因?yàn)槊總€(gè)人心里都有自己的一套標(biāo)準(zhǔn)但大家的標(biāo)準(zhǔn)各不相同。開(kāi)發(fā)按自己理解做了測(cè)試按自己理解測(cè)了驗(yàn)收時(shí)業(yè)務(wù)方說(shuō)這不是我想要的。原因在沒(méi)有做需求分析的情況下用形容詞填補(bǔ)思考空白。解決把形容詞改成可測(cè)量的指標(biāo)?？焖偌虞d改成頁(yè)面首屏加載時(shí)間在4G網(wǎng)絡(luò)下小于3秒。友好這種詞如果無(wú)法量化就拆解成具體的交互規(guī)則比如表單提交失敗時(shí)保留用戶已填寫內(nèi)容就是一條可驗(yàn)證的友好表現(xiàn)。改完以后開(kāi)發(fā)和測(cè)試就有了明確的標(biāo)準(zhǔn)。5.3 只寫主流程異常路徑全靠開(kāi)發(fā)自覺(jué)現(xiàn)象需求文檔寫滿了登錄成功、下單成功、審核通過(guò)卻沒(méi)有密碼連續(xù)錯(cuò)誤怎么處理、庫(kù)存不足怎么處理、審核駁回怎么處理。測(cè)試拿到文檔后正常流程用例寫完了異常流程問(wèn)開(kāi)發(fā)你們?cè)趺磳?shí)現(xiàn)的開(kāi)發(fā)說(shuō)我按自己理解做的。原因需求分析時(shí)把精力集中在主流程上忽略了異常路徑。主流程確定系統(tǒng)的核心價(jià)值異常路徑?jīng)Q定系統(tǒng)是否可靠?jī)烧叨贾匾?。解決在評(píng)審時(shí)對(duì)每條需求追問(wèn)一個(gè)問(wèn)題如果這一步失敗系統(tǒng)應(yīng)該展示什么把這個(gè)問(wèn)題的答案寫進(jìn)驗(yàn)收標(biāo)準(zhǔn)。密碼連續(xù)錯(cuò)誤5次鎖定30分鐘、庫(kù)存不足時(shí)提示具體缺口數(shù)量、審核駁回時(shí)通知申請(qǐng)人不通過(guò)原因——這些補(bǔ)齊后SRS才算真正完整。5.4 非功能需求形同虛設(shè)系統(tǒng)需穩(wěn)定運(yùn)行等于沒(méi)寫現(xiàn)象SRS的非功能需求部分只有孤零零的一句話系統(tǒng)需保證穩(wěn)定運(yùn)行具有良好的性能和安全性。到了壓測(cè)階段測(cè)試問(wèn)性能指標(biāo)是多少開(kāi)發(fā)說(shuō)能跑就行安全測(cè)試問(wèn)有哪些安全要求負(fù)責(zé)的說(shuō)你看行業(yè)通用的就行。原因?qū)懙娜苏J(rèn)為非功能需求不重要或者覺(jué)得自己寫不出可量化的指標(biāo)干脆用一句正確的廢話帶過(guò)。解決至少先確定三類非功能需求并量化性能響應(yīng)時(shí)間、吞吐量、并發(fā)用戶數(shù)、安全認(rèn)證方式、權(quán)限粒度、數(shù)據(jù)傳輸加密要求、可用性年度可用性百分比、故障恢復(fù)時(shí)間。每類寫兩三條就夠關(guān)鍵在可驗(yàn)證。用戶并發(fā)數(shù)達(dá)到200時(shí)核心接口響應(yīng)時(shí)間不超過(guò)1.5秒比一百句高性能有用。非功能需求不要求一步到位但必須起步。5.5 SRS寫完就鎖進(jìn)抽屜需求變更后文檔徹底失聯(lián)現(xiàn)象SRS評(píng)審?fù)ㄟ^(guò)后被當(dāng)作定稿封存項(xiàng)目進(jìn)入開(kāi)發(fā)階段后需求陸續(xù)變化開(kāi)發(fā)按新需求改代碼沒(méi)有人更新SRS。項(xiàng)目尾聲測(cè)試按SRS寫測(cè)試用例和實(shí)際系統(tǒng)對(duì)不上只好不斷找開(kāi)發(fā)問(wèn)你們到底是怎么做的。原因文檔管理流程沒(méi)建立起來(lái)需求變更沒(méi)有走變更流程SRS沒(méi)有被當(dāng)成活文檔維護(hù)。解決把SRS納入版本管理每次變更走同樣的流程提交變更請(qǐng)求、評(píng)估影響用RTM定位受影響范圍、評(píng)審并批準(zhǔn)、更新SRS及所有受影響文檔、通知所有相關(guān)方。變更記錄表放在文檔頭部格式簡(jiǎn)單就可以日期、變更人、變更內(nèi)容、關(guān)聯(lián)需求編號(hào)。6. 讓一條需求從SRS走到測(cè)試用例以忘記密碼為例的完整鏈路前面把模板和坑都講透了最后用一個(gè)例子把整條鏈路串起來(lái)。假設(shè)原始需求只有一句話用戶忘記密碼時(shí)可以重置密碼。這句話不能直接進(jìn)SRS它缺少可驗(yàn)證的行為定義。進(jìn)入SRS后這條需求展開(kāi)成FR-030### FR-030 密碼重置 - 描述用戶在登錄頁(yè)點(diǎn)擊忘記密碼通過(guò)驗(yàn)證已綁定手機(jī)號(hào)重置登錄密碼。 - 優(yōu)先級(jí)Must - 驗(yàn)收標(biāo)準(zhǔn) 1. 給定已注冊(cè)且綁定手機(jī)號(hào)的用戶當(dāng)點(diǎn)擊獲取驗(yàn)證碼時(shí)系統(tǒng)在60秒內(nèi)向該手機(jī)號(hào)發(fā)送短信驗(yàn)證碼 2. 給定用戶當(dāng)輸入驗(yàn)證碼錯(cuò)誤并點(diǎn)擊提交時(shí)系統(tǒng)提示驗(yàn)證碼錯(cuò)誤連續(xù)錯(cuò)誤5次鎖定30分鐘 3. 給定用戶當(dāng)輸入手機(jī)號(hào)未注冊(cè)時(shí)系統(tǒng)提示該手機(jī)號(hào)未注冊(cè)不發(fā)送驗(yàn)證碼 4. 給定用戶當(dāng)設(shè)置的新密碼與舊密碼相同時(shí)系統(tǒng)提示新密碼不能與舊密碼相同 5. 給定用戶當(dāng)重置成功后使用新密碼登錄時(shí)系統(tǒng)登錄成功并跳轉(zhuǎn)首頁(yè)。對(duì)照驗(yàn)收標(biāo)準(zhǔn)測(cè)試用例的設(shè)計(jì)幾乎是順理成章的TC-030-01驗(yàn)證正常重置流程TC-030-02驗(yàn)證未注冊(cè)手機(jī)號(hào)提示TC-030-03驗(yàn)證驗(yàn)證碼連續(xù)錯(cuò)誤鎖定TC-030-04驗(yàn)證新舊密碼相同情況TC-030-05驗(yàn)證重置后登錄成功。每個(gè)測(cè)試用例的預(yù)期結(jié)果直接來(lái)自SRS的驗(yàn)收標(biāo)準(zhǔn)不需要測(cè)試另起爐灶去猜需求。最后在RTM里登記一行FR-030密碼重置Must設(shè)計(jì)文檔4.2TC-030-01~05未執(zhí)行。這一行讓這條需求從文檔到測(cè)試的路徑變得透明需求變更時(shí)順著這一行找到測(cè)試用例更新起來(lái)有據(jù)可查。我后來(lái)養(yǎng)成了一個(gè)習(xí)慣寫一條需求之前先在腦子里把對(duì)應(yīng)的測(cè)試用例過(guò)一遍。如果一條需求想不出至少3條驗(yàn)收標(biāo)準(zhǔn)說(shuō)明需求本身還沒(méi)想清楚如果測(cè)試用例與驗(yàn)收標(biāo)準(zhǔn)對(duì)不上文檔里一定有一處是假的。把這個(gè)問(wèn)題消滅在動(dòng)筆階段比事后再補(bǔ)要省力得多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取