千奇百怪的需求
對開發軟體系統的人而言，最害怕的並不是寫程式，而是千奇百怪的需求。一個朋友告訴我他曾經做過某個學校的校務系統，在加退選的前一天：
『第十五個選課的人不可以退選』學校突然向他們要求這個需求。
經過了解才知道一門課至少必須有十五位選課才可以開課，否則就會倒班，所以校方就提出這個需求。但是用這種方式來預防倒班也有點奇怪。
有趣的事發生了。甲生是第十五個選到課的人（當然他自己不知道他是第十五位），而第十六位選到課的同學正好是他朋友，甲生眼睜睜的看到他同學可以退選，自己卻不能退選。接著又有其他人加選後退選也可以，但他剛好又是第十五位，他還是不能退選，你說氣不氣人？
於是這個問題學生提出來，最後只好把把這個限制拿掉。有時候一個系統的功能看起來沒有幾項，卻是在修修改改之間浪費了很多的時間，如果能夠事先想清楚，是不是可以省很多的時間？如果一個有經驗的系統分析師能夠在顧客提出奇怪的需求時就能跟他們分析這些需求後續可能造成的影響，那就有很大的幫助。
需求因政策的改變有所修改是很正常的事，這就符合Werner Heisenbery的「測不準原理」(Uncertainty Principle)。我們常說軟體工程的issures就是「複雜」與「改變」，所以「千奇百怪的需求」的產生是很正常的事，做為軟體工程師必須忍受這種現象，問題在於，你用甚麼方法發展系統才容易應付這種需求，有許多設計樣式(design patterns)，或結構樣式(architectural patterns)可以運用來應付這種「千奇百怪的需求」，要不然我們學軟體工程或物件導向軟體工程，或其他設計方法何用！？
回覆刪除最近有幾篇文章似乎都在「抱怨」需求變動「無度」、老板要求「無理」等等，而且好像都是作者親身的經驗或聽聞，這種需求好變的現象永遠會存在，甚至會變本加厲，不過這種現象對於教書的人應有相當正面的提示，因為教軟體工程或相關課程與訓練，就是要讓學員能活學活用那些軟工的原則(principles)或常規(practices)，如果不能就不要入軟工這一行。
回覆刪除軟體工程師所碰到的問題的確是很多，因為很多人認為軟體是軟的，所以怎麼變都有可能。身為一個軟體開發者，時常會面對這樣的挑戰。黃教授講得沒錯，我們口袋裡若沒幾把刷子（或是知識/能力），又沒有一些實戰經驗，實在是很難想像如何應對這樣子的工作。這也是希望其他網友們多多分享經驗的地方。
回覆刪除看到『第十五個選課的人不可以退選』這個要求（需求）時，第一印象是怎麼有人想得出來這種怪規則？可是也讓我想到另一個值得思考的問題，也就是『溝通』。Agile裡有提到溝通是一個重要的價值，其實需求工程最重要的一個部分也是溝通。假如一個軟體工程師能在需求分析的時候，就能說明以這需求開發後的系統，使用起來可能會發生什麼樣的事，對客戶所提的無理需求，是否能有一些影響？