準則: 軟體需求規格
軟體需求規格 (SRS) 的焦點在於收集和組織專案的所有相關需求。這個準則說明如何開發 SRS。
關係
主要說明

說明

軟體需求規格 (SRS) 的重點是收集和組織專案的所有相關需求。 如果您有一份需求管理計劃,您應該參考這份計劃來判斷需求的正確位置和組織。例如,對於特定產品版本的每一項 特性,可能必須以個別的 SRS 來描述完整的軟體需求。其中可能包括以系統使用案例模型中的多個使用案例來描述這項特性的功能需求,再加上增補規格中有關的詳細需求。

由於您可能發現您有多種用來收集這些需求的不同工具,因此,請務必瞭解,收集的需求可能會出現在不同的構件和工具中。例如,您可能會發現在增補規格中很適合利用文字記錄工具來收集文字需求,例如非功能面需求、設計限制等。 另一方面,您也可能發現使用案例很適合用來收集部分(或全部)的功能面需求,且利用適合定義使用案例模型的工具也很方便。

文件或套件?

我們發現工具差異並不值得我們特別注意。畢竟您是在收集需求,真正的焦點應該是有效收集和組織需求,而不是所用的工具。由於重點在於需求,不在工具上,我們認為 SRS 所收集的需求可構成資訊套件。系統各種需求的詳述放在一個套件中,我們稱之為軟體需求規格 (SRS)

從願景到 SRS

SRS 套件很顯然與願景文件有關。事實上,願景文件就是 SRS 的輸入。但這兩個構件處理不同的需求,通常是由不同的作者來撰寫。在專案的這個階段中,專案焦點從使用者需求、目的、目標巿場及系統特性的廣泛陳述,進入到如何在解決方案中實作這些特性的細節。

這時我們需要的,是說明系統完整外部行為的構件集合或套件,也就是明確說出「系統要交付這些特性,必須執行這裡的東西」的套件。這就是我們所說的「SRS 套件」。

活的構件

SRS 套件並不是凍結的書冊,為了確保符合 ISO 9000 標準而產生,之後,專案繼續進行,它卻被丟棄在角落裡。相反地,它是一個活生生的、有效的構件。當開發人員開始他們的實作時,它確實有許多用處:它是所有各方之間的溝通基礎,也就是在開發人員之間,以及在開發人員和他們必須溝通的外部群組(使用者和其他關係人)之間的溝通基礎。正式或非正式地,它代表了相關各方之間的合約 - SRS 套件中所沒有的東西,開發人員不應該處理。SRS 套件中的東西,他們有責任交付該項功能。

專案成員的參照標準

SRS 可當做專案管理人員的參考標準。專案管理人員未必有時間、精力或技術來閱讀開發人員所產生的程式碼並立即對照願景文件。他必須利用 SRS 套件作為與專案小組進行討論的標準參考資料。

如先前所說明,它用來作為設計和實作群組的輸入。依專案的組織方式而定,實作者可能已參與了早期解決問題和定義特性,最後並產生願景文件的作業。但在決定他們的程式碼必須執行什麼動作時,焦點正是 SRS 套件。它用來作為軟體測試和 QA 群組的輸入。這些群組也應該參與了某些早期的討論,適當瞭解願景文件中所安排的「願景」,對他們顯然會有好處。但他們的權利是建立測試案例和 QA 程序,以確保開發的系統確實能夠實現 SRS 套件中所安排的需求。另外,SRS 套件也用來作為規劃和測試作業的標準參考資料。

定義功能需求

關於在使用案例模型使用案例內定義功能面需求的建議方法,請參閱準則:使用案例模型準則:使用案例中的完整討論。

定義非功能需求

系統的非功能面需求應該在工作成果:增補規格中說明。以下是定義這些需求時所應遵循的準則。

1 一般

1.1 假設和問題

當收集和驗證非功能需求時,請維護「假設」和「問題」清單。 

