今天進行了傳說中的需求評審。開始以為是一群大boss坐在那裡挑我們的毛病,沒想到是乙個極度輕鬆和open的過程。總結下一哈:
首先,需求評審的參與者是pd,pm,需求方和專案小組全體成員。目的是對需求方提出的需求進行確認和補充。大致的流程是:需求方給出乙個大概的輪廓,開發團隊提出自己的想法,然後諮詢需求方這樣是否滿足了需求。在這個過程中,可以順帶解決兩個問題:一是統一了專案組內部的想法,二是使需求盡量詳細,避免以後因為需求問題導致的變更。
在對prd文件進行提問的時候,作為乙個有經驗的開發人員,要問一些有「技術含量」的問題:
1.未雨綢繆,考慮產品上線之後會產生的問題。如產品對併發的要求,以後是否會有擴充套件,是否需要公升級服務,需要長期維護?
2.**遠矚,考慮全面。如劃定系統的涉眾,具體實施過程,必須要遵守的規則(高壓線),最後的期望產出物。
3.向直接使用者提問。在他們那裡可以改善一些很「蹩腳」的需求提案。而且可以詢問一些以前類似系統的使用情況,對即將做的產品有更直觀的了解。
4.做任何決定都要有書面記錄。比如需求評審開會時一定要指定兩個書記員,記錄需求的更改細節。需求評審結束之後要對本次評審進行總結,並整理乙份完整的需求文件出來,給今天與會的人員每人乙份。而且此需求一旦制定,以後最好不要再去修改。
5.充分考慮到專案風險。在評審會議上,要收集和公布所有的風險和應對措施。這樣以後出現風險時不會太慌張。
軟體需求評審 過程階段評審
過程階段評審,無評審,不過關!還記得在我們還是學生的年代,每次考試交卷前都會檢查好幾遍,生怕錯漏了什麼,實際上就是開展了一次評審活動,評審的人是你,評審的物件是那份卷子,評審的目的是為了發現問題並修改。在軟體生產過程中,涉及到一道道環節,軟體生命週期從專案啟動到需求,緊跟著設計,然後開發,之後測試,...
需求評審與需求測試
在軟體開發過程中,需求分析是最開始的工作,需求分析如果做得不夠詳細或者是偏離使用者需求的話,往往會給專案帶來滅絕性的災難。因此如何保證需求分析的正確性,不偏離使用者的需求就成了決定軟體專案成敗的關鍵。需求工程師取得使用者的顯性需求後,要仔細的分析使用者到底要求軟體實現什麼功能,使用者的表達和需求工程...
專案管理 需求評審6大靈魂拷問
當需求來臨時,不能來者不拒,一定要思考下面六大問題,可有效避免做無用功。需求描述 為什麼要做 是否真的必要 期望的目標 怎麼做做什麼 透視最根本目的 自查,減少浪費 設定可量化的指標 系統設計和詳細設計 以建設公司內部知識社群為例 1.需求描述 建立乙個內部知識分享社群。2.為什麼要做?可以形成業務...