需求工程

已經是好久以前的事了…

我們到一個部門跟他們談office automation,問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎?』(雖然過了好多年,這好像仍然是一些人會問的問題)

拿出我們軟工的本領,就開始『需求工程』了,可是問題不太像我以前所碰到的CASE容易,更不像課本裡所說的那麼單純。我們問他們如何作業,沒有人講得清楚,甚至有許多不同版本。結果變成我們替他們釐清問題,替他們定義一些作業方式,就像我們替他們定一堆SOP一樣,結果還被批評一番。經果許多討論與翻修,終於完成。這中間有多少時候我常想,為什麼不是他們,而是我在替他們定需求呢?難道我以前碰過得人,就那麼的合作嗎?

好不容易prototype出來了,他們開始使用好像不太熟悉,可是試用一段時間後,他們終於瞭解原來電腦不是什麼都會,可是同時看到他們可以藉著軟體系統作更多的事。

以後幾年的合作,他們從被動不合作的『使用者』,變成主動且很聰明的『需求提供者』。他們的胃口也變大,可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。

不知大家有沒有,相似的經驗?假如以為需求分析,只是問問東西,或是定一些定義出來,那就好像不是這麼一回事了。

留言

  1. 胃口也變大,可以想出一大堆非常有創意的應用
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    但是常常情況是領了之前case的錢,而常常被凹
    之後的應用,自己以前遇到的情況是這樣
    因為在台灣贈送好像是裡所當然,當然
    這種情況,"學生" 遇到的情況更為明顯

    回覆刪除
  2. 我想胃口變大是可以接受的,只要需求提供者變得更成熟,漸漸的知道電腦能做什麼、不能做什麼。更棒的使用者會幫開發者想到時程、經費、甚至於幫忙做寫文件、作系統分析。我想就是合作的默契吧。

    所以作軟體專案一定要看長遠的,第一次的案子通常會虧錢,但是做下來了,以後所有的維護案幾乎都跑不掉。

    『魔鬼都藏在細節中』,許多系統一開始看的時候都覺得很簡單,真的下去作才知道有許多的『眉角』(台語)。以前作過一個社區管理的系統,一開始雙方都說的簡單,『僅』提供部分小功能,想不到需求越作越大,還好後來及時縮小範圍才能將案子順利的結案。真的不要小看任何的系統。

    回覆刪除
  3. 個人現在也卡在一個"小小"的使用者管理系統,
    本來只是處理一個報名系統, 但是後來發現,
    他們所定義的使用者有好幾種不同群組,
    每個群組又不是 exclusive, 但是所對應到的行為卻又更複雜,
    所以越寫越亂, 詢問對方的需求的細節,
    得到的回答卻是完全不同的另外一套系統,
    照著他們新的想法去寫, 做了一些修改,
    正要把系統上線的時候, 卻發現檔案系統被客戶的一個半美工/半網頁設計師全部大搬風,
    自己都找不到原來的檔案放在哪裡,
    更別提新的程式碼要上傳到哪個路徑...

    真的, 雖然說程式設計的時候要保留擴展的空間,
    不知道是我資歷太淺, 還是這根本是需要"突變"或是"完全變態"的空間? (泣)

    回覆刪除
  4. 通常我們一開始接觸一個系統的時候,使用者都會講他最重要的功能,而開發者也只會去想技術上有沒有什麼困難,所以就開始動工了。都忽略的系統分析的重要性,沒有透過系統分析去把相關的需求找出來,就很容易發生後續作不完的窘況。

    或許我們會說,當初都已經簽約了,需求就是這些,使用者怎麼可以改?使用者也很無辜,必經他不是資訊專長,domain 有時候也不是很清楚,所以這時候去吵 RFP 或是合約的內容已經沒有什麼用了。

    系統分析真的要注意。

    回覆刪除
  5. 我不知以下說法是否對處理需求變動有用!

    1. The Agile Manifesto第3項:"Customer
    collaboration over contract negotiation"

    2. The Agile Principles第1項:"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

    如果大家覺得有用,可以另文討論。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