有些作業無法提供令您滿意的回答。這可能是因為資訊欠缺,也可能只是您擔心回答會危及設計的可行性。因此,請建立兩份清單,在設計的整個研究過程中都要維護它們:

您在需求和設計流程中所建立的任何假設,其中包括這些假設背後的基本理由或思考過程。這些假設可用來識別在這個專案範圍之外,或在這個專案之後的相關子專案或工作項目。

任何主要問題(可能成為特別精彩的重要考量)

在每個階段結束時,都應該從客戶的角度來檢視這些問題。在每個階段結束時,也必須檢視各個假設,不過,對於較不重要的項目而言,客戶未必是正確的人選。

假設和問題適用於所有工作成果,但它們尤其普遍適用於非功能需求。

1.2 地理組織

請記錄客戶的地理組織。

請說明這個系統所影響商業部分的地理位置。這個定義也應該包括管理主要 ID 機能而未受影響的站台。請特別說明組織的行動式部分。例如,將旅行並使用工作站的銷售人員。 請注意任何您必須提供特殊自然語言支援 (NLS) 的地理位置。

2 給定條件

2.1 預先選取的應用程式套件?

需求指定使用任何應用程式套件嗎? 一個可強力規範某些系統設計決策的非常重要的「給定條件」,是利用特定應用程式套件來提供預先定義的軟體邏輯和資料組織。有些軟體套件非常靈活,可讓您進行多方面的自訂;有些非常死板,不接受任何自訂。套件可能會依照下列方式來規範元件和決策:

  • 工作站類型
  • 連線方法
  • 處理器和直接存取儲存裝置類型 (DASD)
  • 系統控制程式
  • 資料組織、佈置和管理
  • 程式語言
  • 批次介面
  • 流程和資料關係
  • 商業邏輯
  • 畫面設計和使用者介面
  • 效能和可用性等特性
  • 任何現有或必要的列印架構,例如偏好的列印資料格式(如 PostScript、PCL、IPDT)
  • 國家語言支援 (NLS)

請務必瞭解任何給定的套件會如何影響您的設計。如果您有「給定的」套件,請確定您有這個套件的正確知識和技術。來源可能是:

  • 套件供應商
  • 外部顧問
  • 經過專業訓練的設計小組成員

請勿假設知識是現成的。請確定當您需要時,您會有這項知識。

2.2 其他給定條件

請在需求中說明任何其他用來限制設計彈性的給定條件。

這是用來擷取先前的作業未明確涵蓋,但可能限制設計彈性的任何特定需求。請找出下列中的任何一項:

  • 使用現有的處理器或作業系統影像
  • 使用現有的工作站設備
  • 使用現有的網路
  • 使用現有的系統管理作法
  • 使用特定模型,例如:「您必須在設計上使用用戶端/伺服器系統模型來清楚地顯示呈現/商業/資料存取邏輯,以及顯示它們在哪裡和如何連結」。

有任何這些給定條件會影響新系統嗎? 如果新系統要在現有的處理器、作業系統影像或網路配置上執行,現有平台和工作量的特性會影響新系統嗎?

現有的工作量已用了多少連線和處理容量?

現有的工作量使用哪些安全控制? 請記下它們,當您考量新系統的安全需求時,請對照這些需求來檢查它們。

現有工作量的可用性,特性是什麼?

請記下任何可能會影響新系統稍後的可用性設計的東西。例如,現有的工作量是否堅持每個晚上關閉整個處理器?

2.3 特殊硬體

需求指定使用任何特殊硬體嗎?

這可以用通用的詞彙來陳述(「系統必須支援高速的平台繪圖機」),或用更明確的語彙來陳述(「將支援現有的 Panda Corp ATM」)。請儘可能產生下列文件:

  • 任何軟硬體需求
  • 供應商和它們的支援組織
  • 國家語言 (NLS) 考量
  • 加密設備
