在需求分析的過程中,要避免需求的不斷蔓延、需求模擬兩可與需求鍍金等風險,必須建立雙方對專案目標的共識,透過各種訪談的技巧與工具,盡力讓需求規格符合完整性、合理性、一致性、易維護性、可追溯性等特徵;廠商與客戶對需求確認也有正確的認知與共識,落實需求變更管理,才能共同走出需求確認的迷思。

好的需求規格應有的特徵

針對需求常見問題的探討,可以歸納出一份好的需求規格應該具備以下的特徵:

完整性

確保沒有一個必要的需求被遺漏。正因為被遺漏了,所以要從需求規格找到被遺漏的需求較不容易,但仍然有些方式可以用來避免。例如:建立CRUD Matrix來驗證我們對資料的Create, Read, Update, Delete都有所了解;或是以邊界值來測試需求,如:「若訂單金額小於100元,則運費為20元;若訂單金額大於100元,則運費為5%。」在這個例子裡,就遺漏了訂單金額等於100元時的狀況。

合理性

即使都要考慮的需求都沒有遺漏了,但也許其中會有些不太合理的地方需要注意。同樣以上述定價法為例,從小於100元的計算式可知道:100元的運費為20元;以大於100元的計算式算出,100元的運費為5元、200元的運費為10元、400元的運費為20元。由於99元與101元訂單的運費差距太大,客戶的用意是要鼓勵大額訂單而懲罰小額訂單,還是公式真的有誤?此時不要預設立場,必須質疑其合理性而提出,請客戶確認「5%」的合理性。

一致性

每個需求敘述間不可以互相牴觸。有時候我們在收集需求時,每個需求單獨來看時都對,但整理在一起時也許會有矛盾或衝突的狀況。這時候需與需求原始的提供者再做確認,也許是在某些條件下要採用A規則,另一個情境下則是採用B規則,透過這樣的確認可以找到客戶原本隱含的假設。實務上也曾發生過在需求訪談時,幫客戶釐清原來規則真有矛盾的地方,進而透過行政程序去做改善,也算是導入系統的另類收穫。

容易維護

不要假設需求規格中的項目永遠不變,因此在需求規格中的需求項目必須要給予唯一的編號,並記錄每次的改版歷程,如果項目較多時可透過歸類與索引讓調整時不致於錯亂。

可追溯

每個需求項目都要能水平與垂直追溯,水平追溯是指需求項目彼此之間是否有cross reference的關係,垂直追溯是指每一項需求項目都能知道是要滿足哪些RFP項目,又是展開到哪些功能,最後要用什麼測試個案來做驗證。

上述的五個特徵看來似乎都理所當然,但做過專案的人都知道,要每一項都能達到也是很大的挑戰。儘管如此,在寫需求規格或進行需求規格審查時,若能把這些特徵放在心上努力去做,品質就能維持較好的水準。

有關需求確認的迷思

需求確認是開發人員最怕又最愛的一個里程碑。怕的是使用者不肯確認,愛的是一旦使用者簽了名,就好像拿到尚方寶劍一樣,立於不敗之地。其實,站在客戶的角度來想,需求確認反而是客戶最怕的一件事(好像沒有客戶愛需求確認的)!客戶怕什麼?想想看,開發人員拿了厚厚一本需求規格書,上面附上確認單,如果不簽,開發人員說沒辦法動工;如果簽了,以後需求有變更時,開發人員就會拿著這紙簽名告訴客戶:「你看!你都簽名了!你不能改了!」,換做是你,一旦簽了就好像所有責任都在你身上,任何需求變更都是你當初沒想清楚,你怕不怕。也難怪會看到一些扭曲的現象,如:有些客戶會拖延確認時間,以為在確認前都可以不斷的改需求;或是以拖待變,等需求想清楚了再給專案團隊,也壓縮了開發時間;有些簽了名的客戶為避免影響自己的績效,只好努力的找bug再把要改的變更順便安排進去;最後都是兩敗俱傷,誰也佔不到什麼便宜。

這種情節看來荒繆卻是在專案開發中不斷上演的,雙方的想法都可理解,但都不太對!其中最關鍵的死結在於雙方都沒有認清需求不可能在一開始就全部都談出來,以及需求會隨著時間而改變的現實。若要牽就這些現實,專案會一直做不完(除非合約是採用Agile的方式進行),因此當談到一定程度時,做需求確認的動作是必要的,這個確認動作可視為一個里程碑,一個基準(baseline),也僅止於此。

客戶確認所代表的意義是:「我同意這份文件裡的需求是能完全符合我截至目前為止所能知道的範圍;我也同意日後這份基準若有變更時透過已定義的變更程序辦理;我也了解日後核准新的需求變更可能會影響專案的時程、預算與投入的資源」。

而開發人員也要修正觀念,當客戶同意簽名時,表示可以依這份需求規格開始動工,並依此建立基準,未來的變更則是要在會議上經雙方對於時程、預算、資源等的取捨後才可以修改。透過這樣的會議,也可以讓使用者在專案進行中保持對專案範圍的關注,確保開發團隊能交付使用者需要的系統。

總之,在需求分析的過程中,要避免需求的不斷蔓延、需求模擬兩可與需求鍍金等風險,必須建立雙方對專案目標的共識,透過各種訪談的技巧(如:雛型展示)與工具(如:需求追溯表),盡力讓需求規格能符合完整性、合理性、一致性、易維護性、可追溯性等特徵;同時也需要廠商與客戶雙方對需求確認有正確的認知與共識,落實需求變更管理,才能共同走出需求確認的迷思,在雙方都認可的範圍內如期、如質、如預算的完成專案。

前面的話題太嚴肅了,最後提供一個網路上流傳的笑話,大家輕鬆一下。

可見得不是只有做專案才需要和客戶做需求確認,連談聘禮時也要和岳父做需求確認,才不會出糗。

網路流傳的笑話

到南部提親…這還是我這輩子的第一次…真的好緊張。事前和媒人婆打探好未來的岳父岳母都是好人,不重視聘金的禮數,而且對身體保健非常的注重,只是開口要了「立攝適」。

在禮車上,我手中握著精美包裝的兩罐「立攝適」,緊張地一直調整領帶的位置,也一直默記著提親的禮節,深怕把重要的這一刻給弄砸了!

到了!終於到了女方家,要面對我人生中最重要的一刻了… 提親的流程很順利的進行著… 收聘禮的時刻到了,我緊張的拿著「立攝適」遞了出去…

「岳父岳母…這是你們要的立…攝適…」緊張的說的零零落落…

看著他們臉上出現了三條線,和頭上飛過的數隻烏鴉…可能是覺得我準備得太少了…

早知道就多買個兩罐就好了…真是的…

為了緩和這個緊張的情緒,我把廣告詞給背了出來…(雙手弄成喇叭狀
「天天立攝適…體力真正GOOD…」伴隨著哈哈兩聲的乾笑…
現場…沒有一個人跟我一起笑出來的…媒人婆真是的…也不出來打個圓場! 

沈默…這個時候是尷尬最大的殺手!

媒人婆這時候終於開口說話了…

「我相信白先生答應要送的聘禮LEXUS,應該是停在台中家裡面吧!是不是啊? 白先生?」