David Ko的學習之旅

以協作方式, 和具體描述範例的方式, 讓大家對需求有共識

課程特色

課程簡介

在 Standish Report 2014中說到, 專案會成功的前五個原因, User involvement 排第一, clear statement of requirements 排行第三. 而失敗的專案中共同的因素裡, incomplete requirements 是第一個, Lack of user involvement 排第二. 因此, 如何邀請用戶來整理出有共識的需求, 是軟體專案的第一要務.

過去專案在需求處理方面, 先是客戶訪談, 然後再根據會議中所討論的, 整理出需求的規格和說明. 可是, 不管撰寫需求的人寫的再怎樣詳細, 雙方總是會有誤解, 開發人員會以為客戶或是 PM 要的就是這樣, 而客戶或 PO 會誤判以為開發人員已經聽懂. 這樣的事情老是一而再的發生.

還有傳統的方式, 會先寫完需求文件, 可是這段時間通常不短, 等到寫完後交給開發, 才又發現客戶已經要改需求了. 另外, 中途當需求有變動, 卻發現要改的地方很多, 你不容易每個地方都找出來修改, 常常會放棄處理, 導致文件和真實需求或系統不同.

為了解決解決以上問題, Gojko Adzic 提出一個改善的做法, 利用測試範例來說明系統的行為, 讓雙方不會只看抽象的敘述 而是從實際的案例上來解釋事情. 此外, 這些範例在系統完成後, 便可以用來確認系統是否真的做到當初所說的, 因為這是具體的測試案例, 有特定的資料數值, 在驗證上沒有模糊的空間. 這堂課就是要來介紹這樣的好方法給大家, 你怎麼可以錯過這個好機會呢！

在這堂課中, 我們將會手把手教大家, 如何以具體範例來說明需求, 在這個過程中如何識別範例中的壞味道, 並且會實際拿不同功能來練習列出範例, 讓大家上完後就可以實際運用到專案上面.

適合對象

• 軟體開發人員, 測試人員
• 專案經理, 系統分析師
• 需要處理軟體系統需求的人
• 對於需求不清楚感到痛苦的人

課程大綱

常見問題