2.4 現有的資料?

需求是否有指定使用現有資料的使用方法嗎?若是如此,這會影響您的系統設計。請記錄下列事項:

  • 資料目前在哪個或哪些系統中
  • 它的結構(如關聯式或純文字檔)
  • 它的大小
  • 目前哪些使用者和系統在使用這個資料
  • 可用性考量(如資料因資料庫維護或批次作業而無法使用的期間)
  • 這項資料可以移動或複製嗎?

3 標準

3.1 技術架構/策略計劃

客戶有技術架構和/或 IT 策略計劃(或一組相等的標準)嗎?

技術架構大約相等於下列項目:

  • 企業技術平台
  • 企業技術基礎架構
  • 技術架構

在技術架構中,您可能會發現部分已定義好的下列項目:

  • 計算中心的數目和使用
  • 企業的網路連線 (WAN)
  • 特定機構的區域連線 (LAN)
  • 用戶端/伺服器基礎架構服務(中介軟體)的涵蓋面

· 目錄和命名服務,追蹤網路資源和屬性
· 安全服務,透過登錄使用者及授權層次,避免非法使用網路資源
· 時間服務,校準網路上的日期和時間
· 交易管理服務,協調網路中各系統的資源回復

  • 新應用程式將使用的開發方法
  • 一組接受的支援產品,例如:

· 硬體
· 系統控制軟體
· 普遍的應用軟體,例如 "Office"
· 服務中心功能
· 安全規則

  • 列印子系統架構

這份清單可能很廣泛,其中的項目可能非常嚴格地管治,也可能完全不強制。

請記下明確要求或排除使用子架構的任何需求,例如:

  • OSI 或 SNA
  • UNIX**
  • SAA
  • PS/2*,含 OS/2* EE。

使用套裝應用程式解決方案可能會隱含特殊架構。請記住,有些應用程式套件本身便是架構定義。

請記下客戶所需要的開放程度(也就是供應商的獨立自主和交互作業能力)。如果有技術架構,您的設計幾乎是必須符合它。您應該閱讀它,並瞭解將影響這個系統設計的規則。

3.2 網路架構

客戶有這個系統必須符合的網路架構嗎? 網路架構是一組共用的高階連線規則,以及一組共用的傳輸基礎架構。這可能包含中樞網路的定義,其中包括集中程式和線路。如果有這類架構,請瞭解基本規則及拓樸和文件:

實體拓樸的考量(也就是說,網路基本上是農村網路或城巿網路,以及網路連接是密集移入或疏鬆分佈)。

現行網路基礎架構支援哪些高階連線功能。

利用哪些通訊標準(如 SNA、OSI、TCP/IP)來支援這些連線功能。

支援哪些程式設計介面。

用戶端/伺服器層次或基本系統模型層次之間的連線的任何網路架構定義,例如:

  • 用戶端工作站和 LAN 關聯式伺服器之間的關聯式資料存取,必須透過特定關聯式資料庫產品的通訊協定來進行。
  • 呈現邏輯必須一律在工作站中,資料存取邏輯必須一律在集中式主機系統中。
3.3 連線原則

客戶指定了任何連線原則嗎?

即使您沒有任何技術或網路架構,您仍可能會有相同的連線原則。

請說明下列中的任何相關原則:

  • 使用特定通訊協定或通訊機能(供單一大樓內部連線使用,或大樓或組織外部連線使用)。
  • 是否隱含地需要任何特定通訊協定來支援現有的設備或軟體。
  • 是否將使用現有的實體連線機能(也就是安裝纜線或佈線、網路或週邊控制器,以及一般電信業者機能)。如果不是,可用的實體機能類型可能會受到限制(政策、政府章程、實際空間、場地所有權、第三方涉入)。請將這些寫在文件中。
  • 如果可能需要安裝或修改實體機能,便可能需要涉及一或多個協力廠商(如承包人或一般電信業者)。請理解合約或責任的管理方式。如果商業互動會涉及國際連線,這就特別重要。
  • 支援行動使用者。
