作業: 開發增補規格
這項作業會擷取不適用於特定使用案例的需求。
目的
擷取使用案例中尚未擷取的需求。
關係
主要說明

在需求活動期間,會依據所收集的關係人需求,在「增補規格」中擷取不適用於特定使用案例的需求。「增補規格」可以擷取功能方面和非功能方面的需求。 

如需有關分類及擷取需求的詳細資訊,請參閱概念:需求

在執行這項作業時,很重要的一件事是確保所有需求記載的詳細程度,足以移交給設計師、測試人員及文件作者使用。如果需求要進行追蹤或正式管理,請確定要清楚指出及標示每項需求。

步驟
擷取非關使用案例的功能需求

功能需求說明用來支援使用者目的、作業或活動的系統行為(功能或服務) [MAL2001]

雖然有許多功能需求會記載在使用案例中,但是有些功能需求卻無法套用至特定的使用案例。例如,產生報告、審核、列印、安全、授權支援/實施、鑑別需求等。這類型的功能需求應該記載在「增補規格」中。       

如果有大量的全系統功能需求存在,則要注意這些需求的組織方式。一般的組織方式是依特性/特性組合,但是也可以使用別的組織方式。例如,依使用者組織或依子系統組織,都是可行的方式。 

功能需求代表 "FURPS+ 中的 'F'。如需有關  "FURPS+" 的詳細資訊,請參閱概念:需求

擷取系統品質

非功能面需求包括品質和限制 [MAL2001]。我們要在這個步驟討論品質。限制會在別的步驟中探討。 

[系統] 品質是關係人所關心的系統內容或特性,因此將會影響他們對系統的滿意程度。[MAL2001]

品質在 "FURPS+" 中代表 "URPS"。對這些需求分類的顧慮如下所示: 

  • 使用性:使用者介面的美觀與一致性。  
  • 可靠性:可用性(系統可用時間量)、系統計算的精確度以及系統的故障回復能力。
  • 效能:產量、回應時間、回復時間、開機時間及關機時間。
  • 支援性:可測試性、可調適性、維護能力、相容性、配置能力、延展性以及區域化能力。

如需有關 "FURPS+" 以及擷取非功能需求的詳細資訊,請參閱概念:需求

您可以視所要記載的系統品質數目,針對每種品質類型提供個別的子區段。

下列區段提供您可能要針對這些品質擷取的兒童資訊的一些範例:

使用性

說明使用性需求時,可以指定:

  • 讓一般使用者和進階使用者可以有效率執行特定作業所需要的訓練時間
  • 一般作業的可測量作業時間
  • 遵守一般使用性標準的需求,例如 IBM 的 CUA 標準或 Microsoft 的 GUI 標準

可靠性

說明可靠性需求時,可以指定:

  • 可用性 – 指定可用的時間百分比 ( xx.xx%)、使用時數、維護存取、退化模式作業等等。
  • 平均失效時間 (MTBF) – 這通常是以時數指定,但也可以用天數、月數或年數指定。
  • 平均修復時間 (MTTR) – 系統失敗之後,可以接受處於無法作業狀態多久?
  • 精確度 – 指定系統輸出需要的精準度(解析)及精確度(依據一些已知的標準)。
  • 錯誤或問題比率上限 – 通常是以 bugs/KLOC(無數程式碼行)或 bugs/function-point 表示。
  • 錯誤或問題比率 - 依次要、重要及嚴重錯誤分類:需要必須定義嚴重錯誤指的是什麼;例如,完全喪失資料或完全無法使用系統的特定功能部分。

效能

說明效能需求時,可以指定:

  • 交易的回應時間(平均、上限)
  • 產量(例如每秒交易數)
  • 容量(例如系統可以容納的客戶或交易數目)
  • 退化模式(當系統循某種方式退化時,可以接受的作業模式為何)
  • 使用資源:記憶體、磁碟、通訊等等

記載效能需求時,務必要包括特定的回應時間。在可能的情況下,依名稱參照相關的 使用案例

支援性

說明支援性需求時,可以指定:

  • 程式碼撰寫標準
  • 命名慣例
  • 類別庫
  • 維護存取
  • 維護公用程式
擷取限制

在這個步驟中,您要記載所要建構的系統之任何設計限制。以一般的方式來說,限制是我們在提供解決方案時,可以有的自由程度限制  [LEF2000]。設計限制代表已經委任並且必須符合的設計決定。   

