簡介
本原則明確指出平衡往往相衝突的商業與關係人要求的重要性,以及如何在滿足各方需求下平衡自訂開發與資產重複使用。
|
|
好處
|
-
調平應用程式與商業及使用者需求
-
減少自訂開發
-
商業價值最大化
|
型樣
|
-
定義、瞭解並決定商業及使用者需求的優先順序
-
因應軟體功能需求,決定專案及需求的優先順序
-
瞭解可活用的資產
-
平衡資產重複使用與使用者需求
|
反型樣
|
-
於專案之初詳盡書面記錄確切需求,強迫關係人接受需求
-
協商需求上的任何變更,但每次變更都會增加專案成本或拖延期限
-
於一開始便敲定需求不得變動,因而降低活用現有資產的能力
-
以進行自訂開發為主
-
僅聽取意見最多的關係人的需求來架構系統
|
|
討論
舉例而言,大多數的關係人都希望應用程式能夠完全照他們的意思運作,且要用最低成本、在最短期限內完成開發。可惜,這些優先順序往往相互衝突。另一個例子是,若直接採用套件式的應用程式,或許能夠以較快的速度及較低成本產出解決方案,但卻必須犧牲掉許多需求。反之,若選擇從頭開始建置全新的應用程式,也許能夠滿足期望中的每一項需求,但是預算及專案完成日卻恐怕遙不可及。
使用元件可大幅降低成本及時程,產出一定程度的功能。我們通常也必須在一些功能面或技術需求上妥協, 例如平台支援、效能或規模(應用程式的實體大小)。
站在平衡需求的立場,首先必須有效管理需求,如輔助資料:需求管理中所述。我們無需任命程式設計團隊與需求清單中的每一項目大戰三回合,而是先進行瞭解後,排定商業與關係人要求的優先順序。亦即掌握商業流程,逐一對應到專案及軟體能力,以便有效排定專案及需求的優先順序,並隨著我們對應用程式的瞭解加深及關係人需求提升,逐步修改既定的優先順序。此外也需要與客戶及專案的客戶代表溝通,以確實理解對方的需求所在。
同時,我們應當以關係人需求為中心,進行開發活動。例如,活用使用案例導向開發及以使用者為中心的設計,我們的開發即可在專案全程中,適應不斷演變的業務,加深我們對於商業及一般使用者最重視的功能認知,而能夠包容關係人的需求變化。
最後,我們應瞭解哪些資產可資利用,並在資產重複使用與關係人需求之間取得平衡。
所謂的資產例如包括舊版應用程式、服務、可重複使用的元件及型樣。在多數情況下,重複使用資產能降低專案成本。重複使用可信用的資產,往往能為新應用程式的品質背書。但缺點在於,在多數情況下,我們必須在重複使用資產與徹底滿足使用者需求之間作一取捨。重複使用元件假設
約可降低 80% 的開發成本,但也許只能達到 75% 的需求。因此,為求有效的重複使用,必須不斷在平衡資產重複使用與進展不定的關係人需求之間取得平衡。
|