3.4 其他原則?

客戶有任何未明列在需求中的其他原則、標準或規則嗎? 例如:

  • 使用者的所有新系統介面都必須設計成物件導向的原則,以便接受拖放動作。
  • 所有新的系統都必須以主從式應用程式模型為基礎。
  • 所有新的系統都必須以開放式標準來定義。
  • 國家語言支援 (NLS) 的標準和原則,尤其是由右至左的文字作業之類的事物。
  • 定義使用者身份鑑別、存取控制和資料保護的管理責任和標準的安全原則。
  • 可能隱含使用特殊連線或安全設備的應用程式交換標準(如 UNEDIFACT 或 VISA)。

如果有其他原則,請確定您瞭解它們,能夠取得它們,以便在設計流程稍後階段中,確保您的設計符合標準。使用套裝的應用程式解決方案可能會檢附一些隱含的標準。

讓使用者或部門新增和/或開發他們自己在下列各方面的本端程式的原則是什麼:

  • 工作站
  • 伺服器(尤其是磁碟空間用法)

在沒有控制的情況下,您可能會發現本端的使用情況,很快就耗盡了這些本端元件最初購買時,是為了供它使用的正式作業系統所需要的資源。您可能會發現在最後備妥大規模的部署之時,無法安裝正式作業系統。

4 數字

4.1 「測量單位」

請配合應用程式開發人員將商業流程分解成粒度更好的單元,如較小的商業流程或交易。

執行這個動作是因為您將在下一個問題中擷取數字,且您必須決定您要計數的項目。

請注意,單一商業流程可以啟動較小商業交易的多個實例(如每份客戶訂單有多份項目訂單),當您在文件中記下這些數字時,應該記住這些乘數。不過,不需要太詳細,複雜系統尤其如此。

商業「流程」(如「客戶訂單處理」)通常是由單一「應用程式」(IT 詞彙)來實作,也可能跨越多個應用程式。在每個應用程式內,通常都會有許多 IT 的「交易」,如「查詢股票層次」或「產生客戶信件」。

不同社群會使用它們自己的名稱來識別我們試圖同意的單元。例如,對具備應用程式開發背景的人和基礎架構小組而言,「交易」所代表的意義,可能完全不同。請務必協同運作,使這些名稱產生關聯,再收集資訊。

4.2 「商業量和大小」

請識別 4.1:「測量單位」中每個單位的數量和大小資訊,並產生文件,例如:

  • 在平均時間和尖峰時間,預計會有多少使用者使用每個商業流程或應用流程
  • 尖峰時間是什麼時候(每日、每週、每月等,依適當情況而定)
  • 平均和尖峰時間所需處理的交易率
  • 每個資料群組中的資料元素及實例的數目和大小。
4.3 「商業流程效能準則」

客戶的部分或所有商業流程有可能指定了效能準則。不過,請記住,您也要在文件中寫下系統支援流程(如系統備份)和應用流程開發流程(如果識別出來的話)的效能目標。請在文件中寫下每個種類的下列各項:

  • 每個種類的回應/改變要求
  • 將在哪那裡測量這些項目
  • 在不同時間,能不能接受不同的標準(如離峰/夜間)
  • 在回復或備用期間是否要符合標準
  • 是否需要效能保證
  • 如果效能需求不符合,是否有任何一方會受到影響
  • 表達商業流程被認為可用所需要的最小效能條件(也就是說,在這個點之下,系統會被視為「無法使用」,而不是「太慢」)。
  • 如果已選取了套裝的應用程式解決方案,請確定您能夠取得它的效能特性。您目前不一定需要它們全部,但您應該知道哪裡可以取得它們,因為後續的作業可能會需要它們。協力廠商可能需要花很長的時間來交付您需要的特性,因此,請現在提出要求。

