被遺漏的需求

在軟體開發過程中，需求變動往往會令開發團隊十分困擾，即使許多開發團隊在設計前做了許多努力，希望找到軟體的最完整需求，同時要求使用者確認下來，但最後卻還是發現需求變動終究還是不能避免。最近，同人在上班搭公車的時候，遇見了我目前所參與專案的前一任專案經理，他聽別人告訴他專案此階段已近尾聲了，客戶卻還一直在改需求，他向我表示，他很不能理解這樣的狀況。

怎麼現在還再改需求，那這樣向 power user 展示系統請他們提供對系統意見又有何用？

正巧此時他的站到了，必須下車，臨去之前我只得微笑著告訴他：＂需求會變動是很正常的一件事＂，但我從他的眼中看到他疑惑，似乎是認為專案在需求確認後，不應該任由客戶變更需求。

同人可以理解這位長官的看法，站在管理面的觀點，需求變更會對專案造成不小的影響，既然之前雙方已經針對需求做過確認了，就沒有理由讓需求一改再改，不能因為客戶臨時產生一些新的想法，就要迎合他們改變需求。

不過，從另一個角度來思考，要找到軟體所有的需求，是一件很困難的事情。為什麼呢？因為尋找需求就像尋找未被發現的癈墟一樣，當我們找到愈多，我們就愈發現有剩下的沒被我們找到[ref]Dean Leffingwell & Don Widrig(2003), Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley.[/ref]。換句話說，當我們以為我們已經找到了所有的需求時，很有可能是因為還有被遺漏的需求未被發現，直到它們真正被發現為止，我們才有機會了解更完整的需求。

由此可知，在客戶確認需求後，就不讓他們改變需求是多麼難以做到的一件事。所以，在軟體開發過程中，堅持不讓客戶修改需求其實是不切實際的。

當然，我們也不能讓客戶隨意更改需求，擁抱改變不代表我們該接受混亂失序的狀態，而是需要對變更採取必要的管理。管理的目的不是為了防止改變，而是為了防止因為改變而造成系統開發的混亂失序狀態。

從許多方面都一致地顯示著，要對變更做好妥善的管理，其實關鍵還是在於溝通上。在專案變更管理方面，必須達成讓改變對達成專案目標有正面的意義的共識、確認造成變更的因素已經發生、以及協助有效管理變更的行為[ref]此為 PMBOK 所認為的一般性變更管理的原則。[/ref]。而軟體敏捷開發方法也強調開發者與客戶必須達成共識，對於會影響正在開發的功能的變更必須延後處理。

從軟體開發的現實角度來看，如果要等所有遺漏的需求都被找到了，才可以開始開發軟體的話，我們必須承認那將會是個不能完成的任務，但我們卻也了解到，在某些問題點上，我們可以有信心地說：＂我們現在已發現足夠的需求了，以後我們會找到剩下的需求＂[ref]同附註1[/ref]。

所以，難怪 SWEBOK Guide 2004 當中，在需求過程中會特別強調：

需求過程不是軟體生命週期中被分割的前端作業，卻是從專案初始在生命週期中，連續不斷精煉需求的一個過程[ref]A project of the IEEE Computer Society Professional Practices Committee(2004), Guide to the Software Engineering Body of Knowledge, 2004 Version, IEEE.[/ref]。

因為有遺漏的需求，所以同人才會認為需求會變動是很正常的一件事，開發者對抗它是沒有意義的，去思考如何因應現況才能創造價值，才是共創雙贏的互賴行為呀。

Powered by ScribeFire.

Please follow and like us: