規範篇2

二，需求規範

　　　1，目的：　目前存在需求描述不明確，錄入、評審不規範等問題，本文件的目的是通過需求管理規範化，確保團隊的成員在專案過程的做符合專案目標的事，以便提高團隊的整體效率，及時完成專案的目標，交付可用的產品。

　　 2，需求管理規範

　　　　2.1.建立和評審需求

　　　　　　2.1.1 建立需求

　　　　　　（1）需求的標題、所屬模組、需求來源、來源備註 是必填項。 （需求備註：填寫具體的需求填寫人）

　　　　　　（2）所屬計劃，可以暫時保留為空。

　　　　　　（3）錄入需求時預設必須評審。優化、修復，輕微調整可自行判斷是否需求評審。不評審，需求則預設處於草稿狀態。

　　　　　　（4）需求描述內容必須包含不限於： 圖片、原型設計 以及文字描述。有其他參考檔案如：單據、Excel。可以以附件方式上傳。

　　　　　　（5）需求錄入必須填寫 驗收標準。

　　　　2.1.2 需求的列表頁標籤：TBC的說明

　　　　　　T：T 是任務（Task）的縮寫，表示該需求所分解的任務數。

　　　　　　B：B是Bug的縮寫，表示與該需求相關聯的Bug數。

　　　　　　C：C是用例（Case）的縮寫，表示該需求所建立的用例數。

　　　　2.2 需求評審

　　　　　　2.2.1 在建立需求的時候，有一個"不需要評審"的複選框，如果選中該複選框的話，需求的建立是啟用中的。但大部分情況下面，需求還是需要評審的。

　　　　　　即使產品完全由一個人負責，也可以將一些不成熟的想法存為草稿，後續再進行處理。新增需求的評審流程如下：

　　　　　　2.2.2具體的需求評審操作

　　　　　　（1）在需求列表中選擇，“眼鏡圖示”點選，進入評審。

　　　　　 （2）根據評審結果編輯評審結果。

　　　　　　（3）評審通過後，狀態則變為啟用。

　　　　　　2.2.3，評審注意事項：

　　　　　　　　　評審結果可以選擇確認通過、有待明確、拒絕等操作。如果選擇“確認通過”，則需求的狀態改為“啟用中”，然後就可以關聯到專案中進行開發了。

　　　　　　　　　如果選擇“有待明確”，會保持需求的草稿狀態，並將需求指派回需求的建立者頭上，有其繼續進行完善。

　　　　　　　　　如果選擇了“拒絕”，則需要給出相應的拒絕原因，拒絕原因可以有：

　　　　　　　　　由誰評審是記錄的參與評審的人員名單，可以輸入使用者名稱來自動篩選。一般來講需求評審可以是一個線下的評審會議，在禪道里面記錄下參與需求評審的人員即可。

　　　　2.3 變更和評審需求

　　　　　　2.3.1 需求變更流程

　　　　　　2.3.2 需求變更

　　　　　　　　禪道專門提供了需求的變更流程。凡是對需求標題、描述、驗證標準和附件的修改，都應該走變更流程。變更之後的需求狀態為已變更。　

　　　　　　　　（1）編輯操作是無法修改需求的標題、描述、驗收標準和附件的。

　　　　　　　　（2）在變更需求的時候，如果選擇了“不需要評審”，則需求狀態自動變成啟用，不需要再走評審流程。

　　　　　　　　（3）在變更需求的時候，會列出該需求的影響範圍。

　　　　　　　　（4）通過需求的詳情頁面檢視變更前後的變化

　　　　　　　點選需求名稱，進入需求詳情，在下方導航中點選“變更”按鈕。

　　　　　　2.3.3 評審需求

　　　　　　（1）評審結果可以選擇確認通過，撤銷變更，有待明確或者拒絕。如果選擇確認通過，則需求的狀態從“已變更”變為“啟用中”。

　　　　　　（2）如果選擇撤銷變更，則取消當前的變更，並回退到之前的版本。

　　　　　　（3）如果選擇有待明確，需求被打回到需求的變更者，繼續進行完善。

　　　　　　（4）如果選擇拒絕，則需要給出相應的拒絕原因。

　　　　　　（5）同樣在評審需求的時候，也會列出相應的影響範圍，評審者可以參考。

　　　　　2.3.4 確認需求變更

　　　　　　當需求變更被評審確認之後，研發團隊和測試人員需要確認需求的變更。在需求中的影響範圍裡可以看到該變更的需求影響的專案任務、bug和用例，評審後，需要做相應的確認。

　　　　　　如圖：

　　　　2.4 需求狀態和研發階段

　　　　　　2.4.1需求的狀態

　　　　　　　　需求狀態(status)欄位，總共有四種狀態，分別是草稿(draft)、啟用(active)、已變更(changed)和已關閉(closed)。對應為需求的流程操作共有：建立、變更、稽核、關閉、啟用，其狀態流轉圖如下：

　　　　2.4.2 需求的研發階段

　　　　　　　　需求還有一個階段(stage)欄位，用來描述啟用的需求在研發過程中所處的階段。目前總共有未開始、已計劃、已立項、開發中、開發完畢、測試中、測試完畢、已驗收、已釋出。

　　　　　　禪道可以通過編輯操作，來修改研發階段。

　　　　　　但我們更提倡另外一種方案，就是在建立任務的時候，仔細設定任務的型別，比如開發，測試。禪道的程式會自動根據不同型別任務的變化來自動計算需求的研發階段，其規則如下：

1. 如果需求沒有關聯到專案，也沒有關聯到計劃，則需求的研發階段是"未開始"。
2. 如果需求關聯到了計劃，還沒有關聯到專案中，則需求的研發階段是"已計劃"。
3. 如果需求關聯到了專案中，但還沒有分解任務，則需求的研發階段是"已立項"。
4. 如果需求關聯到了專案中，且進行了任務分解:
   如果有一個開發任務進行中，並且所有的測試任務還沒有開始，需求的研發階段為“研發中”。
   如果所有的開發任務已經完成，並且所有的測試任務還沒有開始，則為“研發完畢”。
   如果有一個測試任務進行中，則視為“測試中”。
   如果所有的測試任務已經結束，但還有一些開發任務沒有結束，則視為"測試中"。
   如果所有的測試任務已經結束，並且所有的開發任務已經結束，則視為"測試完畢"。
5. "驗收"階段是需要產品經理手工來進行確認的，確認後階段改為“已驗收”。
6. 產品→釋出中關聯的需求後，需求的研發階段是“已釋出”。

　　　　2.5 需求注意事項

　　　　　　2.5.1需求的INVEST原則：

　　　　一個編寫良好的使用者故事是敏捷開發的基礎。它們應該相互獨立，詳情應該便於開發者和使用者進行溝通，應該對使用者有價值，應該對於開發者來說盡可能的清晰以便進行估計，應該短小，通過預定義測試用例的使用確保它是可以測試的。