5 可用性

5.1 可用性建議

以下是建議您採用的建立可用性需求的方式:

  1. 識別系統真正的使用者、他們在執行的商業流程,以及他們在什麼時候執行這些流程。
  2. 在使用者完成商業目標的能力上,分析服務可用性(或不可用性)所造成的影響。
  3. 指定直接反映使用者需要什麼才能完成其商業目標的可用性需求。
  4. 請注意,選取套裝的應用程式解決方案之後,它的結構和設計可能會嚴重影響使用者所見到的應用程式的可用性特性。未設計成連續運作的套件可能很難連續運作,在維護和批次視窗上,尤其如此。

當您形成可用性需求時,請考慮這些準則:

  • 指定粒度層次低的可用性需求(例如,依個別流程、使用者群組、資料群組等來指定),而不指定整個系統的「廣域」需求。這會使設計者能夠更靈活配合使用者需求。對於非常需要連續可用性的系統而言,這尤其重要。

以下是一些範例:

  • 「系統必須每天啟動 24 小時來配合紐約和香港的使用者」這句話提供給設計者的設計彈性空間較窄,「紐約使用者必須能夠在紐約時間 7AM 到 7PM 執行他們的資料交易,香港使用者必須能夠在香港時間 7AM 到 7PM 執行他們的資料交易」便比較寬。在後面一種情況中,設計者有維護一個時區的資料或系統元件的靈活運用時間,而另一個時區則仍在它們的正式工作日中。
  • 在 ATM 應用程式中,在星期一早晨 3AM 接受現金存款和提款,可能很重要,在當時提供確實帳戶餘額的能力,可能比較不那麼重要。
  • 區分 DESIRED 的可用性特性和 MANDATORY 的可用性特性。例如,「ATM 必須 (MUST) 能夠每天 24 小時接受現金的存款和提款。ATM 最好 (DESIRED) 能夠每天 24 小時提供客戶的確實帳戶餘額;不過,也可以接受帳戶餘額查詢流程偶而中斷,但期間必須 (MUST) 低於 10 分鐘,且是發生在 3:00 和 4:00 AM 之間」。
  • 如果不符合特定可用性目標的影響,與使用者達成商業目標的能力沒有直接關係,這個目標可能不值得成為系統的可用性需求。
  • 相較於直接反映使用者所感覺的可用性之可用性需求(如「銀行櫃員必須能夠執行 X 和 Y 流程」),只間接反映使用者所感覺的可用性之可用性需求(如「IMS 控制區必須啟動」)往往比較沒用。
5.2 「排程服務時間」

對於每個商業流程和必須執行它們的使用者群組,請識別使用者必須能夠執行這項流程的時間。另外,也請記住,不直接關聯於使用者群組的流程,也要執行這個動作。

如果有在不同時區的使用者群組(如先前的紐約,香港範例),請將他們當作分開的使用者群組來處理。

另外,也要顯示是否偶而(如國定假日)會不需要應用程式。(如此一來,設計師便可以靈活使用這些期間來進行延伸維護)。在應用程式的預估生命期間內,預期這些服務時間會發生什麼變化?

這個系統的服務時間也會受到這個系統連結的其他系統之服務時間所影響。

預期這個系統的排程服務時間在預計生命中會如何改變?

5.3 「服務中斷成本」

請理解在排程服務時間內,服務中斷所帶來的商業影響、財務成本和風險。

如果要識別這個系統真正重要的可用性需求,請考慮商業流程集合與使用者群組,並識別下列原因所可能造成的商業影響:

  • 在排程時間內,短暫中斷或回應時間暫時緩慢到無法接受。當與這個特殊應用關係相關時,請定義「短暫」和「緩慢到無法接受」的意義(請參閱「商業流程效能準則」)。
  • 在上述時間裡(一分鐘、幾分鐘、15分鐘、30分鐘、一小時、二小時、四小時等),各種長期服務中斷
  • 延長服務中斷(轉移、一天、多天等)。
  • 另外,也要考慮不直接關聯於使用者群組的所有流程(如夜間檢查清除)。

