待軟體需求discover階段完成,也就是可行性研究完成,公司決定進行該專案/產品的開
發後,就進入了軟體需求的define階段.define階段包括下面的事情:
1)分析專案的風險,編寫專案風險控制報告.在國內,這個報告相當於乙個擺設,文件寫
完就放那裡了;為什麼呢,因為控制風險需要成本,國內老總不想要成本,老總想要的只
是money&money.
2)明確專案的功能需求,整理專案的需求文件.
功能需求文件可能不只乙個,可能每個子系統都有單獨的需求文件;不確定的功能需求
應該用tbd來標誌;功能需求文件可能包括資料字典.功能需求應該由專案的開發經理整
理,但我參與的專案,需求文件都是由小兵來完成的,呵呵,因為功能需求文件太瑣碎了,
當官的才不做這種沒有成就感的小事.當然了,有的專案的功能需求文件是要使用者簽字
的,這樣的文件公司會比較注意.
3)建立需求跟蹤矩陣(scope matrix)
需求跟蹤矩陣(scope matrix)應該是由專案的開發經理來完成並跟蹤的,在我開始做軟
件時,有個資深的程式設計師堅定不移地告訴我,需求跟蹤矩陣(scope matrix)是由專案的
配置管理人員來做,害了我好一陣子;後來想想,需求跟蹤矩陣(scope matrix)將要指導
後期開發,所以編寫人員還應該是開發經理.
4)功能需求的評審
功能需求的評審應該由專案經理發起,行業專家和客戶參與,通過會議形式討論,得出
review notes.
軟體需求體會 discover階段
我畢業後的第乙個職務是軟體工程師,研發部門的,但我的第乙個任務,卻是做調研 就 因為當時我不清楚研發和調研的細緻區別,不能把角色給轉換過來,所以還鬧了一些笑 話,現在想來,還真是挺有意思的.調研應該屬於需求的第一階段 需求的discover階段.調研階段應該完成下面的任務 了解客戶現狀,如客戶的資訊...
軟體需求體會 discover階段
我畢業後的第乙個職務是軟體工程師,研發部門的,但我的第乙個任務,卻是做調研 就 因為當時我不清楚研發和調研的細緻區別,不能把角色給轉換過來,所以還鬧了一些笑 話,現在想來,還真是挺有意思的.調研應該屬於需求的第一階段 需求的discover階段.調研階段應該完成下面的任務 了解客戶現狀,如客戶的資訊...
軟體需求體會 discover階段
我畢業後的第乙個職務是軟體工程師,研發部門的,但我的第乙個任務,卻是做調研 就 因為當時我不清楚研發和調研的細緻區別,不能把角色給轉換過來,所以還鬧了一些笑 話,現在想來,還真是挺有意思的.調研應該屬於需求的第一階段 需求的discover階段.調研階段應該完成下面的任務 了解客戶現狀,如客戶的資訊...