xxxx-需求管理規(guī)范v11-資料下載頁(yè)
2025-04-07 07:00本頁(yè)面
【正文】 設(shè)計(jì)階段，需輸出設(shè)計(jì)文檔，并評(píng)審；測(cè)試部門應(yīng)按時(shí)間節(jié)點(diǎn)輸出測(cè)試用例，并評(píng)審。 開(kāi)發(fā)工程師完成編碼、單元測(cè)試、聯(lián)調(diào)測(cè)試，在自測(cè)完成的情況下向測(cè)試部門輸出安裝包、release notes和測(cè)試說(shuō)明文檔申請(qǐng)集成測(cè)試。測(cè)試部門按照測(cè)試流程，進(jìn)行需求的測(cè)試和驗(yàn)證。同時(shí)根據(jù)《缺陷處理規(guī)程》來(lái)處理測(cè)試過(guò)程是發(fā)現(xiàn)的bug，直至灰度測(cè)試完成。跟進(jìn)需求的設(shè)計(jì)實(shí)現(xiàn)過(guò)程，保證需求的實(shí)現(xiàn)不打折扣，并隨時(shí)關(guān)注需求的變化。通過(guò)比較需求定義與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)需求跟蹤列表，確保產(chǎn)品依據(jù)需求的定義進(jìn)行開(kāi)發(fā)。產(chǎn)品經(jīng)理每天都需要跟進(jìn)當(dāng)前迭代中需求的實(shí)現(xiàn)進(jìn)度，確保需求執(zhí)行的過(guò)程沒(méi)有出差錯(cuò)，一般而言，需求的跟蹤分為兩種：正向跟蹤：檢查已安排的每個(gè)需求是否都能在后續(xù)的實(shí)現(xiàn)過(guò)程中有相對(duì)應(yīng)的部分，確保沒(méi)有漏做的需求，并保證需求的實(shí)現(xiàn)程度和需求定義要求的一樣。這就需要每天都與后續(xù)的各個(gè)負(fù)責(zé)實(shí)現(xiàn)的人員進(jìn)行確認(rèn)。逆向跟蹤：根據(jù)已有的原型、UI、系統(tǒng)設(shè)計(jì)文檔、測(cè)試用例文檔等成果文檔，反向檢查是否包含了所有已安排的需求。 需求變更對(duì)一個(gè)軟件項(xiàng)目來(lái)說(shuō)，無(wú)論最初的需求分析有多么明確，開(kāi)發(fā)過(guò)程中的需求變化也還是不可避免的。這主要有以下幾種原因：1. 軟件所應(yīng)用的外部環(huán)境發(fā)生變化；2. 隨著用戶對(duì)軟件的熟悉和應(yīng)用，又提出新的需求；3. 項(xiàng)目組進(jìn)行需求分析時(shí)未能徹底分析用戶的需求，或分析錯(cuò)誤；4. 用戶在開(kāi)始時(shí)不能很全面的知道所需軟件的功能。 需求變更評(píng)審及實(shí)施1. 對(duì)于小修小改的需求，產(chǎn)品經(jīng)理著急相關(guān)人員座位過(guò)審，相關(guān)人員知悉并同意后，更新Tapd上產(chǎn)品需求更改日志，并在需求詳細(xì)闡述中，紅色標(biāo)示出修改點(diǎn)，以便下流部門知悉2. 對(duì)于大改的需求，召集評(píng)審會(huì)，待下流部門過(guò)審后，項(xiàng)目重新排期，再進(jìn)入開(kāi)發(fā)階段，一樣需要同步更新需求文檔和TAPD上需求日志、表單
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1