當評量各項中斷的影響時,請找出備用程序,考慮它們可以如何降低中斷所帶來的真正商業影響。

請嘗試利用經濟詞彙來量化這個影響(喪失人員或設備生產力的成本、現行業務損失的價值、評估未來因客戶不滿意而失去的業務、利息費用、管理罰款等)。

請提供必要數量的回答來反映各種情況的相關成本和風險的差異:服務在不同期間中斷、在一天的不同時間中斷、服務是計劃性或非計劃性中斷,以及哪些商業流程或使用者會受到影響。

在這個系統的預計生命期間,預期的服務中斷對於業務/財務的影響會如何變更?

請檢視每個這些已取得共識的重要商業流程,以識別出在系統的某些部分暫時無法使用時,可讓這些流程最重要的元素繼續作業的替代方案。在商業功能縮減的情況下仍能暫時運作的能力,可能有助於降低關鍵流程和資料間交互相依性的可用性影響。

以下是一些範例:

  • FULL FUNCTION 1 讀取和更新股票記錄。
  • REDUCED FUNCTION 1 輸入股票記錄和佇列的更新,供未來更新使用。
  • FULL FUNCTION 2 讀取最新的客戶餘額。
  • REDUCED FUNCTION 2 讀取替代來源的客戶餘額,可能不是最新。
  • FULL FUNCTION 3 更新電腦日誌。
  • REDUCED FUNCTION 3 更新列印的紙本日誌。

請記住,當系統使用簡化的功能時,在商業流程可接受的程度上,可能會有限制。例如,過期客戶餘額不能過期超出 24 小時。

如果服務是在排程時間(請參閱「排程服務時間」)內中斷,中斷的影響通常會隨著中斷期間及其他條件而不同。部分中斷情況可能只會些微影響使用者執行他們的商業流程的能力(短暫中斷、一日中使用量較少的期間所發生的中斷、只會影響使用者群組中小部分人的中斷,或有可接受的手動備用流程的中斷)。其他中斷情況,如較長的中斷,或在一日「重要」時段所發生的中斷,可能會有較重大的影響。 

以下是一些範例:

  • 製造生產線控制流程的短暫中斷,對生產力的影響可能最小,因為依照先前所列印的工作次序,仍可以繼續運作,各項變更可以手動寫下,稍後再輸入。不過,中斷超出六十分鐘之後,輪值其餘部分的生產線可能會停工。
  • 高額財務結算系統在交易最後一小時中斷,可能會帶來重大的利息成本或管理罰款。
  • 警察局和消防隊對威脅生命之緊急狀態的回應,如果分派系統無法使用,仍可以利用手動備用程序來繼續運作。不過,由於增加了調度員工作量,可能會增加回應時間,生命會受到潛在威脅。
  • 航空公司或旅館預約系統在尖峰期間中斷,也許不只導致客戶電洽競爭者安排預約而造成現行營業損失,同時也可能因為客戶不滿意的程度,足以使他們在下次需要這些服務時,先打電話給其他航空公司或旅館,而導致未來的營業損失。
5.4 「可用性和回復準則」

請識別在「正常」情況之下所適用的可用性和回復準則。

請排除「災難」情況,例如整個運算機能延長損失或關機時間。

請根據「服務中斷成本」所識別的商業/財務成本及風險來開發必須符合的可用性準則規格,以避免嚴重影響使用者群組,使他們無法執行指派的商業流程。您可以依照下列形式來指定這些準則:

  • 在給定的分鐘/秒數內回復中斷的百分比
  • 在給定星期/月份/年份內,使用者無法執行特定功能的時間上限