限制代表 "FURPS+" 中的 '+',並且可以依照下列方式,進一步分類: 

  • 設計限制:指定或限制用來建構及/或設計系統的選項。例如,要求使用關聯式資料庫作為持續性使用。 
  • 實作限制:指定或限制系統的程式碼撰寫或建構限制。例如,必要標準、程序、工具、實作語言、硬體平台、作業系統、協力廠商元件、類別庫以及資源限制(使用記憶體或磁碟空間)。
  • 介面限制:指定系統必須與之互動的外部項目,或是這種互動中使用的格式限制或其他因素。例如,透過訊息佇列作為和外部系統的介面。 
  • 實體限制:指定對用來存放系統的硬體實施的實體限制,例如形狀、大小或重量等。

您可以視所要記載的系統限制數目,針對每種限制類型提供個別的子區段。另外:

  • 如果需求包括購買協力廠商的元件時,請務必要記載任何適當的授權或使用限制,以及任何相關聯的相容性/交互作業能力或介面標準。建議針對每一種採購的元件,使用一個個別的區段。
  • 如果需求包括特定的介面需求,則建議您針對不同的介面類型(使用者、硬體、軟體) 提供個別的區段。對於每一種介面,務必要包括適當的規格、通訊協定、連接埠和邏輯位址等,以便針對介面需求開發及驗證軟體。具體地說,亦即:
    • 如果是使用者介面,說明要由軟體實作的使用者介面。
    • 如果是硬體介面,則包括邏輯結構、實際位址、預期的行為等。
    • 如果是軟體介面,則包括和其他軟體系統元件之間的介面說明。這些元件可以是採購的元件、來自其他應用程式,或針對本系統範圍以外的子系統開發,但此系統應用程式必須與之互動的重複使用元件。

如需有關 "FURPS+" 以及擷取限制的詳細資訊,請參閱概念:需求

擷取標準依循需求

依循併入時,要包括標準依循(包含法令標準、程式碼撰寫標準或使用者介面樣式準則),以及法律上的免責聲明、保固、版權聲明、專利聲明、文字標示、商標及/或標誌依循標準。

標準需求可以使用其他需求(功能、非功能以及限制)來實現。在這種情況下,那些需求的詳細資料應該依先前步驟的說明,記載在「增補規格」的適當區段中。不過,一定要彙總系統必須符合的標準及原則。所產生的標準依循需求可以視需要,參照適用的詳細需求。 

您可以視所要記載的系統標準依循需求數目,針對會影響系統的每種依循類型提供個別的子區段。

下列區段提供您可能要針對不同的依循標準擷取的兒童資訊的一些範例:

授權需求

定義軟體要顯示的任何授權施行需求或其他用法限制需求。

法令、版權及其他注意事項

說明軟體的任何必要法令免責聲明、保固、版權聲明、專利聲明、文字標示、商標或標誌依循問題。

適用的標準

說明(透過參照)適用於要說明的系統之任何適用的標準及這種標準的特定區段。例如,這可以包括法令、品質和法規標準、使用性、交互作業能力、國際化、作業系統依循等的業界標準。

擷取文件需求

在這個步驟中,您要說明文件的需求,如果需要文件的話。文件需求可以包括線上說明 以及使用者文件(例如安裝手冊、使用手冊、訓練資料等)需求。  

和標準依循需求一樣,文件需求也是其他需求類型的驅動力。尤其是功能需求(系統必須支援存取線上說明的功能)和使用性需求(系統使用資訊的隨需應變存取,支援系統的整體使用性)。   

因此,和標準依循需求一樣,支援文件需求的詳細資料應該依先前步驟的說明,記載在「增補規格」的適當區段中,但另外一件重要的事情,是要記載系統的整體文件需求彙總。所產生的需求可以參照適用的詳細需求。

視系統要記載的文件需求數量而定,您可能會提供子區段來記載對系統提供的各種文件。

內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
主要考量

跨越使用案例的需求(可能是全系統的需求),傾向於成為開發系統架構的驅動力。事實上,在某些專案中,這種需求可能會比和領域相關(或使用案例特有的)的對等項目來得更重要。例如,如果您要開發醫護方面的生命支援系統,其可靠性需求就很重要。

但是這種需求通常很難收集,並且常會因而被忽略了。這項作業說明收集這些需求的整體方法。如需有關使用特定的問卷調查,以「有系統」的方法收集這些需求的詳細資訊,請參閱 [EEL2004]

詳細資訊