簡介
無可避免地,系統開發一定會形成一套需求階層,從定義系統任務或系統整體使用者目標或意圖的概略層次開始,一直深入至最詳盡的層次,中間或許歷經許多中階層次。在最詳盡的層次上,極可能以系統所使用技術詞彙來表達需求;反之,在最高層次上,通常根據系統針對之領域的專業術語,採取較抽象的表達方式,例如性能、服務、行為、函數、功能等,言詞的選擇沒有固定的標準。當然,這些言詞可能有不同的意義來更精確的表達主題
(例如,對系統特定行為的描述,可能無法完全彰顯目標或意圖,需要輔以其他敘述符號),但這不是本文討論的重點。
需求修飾(從最高層次開始,加入更多細節)可完全以純功能作為行進導向,亦即將功能再細割為支援這些功能所需的子功能或子作業 - 不考慮任何實現架構 -
如此的分割結果可將所述需求帶入系統的內部深處(假設系統以此方式建構),且在系統之外可能沒有直接的通訊。例如,在如同基本轉換氣泡一樣深入的結構化分析方法中,就是這種情形。
這種方式欠缺考慮,首先,因為會將完全不是需求的事物視為需求,而這些事物只是分解的工作成果;再者,如果設計師太緊密對映實現與分解,則可能導致架構不良(例如,無法滿足或妨礙其他非功能需求)。然而,從高階的觀點來表達目標願景時,仍然有正當的理由可以執行
一些功能分解,但將分解深度限制在明顯的性能或功能上,亦即,有足夠詳細的資訊可擷取所有重要的(對關係人而言) 行為、特性等,讓設計師可以正確實現這些功能。從高階需求修正而得的需求(或多或少直接修正)是一種衍生需求。
衍生需求
以下是一個簡單的例子:
假設使用者需求是「系統必須在阿拉斯加州的室外運作,且全年無休」。
有幾個衍生需求包括:
-
系統必須在 32 F / 0 C 以下的溫度運作。
-
系統必須在雪地裡運作。
還有另一種衍生需求。以適當的實現細節來表達系統層次的需求之後,您就接著:
-
將系統(模型)分割成元素(例如,運用 OOAD 方法)。
-
決定這些元素如何分工合作,達成預期的系統行為。
-
從協同作業中匯集低階行為,導出元素層次的需求。
這些低階需求是衍生需求;已經與系統的分解達成一致。根據簡介段落中對功能性方法的說明,進行功能分割時並不考慮任何架構分解及系統層次需求的修飾,剛好和衍生需求形成一種對比。
分配的需求
分配的需求是指已指派(根據功能考量)給系統元件的需求,例如硬體或軟體子系統等元件。舉例還說,我們在極高的層次上推論一個系統體系的任務層次需求時,仍可採用功能導向的方式來詳述這些需求,然後分割產生的衍生需求,並將群組分配給
系統 - 或許實現之前可再進一步修正。之後,建議仿照「衍生需求」的作法繼續進行。即使在系統體系層次上,您也可以考慮運用「商業模型」方法,以此方式進行。
請注意,在衍生方法中,系統會先拆解成實體,再經由研究實體之間如何分工合作達成更高層次的需求,以決定實體的需求。在功能性、分配的方法中,則是先拆解需求,再指定可滿足低層需求的實體。
採用的方法視情境及文化和契約期望而定。例如,美國太空總署 (NASA) [請參閱 Software Assurance Guidebook, NASA Goddard Space Flight Center Office
of Safety, Reliability, Maintainability and Quality Assurance, 9/89] 將需求定義成四種詳細層次:
-
層次 1,任務層次 - 非常高階,在初期就固定。
-
層次 2,系統層次(分配)- 此層次也是初期就很固定。這些需求衍生自任務層次,然後分配至區段。
-
層次 3,子系統(或區段)層次(衍生)- 此層次的需求是從已分配至區段的系統層次需求中衍生。
-
層次 4,配置項目(硬體配置項目 [HWCI],軟體配置項目 [CSCI])層次 (詳細)- 同樣地,自前一個層次分配,再經過修正。
需求層次和對映至 RUP。
契約通常是在層次 3 訂定。NASA 習慣以此方式來處理需求,任何與 NASA
往來的組織很自然會採用相似的分類架構。開發人員仍然有相當大的彈性決定如何衍生低階需求,但由於任務層次的需求有非常高度的抽象化(通常很像程式層次需求),循著功能路線可以自動衍生出系統層次的需求(及區段分配)。儘管如此,隨著企業架構愈來愈受到重視,即使是系統需求,也愈來愈普遍以架構為著眼點來衍生。上圖說明這種情形,也顯示
NASA 層次和 RUP 工作成果(包括商業模型)的對映。在 RUP 流程中,請注意「使用案例實現化」流程和後續的行為聚合中是如何完成傳統流程上的分配。圖中以藍色虛線連接相似層次的工作成果。
|