請依照需要,儘可能明確反映各種因素,例如計劃性和非計劃性中斷的差異、發生中斷的時間(如「重要」時段和使用量少的期間),以及所有使用者或只有少數使用者受到影響等。

請小心避免不必要地指定最強的可用性準則,因為這可能嚴重影響實作成本。一般而言,如果無法利用一組給定的中斷狀況來識別重大商業/財務成本或風險,可能表示這組給定的中斷狀況不應併入所說明的可用性準則中。

如果「排程服務時間」建議指出排定的服務時間可能會改變,且/或「服務中斷成本」建議指出,在系統的預計生命期間,服務中斷的相關商業/財務成本或風險可能會改變,請評估可用性準則會因而有什麼改變。

如果使用加密的話,會有其他回復和可用性考量。例如:

  • 回復秘密資訊的功能可能在系統之外。
  • 必須確保受密碼保護的資料會配合適當加密金鑰的回復而一併回復
5.5 「災難回復?」

在這個設計專案的範圍內,需要災難回復嗎「災難」狀況期間的可用性(例如整個運算機能延長損失或關機時間)?。若是如此,這類回復的準則是什麼?

請注意,大概不是所有商業流程都需要災難回復機能。請只選取重要且確實需要災難回復的流程。即使在這些流程之內,也不見得需要涵蓋所有功能。

  • 還原服務必須多快? 這是從災難發生之時開始測量,或從決定移至遠端站台開始測量?
  • 在哪些情況之下,組織會決定在遠端站台回復,而不是在本端回復?
  • 遠端站台的資料必須多新,才能繼續營運(絕對最新、在失敗的幾分鐘之內、可接受舊日資料)?
  • 何時開始從遠端站台還原服務?
  • 在日後的某個時間點?
  • 對照相依於相同運算機能的其他商業應用程式,這組應用程式的遠端站台回復優先順序為何?

請注意,不同的系統組件可能會有不同組的準則,這也可能隨著災難類型而不同。

在應用程式的預計生命內,預期上述災難回復需求會有哪些變更?

5.6 「其他可用性設計考量」

如果要將系統設計成會儘快還原,設計者必須知道他們在實作應用程式時,仍能夠符合應用程式功能需求的彈性空間。以下是對設計者有用的問題:

1. 如果要容納必要的維護作業,系統在短期的作業中,它會:

a. 執行查詢,但不更新嗎?

b. 接受使用者的更新要求,但在維護作業完成之前,不實際更新 DB 嗎?

2. 面對需要回復資料的中斷,執行哪一項比較重要:

c. 儘快還原服務,即使這代表使用並未完全保持最新的資料也一樣,或:

d. 在還原服務之前,先將所有資料回復到目前的狀態,即使要花比較多時間也一樣?

3. 如果失敗時,使用者要求「在進行中」,在服務回復之後,可以靠使用者來重新輸入要求嗎?

4. 有任何非技術的考量可能影響這個系統的可用性嗎(例如,商業原則指出,除非 B 流程也能使用,否則,不能將 A 流程提供給使用者)?

有任何上述設計考量預計會在一段時間內變更嗎?

對於企業的關鍵流程而言,找出一個替代方法,讓這些流程的最重要元素,即使在系統的某些部分暫時無法使用時,仍然能夠運作,會很有幫助。在商業功能縮減的情況下仍能暫時運作的能力,可能有助於降低關鍵流程和資料間交互相依性的可用性影響。

6 安全

6.1 「安全需求」

1. 識別要保護的資料

2. 識別每個資料類型所面對的威脅類型:

  • 意外毀損或消滅
  • 蓄意毀損或消滅
  • 商業情報
  • 詐欺
  • 駭客入侵
  • 病毒

1. 識別對於實際安全的威脅:

  • 偷竊元件
  • 未獲授權的實體存取
  • 使用者的實體安全

2. 識別這些威脅的可能來源人士:

  • 資料中心人員
  • 其他 IT 人員(如開發)
  • 組織的非 IT 人員
  • 組織外的人

3. 識別任何特殊或不正常的安全需求,尤其是下列方面:

  • 系統存取
  • 資料加密
  • 審核性

4. 有任何一般原則(如「資訊自由」法案)可能影響這個系統的安全設計嗎?

5. 部分套裝的應用程式解決方案會有他們自己的安全子系統。如果您有一個「給定的」套件,請注意它的安全機能。

如果要建立和分類安全需求,您可以使用下列方式:

1. 列出需要邏輯或實體安全保護的物件。

2. 識別與每個物件相關的漏洞。一般種類如下:

  • 檢視存取(機密性缺口),如帳戶資訊、客戶名單、專利等。
  • 更新存取,也就是修改資料來欺騙、掩飾和轉移資金。
  • 資產損失,也就是為他人所佔有,擁有者無法再使用資產(有別於因災難而損失)。例如:客戶和前景清單、合約等。

請注意,並非所有物件都對上述所有漏洞敏感。

3. 識別所有與環境相關的威脅。例如:

  • 不高興的員工
  • 未獲授權的員工
  • 在公開場合開啟終端機階段作業
  • 駭客
  • 線路監控
  • 遺失設備(如可攜性 PC)

4. 建立每個物件所適用的威脅,將它關聯於特定漏洞。

請注意,您可能必須檢視在靜態位置(如硬碟)和在傳輸中(如在傳輸期間)之物件的安全需求。

由於設計可能將物件的位置延伸到不安全的區域,因此,您可能必須重新造訪這個主題。

某些系統設計安全方面的要求非常高。它們可能會支配您的設計決策。它們可能使非常好的結構和元件選項成為不可接受。因此,請現在就明確決定,您在設計的系統是否有特別強的安全需求。例如:

  • 機密的軍事系統
  • 高價值的轉帳系統
  • 處理機密個人資訊的系統

如果您相信您有特殊安全需求,您應該找一位安全專家或工作者來協助您設計系統的各個方面。

7 使用性

使用性需求定義使用者介面的使用性必須有多高。

使用性需求應該設成系統必須達成才能使用的最低可用性層次。它們不應設為您相信系統能夠達到的程度。換句話說,您不應將可用性需求視為一項目標(上限)。可用性需求應該定義絕對最低而可接受的系統可用性。因此,可用性需求實現之後,您不應該停止改進可用性。

系統應該達成什麼才能使用,大體上,取決於系統的替代方案是什麼。系統應該比替代方案有用得多,是一項合理需求。替代方案可能是使用:

  • 現有的手動程序。
  • 舊式系統。
  • 競爭產品。
  • 系統較早的版本。

使用性需求也可能來自需要在經濟上證明新系統合理:如果客戶必須為新系統支付美金三百萬,他可能會想強加因人力資源工作量減少而能夠每年省下美金一百萬的使用性需求。

以下是一般使用性需求範例:

  • 最大執行時間 - 訓練過的使用者要花多少時間來執行一般情境。
  • 最大錯誤率 - 訓練過的使用者平均一般情境會有多少錯誤。
    只有無法復原且會對組織造成負面影響(如失去業務或造成所監視的硬體損壞)的錯誤,才與測量相關。如果錯誤的後果只是需要花時間修復,這會影響所測量的執行時間。
  • 學習時間 - 使用者要花多久,執行情境的速度才能夠比指定的最大執行時間快。

以下是「管理送入的郵件訊息」這個使用案例的部分特定使用性需求範例。

  • 郵件使用者應該只按一下滑鼠,就能夠排列郵件訊息。
  • 郵件使用者應該只按一下鍵盤按鈕,就能夠捲動郵件訊息文字。
  • 郵件使用者在讀取現有的郵件訊息時,不應受到送入郵件訊息的干擾。