處理NFR(非功能需求)的常見錯誤及其糾正方法

常見錯誤	糾正錯誤	舉例
沒有充分注意NFR，因為它們無法在視覺上建模	NFR應被視為功能要求的重要性; 提取NFR的方法是建立原型（例如，技術，介面，業務）。	請參閱本章的早期討論和第16章中的原型設計。
沒有意識到軟體解決方案的使用者體驗在很大程度上取決於其NFR	舉辦一系列正式研討會，記錄NFR。	重新審檢視20.1至20.3，以瞭解NFR的深度和廣度，並寫出與每個標題相對應的實際要求。
假設安全性是一個完全獨立的實體，可以稍後以某種方式新增到正在開發的軟體解決方案中	開始討論每個用例和每個活動圖的安全性。	請參閱本章中的討論，然後重新訪問用例文件以增加安全性。
只有在系統開發生命週期結束時才會測試卷和效能	特別是這兩個NFR不能等待系統完全可執行。 相反，開始使用軟體版本的初始模組測試這些要求。	請參閱本章中的討論。
NFR都處於同一水平	NFR處於不同的級別，因此需要在相關級別的組織，專案，流程，用例和資料中進行記錄。	各種NFR水平見圖20.3。
可用性與使用者體驗相同	可用性涉及設計的精確性; 使用者體驗是使用者從系統中獲得的總體結果。	請參閱本章中有關可用性和使用者體驗的討論; 還重新討論了第16章的討論。
雲旨在處理資料儲存	雲端計算是大多數新軟體應用程式的組成部分。 雲不僅可以處理資料，還可以處理分析和處理。 雲還促進了系統，資料庫和企業之間的協作。	請參閱本章關於雲的討論。

非功能（操作）要求規範和應用

NFR解決了諸如正常業務事務下的整個系統的效能，用於改變客戶數量的系統的可擴充套件性以及基於web的架構上部署的系統的安全性之類的問題。此外，安全性，數量，服務質量（QoS）和可維護性也是NFR的一部分。系統的引數不是其功能（工作流程）的一部分，但對於良好的使用者體驗至關重要，這是NFR討論的重點。

◾使用UML NFR和UML的軟體工程

上述操作（非功能）需求不能用例如用例或活動圖建模。 UML沒有針對NFR的特定建模構造（符號或圖表），因為它的主要重點是對功能（行為）要求進行建模。但是，NFR可以在UML圖中以各種方式出現。例如，註釋，約束和標記用作使用NFR註釋UML圖的機制。架構（背景）建模空間中的元件和部署圖最適合描述其中的NFR。

特別是UML的註釋功能在指定NFR方面有很大幫助。 Notes用於用例，活動和類圖，以突出顯示系統的操作需求。例如，用例圖中的註釋突出顯示該用例在一天或一年中的最大使用者數。

NFR的來源組織的建築和運營限制是NFR的主要來源。例如，擁有Windows 8作業系統的限制（約束）會影響在組織中部署軟體解決方案的方式。因此，軟體解決方案必須能夠在整個組織的Windows 8上執行。智慧手機的作業系統（例如，iOS或Android，加上相應的版本號）是組織的策略規定了該系統的操作要求的另一個例子（在這種情況下是移動應用程式）。

組織的企業體系結構（EA）限制內容的型別和大小，分析，知識建立和客戶互動。這些EA因子是NFR的重要來源。組織的技術邊界和侷限性影響NFR。

除了開發的軟體的操作要求之外，一些額外的約束也會影響NFR。這些是專案和組織級別的約束，與直接屬於軟體解決方案的約束不同。以下是影響軟體專案中NFR的一些因素的示例：

◾組織的現有技術環境，其功能和侷限性

◾軟體專案中使用的現有工具和技術

◾當前的專案背景，預算，資源及其侷限性

◾專案的型別，大小和重要性

◾操作軟體解決方案的過程

◾影響系統開發和部署方式的法律和合規專家（即律師），提供繫結解決方案的另一個操作要求來源這些NFR最終會影響終端使用者的感知。軟體解決方案的前端（例如在網站或移動應用程式上）受其後端效能引數的限制。例如，如果應用程式的網頁由於低頻寬而凍結，則使用者不感興趣或不能感知該基礎非功能引數。使用者的整體感知稱為“使用者體驗”，由於操作效能差而受到影響。 NFR對於增強使用者體驗至關重要，它們在軟體建模和開發中應該得到獨立和專注的關注。

非功能引數的型別圖20.1顯示了系統中最常見的非功能引數的示例。這些非功能性引數在軟體開發的早期階段被陳述為要求。

系統的NFR不是孤立的，獨立的要求，即使它們在這裡如此呈現。相反，這些NFR彼此依賴，並且基於EA的約束一起應用於軟體解決方案。

以下是NFR的摘要（如圖20.1所示）。本章稍後將詳細討論這些NFR中的每一個：

◾效能（頻寬） - 通常根據系統預期的響應速度來指定。基於Internet的部署的效能要求取決於可用頻寬。例如，可用處理能力和要處理的資料量等因素也會影響效能。

◾可擴充套件性（時間） - 系統隨時間的預期增長和使用。隨著使用者數量的增長，可擴充套件性包括系統引數，例如資料儲存和與系統相關的效能。可擴充套件性要求取決於時間因素（第二天，一個月或一年的增長和需求）。

◾卷（資料庫） - 例如，系統執行時預期的資料庫大小。當前使用的資料空間以及操作資料庫的備份和映象是此要求的一部分。

◾可用性（QoS） - 這些要求的示例包括允許的維護停機時間，允許系統離線的次數以及不同型別系統故障的預期QoS。

◾可操作性（平臺） - 目前執行的幾乎所有系統都需要後端作業系統和前端瀏覽器技術。此要求指定操作平臺的型別和用於系統的瀏覽器。由於動態改變裝置和位置（在移動介面的情況下），瀏覽器的規格變得非常重要。整個範圍的瀏覽器和作業系統及其版本對於指定此NFR至關重要。

◾可訪問性（裝置，物聯網） - 這些NFR處理使用者裝置的易用性。這種易於訪問需要考慮可能有特殊需求的使用者（例如，如果要求使用者輸入驗證碼字元以驗證它們不是機器人，那麼這些字元也應該以音訊格式提供以確保某些使用者不會處於不利地位） 。可訪問性不僅限於使用者的需求;它也是一個強制性的監管要求（本章後面會討論）。

◾可靠性（信任，風險） - 此NFR基於系統的關鍵性。例如，飛機導航系統可以具有更接近十二西格瑪（相對於六西格瑪）的可靠性規範 - 隱藏十億分之一，而不是百萬分之一的缺陷。

◾環境（碳） - 環境意識在商業中日益增加的重要性意味著需要指定系統的碳含量。雖然一些業務系統可能不會直接導致碳排放，但它們對後端資料伺服器的影響越來越多地計算在組織的整體碳排放中（Unhelkar，2011）.1或者，碳排放管理系統對其排放有更詳細的規範。碳容量被指定為非功能性和功能要求。

◾法律（合規） - 金融系統總是要求跟蹤和審計。雖然其中一些要求本質上是功能性的（例如，記錄審計員的詳細資訊），但其他處理建立審計跟蹤和備份的要求可能無法直接起作用。相反，法律要求被指定為無功能，需要仔細的演練和檢查，以便在系統中進行驗證。

前面的NFR中的每一個都受到四個其他非功能（操作）引數的影響。這四個引數如圖20.1所示（本章稍後將對此進行更詳細的討論）。這些非功能性引數如下：

◾安全性（級別） - 此要求差異很大，從系統中的特定功能或用例到訪問其Web門戶的組織策略。

安全要求的示例包括加密（例如，128位），密碼策略和瀏覽器要求。

◾可用性和使用者體驗 - 此要求適用於圖20.1中心所示的所有其他要求。雖然可用性本身涉及系統的典型使用者介面的易用性，但是使用者體驗處理在通過系統與組織互動時使用者的整體“帶走”。因此，圖20.1中間的所有非功能性引數都會影響使用者體驗並受其影響。

◾大資料（速度和變化） - 這在圖20.1中顯示為更高級別的要求，它影響並受該圖中心的所有其他要求的影響。雖然與大資料相關的要求較新（與早期的程式和麵向物件的軟體工程方法相比），但重要的是要將這些要求納入任何新系統的總體NFR中。進入系統的資料速度尤其如此 - 例如當物聯網裝置（健身腕錶，血壓監測裝置或碳排放記錄裝置）收集資料並將資料傳送到系統時。此外，由於資料 - 音訊，視訊和圖形的多樣性，大資料還增加了非功能引數的挑戰。

◾雲端計算在NFR討論中提供了一個重要引數，因為大多數新軟體系統（包括特別是移動應用程式）將其資料儲存在雲中。即使是擁有內部資料庫的企業系統也會將這些資料庫遷移到私有云。例如，容量，可用性，可伸縮性和可靠性引數受雲端計算架構的影響。隨著雲端的後端資料和處理（分析）也轉移到雲，系統的可用性及其可靠性取決於雲的可用性以及承載連線到雲的中間網路。

NFR的複合敏捷方法和策略以及原型製作第4章討論的複合敏捷方法和策略（CAMS）鼓勵對解決方案進行詳細討論，建模和原型設計，以便能夠處理這些NFR。第16章討論了原型設計在建模軟體中的重要作用。

原型設計可以模擬應用NFR的技術環境。

因此，在專案開始時，為NFR建立原型變得至關重要。業務分析師與技術和業務專家合作建立原型，並通過測試確保在系統完全開發和整合時最終滿足NFR。例如，在發現應用程式完全開發後，128位加密不適用於特定應用程式是沒有意義的。通過建立技術原型，在專案中儘早測試NFR。

為了幫助改進估算和假設，CAMS建議在專案早期正式讓業務分析師和使用者參與進來。建築師和解決方案設計師與業務分析師一起探索NFR並進行他們的概念驗證原型。業務分析師與業務利益相關者，架構師和解決方案設計師密切合作 - 特別是在NFR方面 - 是CAMS在實踐中的重要組成部分。

NFR類別：質量和約束NFR大致分為兩部分：執行中系統的各種“質量”或屬性以及系統上相應的“約束”。

圖20.2顯示了這兩個主要類別的NFR：約束通常來自EA，而質量往往是在系統架構級別指定的。

約束：

◾這些是系統架構和設計的限制。在系統架構和設計期間遵守約束可確保部署的系統在這些組織引數內正常執行。各級限制的示例包括： - 組織（例如，100 mbps頻寬） - 專案（例如，350 k預算） - 時間範圍（例如，必須在某個日期之前生效）質量：

◾組織（例如，3秒響應時間）

◾專案（例如，每個需要進行演練的要求）

◾可接受性（例如，每百萬1個缺陷;或每天23小時58分鐘的正常執行時間）業務分析師以及關鍵業務使用者和架構師，可以很好地調查和指定這些NFR。此外，業務分析師還可以概述這些NFR的驗收標準（測試）。

系統的質量（偶爾也按照各種“能力”分組）由業務分析師與使用者和領域專家合作指定。對系統的約束通常由瞭解適用於系統的組織引數的企業架構師決定。

NFR挑戰NFR在開發生命週期的早期階段有被忽略的趨勢。偶爾會發生這種情況，因為這些NFR不是系統的行為，因此不容易記錄和建模。

NFR的另一個困難是，當系統的至少某些部分已經開發時，它們開始變得相關。例如，指定和測試系統的效能不是用UML圖建模的;相反，它只能在系統在生產等效環境中可用時進行驗證。

因此，關鍵業務利益相關者和領域專家之間的互動是獲取NFR的必要條件。然而，即使這些相互作用也不足以在專案開始時成功捕獲NFR。這是因為當涉及到NFR時，專家會做出有根據的估計（猜測）以確定NFR。例如，預計在銀行應用程式的第一年（10,000？或100,000？）開啟的帳戶數量可以是“任何人的猜測。”估計是在專案開始時進行的，然後作為迭代和增量進行細化。系統的發展進步。 NFR的迭代和增量方法確保系統的體系結構能夠處理NFR。

由於NFR中涉及的猜測工作，將這些要求與相應的假設配對也是一個好主意。以預計將在第一年開設的100,000個賬戶為例，當與線上營銷和銀行的社交媒體相關時，假設可以相當準確。可以看出，這些要求對於滿足系統使用者在操作中的需求和“體驗”以及最終的接受度是至關重要的。

組織系統和專案功能和用例資料和類專案（例如，35萬美元預算）專案（例如，每項要求需要演練）組織（例如，3秒響應時間）組織（例如，100 mbps頻寬）約束質量NFRS圖20.2兩個主要類別的NFR競爭約束（架構師說明系統不能做什麼）和質量（業務利益相關者在功能中說明他們對系統的要求）。

在CAMS中捕獲NFR業務利益相關者和領域專家參與通常由業務分析師組織的研討會，以發現這些不熟悉和不明確的要求。對於NFR缺乏標準化的建模構造（特別是在純粹的敏捷方法中）也意味著它們不是在視覺上建模的。此外，業務利益相關者可能不會完全瞭解NFR。

系統所需的正常執行時間或實現正常執行時間所需的資源可能在專案開始時仍然不確定和未建模。在需求建模研討會上開放關於NFR的討論是開始捕獲這些NFR的理想方式。例如，如果企業要求對其新解決方案（系統預期的效能相關質量）的響應時間為3秒，那麼企業架構師可以說：“不，這是不可能的，因為我們只有具有一定的頻寬可用 - 100mbps。“一旦討論（雖然不一定要整理或解決），它為業務利益相關者提供了增加預算以實現他們期望的解決方案質量的大門。或者，降低他們的期望。如果這些NFR在解決方案的後期階段保持不變或未被討論，那麼解決方案的期望和提供將不匹配。

CAMS和NFR測試功能和非功能需求之間沒有一對一的關係。

但是，仔細檢查功能要求總能對NFR產生影響。許多NFR適用於專案和組織層面，但不適用於單個功能層面。這可能是NFR通常落後於功能要求的另一個原因。測試NFR也可能落後 - “因為沒有系統，所以沒有太多可以檢查效能。”在CAMS中鼓勵建立可以測試NFR的系統的早期原型。企業架構師和解決方案設計人員可以一起工作來載入資料庫並針對這些測試資料庫執行原型，而不僅僅關注功能需求的實現。這是NFR規範（包括效能，可擴充套件性和安全性）的方式，以及它們在解決方案中的結合是在CAMS中實現的。

由於NFR適用於整個組織，因此業務利益相關者可能無法完全理解這些要求應用於軟體系統的級別。業務分析師強調NFR及其與成本和時間的關係。業務利益相關者對系統的期望質量需要具有相關的成本和時間，這兩者都會隨著業務預期的增加而上升。請注意，這些不是新的預期功能，也不與這些功能的更高質量相關聯（需要更高的測試嚴格性）。 NFR中的這些特性是系統執行時的特徵。系統對NFR的更高要求具有相應的成本和時間，需要在專案中加以考慮。

例如，利益相關方同意儘可能高的安全性，24×7正常執行時間以及映象資料以提高全球效能。除非業務分析師顯示這些NFR中的每一個與實現該要求所需的相應成本和時間之間存在直接關係，否則隨著專案的進展，這些NFR將繼續出現（並且增加）。

◾具有UML NFR級別的軟體工程NFR不限於系統。相反，NFR來自組織內的各個級別並在其中應用。瞭解NFR的適用性水平最有助於確定它們在何處以及如何影響正在開發的系統。 NFR可以是整個EA的一部分，適用於特定系統級別，或應用於單個功能單元。確定NFR的級別並將其用於企業和系統架構以及這些架構的相應驗證和驗證非常重要。

圖20.3顯示了各種NFR水平：

◾組織級NFR適用於整個組織。因此，組織級NFR適用於為組織開發（或採購）的所有專案和系統。這些NFR的示例包括與電子訪問，可用頻寬，資料倉庫資源和與使用者相關的HR要求相關的策略。

◾專案（解決方案） - 級別NFR與專案產生的解決方案相關。這是整體解決方案，不僅僅是軟體系統。例如，與解決方案相關的操作程式和規則可以在此級別指定為NFR。這些是適用於解決方案的規則。 （注意：這些與軟體解決方案中嵌入的業務規則不同。）在軟體系統級別指定時，這些NFR適用於軟體解決方案的開發，部署和操作。例如，特定作業系統的要求或瀏覽器的版本號是可以涉及軟體系統的操作但不一定涉及整個組織的要求。

◾流程（業務，系統） - 級別NFR是管理與解決方案相關的流程的一部分。因此，這些要求包括不屬於任何視覺模型的詳細業務規則。描述解決方案對系統的其他（通常是外部）元素的依賴性的系統級技術規則是此級別NFR的一部分。將規則與流程級NFR相關聯的原因是這些規則在整個流程中應用，無法在視覺上建模，並且嵌入在解決方案中而沒有對使用者的直接可見性（因此，沒有介面）。儘管流程規則具有隱藏的性質，但它們需要被指定為NFR的一部分。

◾用例（功能）級別NFR是適用於個別用例級別的要求（與上述適用於流程級別的規則和要求相比）。由於業務流程可以包含許多用例，因此此功能級別的NFR有助於資料套件（基礎）用例（功能）流程（業務，系統）軟體系統專案（解決方案）組織圖20.3指定與軟體解決方案關聯的NFR並應用於組織內和專案的各個層面。

區分僅適用於一個用例的要求。例如，整個庫存過程總體上可能有嚴格的稽核要求;但是，與特定用例的審計相關的NFR可能沒有相同嚴格的審計要求，這些用例涉及內部員工將庫存從倉庫移到店面。因此，用例級NFR修改或專門化適用於整個過程的NFR。

◾資料套件（基本）-NFR這裡涉及一條資料或包含資料的表。

資料套件的NFR也適用於整個資料庫。例如，與賬戶（典型銀行應用程式）中的金額欄位相關的NFR可以指定對四個小數點的合法（合規）需求。資料庫級別的另一個NFR可以指定需要建立整個資料庫的映象，以確保提高關鍵業務功能的效能和可用性。

本章的其餘部分詳細介紹了迄今為止討論的一些重要的NFR。

效能效能要求指定軟體解決方案所需的速度或響應時間。

該效能標準在確定系統的效率和有效性方面起著重要作用。因此，該效能標準有助於整體使用者體驗。在大型複雜系統的情況下，子系統有自己的效能要求。例如，HMS中與患者相關的外部過程的效能要求是嚴格的（每頁3秒），但對於內部員工相關過程，它可以更放鬆（每頁5秒）。

在建立MOPS的早期階段，應該謹慎地定義系統的效能標準。在開發的早期階段，系統（特別是大型和複雜系統）分為子系統和包（第3章）。為每個子系統指定效能標準，然後將標準應用於整個系統。

將效能標準的規範留待以後是專案風險，因為一旦開發出解決方案，就很難對其進行重新架構和重新設計以滿足效能標準。軟體過程的迭代和增量基礎在處理與NFR相關的風險，特別是解決方案的效能方面最有價值。

UML模型具有直接的標準化機制來顯示效能要求。然而，CAMS鼓勵在故事卡上記錄NFR，其正常格式是列出系統的功能要求。 PRIMA-UML2等方法值得專案團隊探索，試圖在早期建模階段獲得性能要求。

響應時間和效能對於大多數實際用途，系統的效能等同於響應時間 - 即系統處理使用者請求所花費的時間。無論正在執行的處理型別如何，終端使用者都在尋求越來越快的響應時間。使用者的需求基於使用系統的越來越多的專業知識，他們需要執行的功能越來越多，以及影響系統和裝置的人類需求的心理社會因素。因此，使用者不斷增長的需求是系統可擴充套件性要求的一部分，需要將其納入關於系統預期效能的討論中。

如果不考慮影響效能標準的許多因素，系統設計將無法滿足使用者要求的效能目標。缺乏良好的系統性能可能會損害客戶與組織的關係（例如，當系統響應不佳時，客戶將總是拒絕系統）。內部組織流程也因系統性能不佳而受到影響，從而導致生產力下降和收入損失。如果系統需要重新設計以提高其效能，則專案將產生額外成本以及相關的機會成本風險（由於錯過了市場視窗）。在極端情況下，整個解決方案都會被廢棄，因為效能調整工作可能還不夠，專案可能需要取消。

效能挑戰的出現主要是由於在軟體開發生命週期（SDLC）的早期階段缺乏對NFR的關注。缺乏關注可能是由於難以從使用者那裡引出實際的效能要求。由於效能測試需要模擬技術環境（充足的資料庫和執行系統），因此該測試也會在SDLC中推遲。此外，通過在構建軟體系統中使用外部的，可重用的面向服務的元件，效能問題也可以依賴於那些外部服務。最後，通訊機制（包括網路協議，安全需求，資料量和資料速度）也會影響系統的效能。

系統設計人員在設計系統時需要牢記使用者的“期望時間”。重要的是要向用戶傳達要求更高效能時間與滿足這些需求相關成本之間的平衡。系統響應的隨機預期時間對於設定系統的目標和設計沒有幫助。此外，響應時間不應太快以至於無法逃避使用者的注意力。

效能要求及其滿意度是技術，設計和開發以及使用者期望之間的平衡。

響應時間和效能分析Miller（1968）3在他關於人機互動響應時間的研究工作中詳細討論了各種功能的基本響應時間。使用者認為必要的預期響應時間幾乎是瞬時的約0.1秒。這種情況發生在不需要特殊反饋的情況下，所需要的只是顯示結果。一秒鐘被視為系統在中斷使用者思維流程之前可以允許的最大延遲。即使感覺到這種延遲，也不會破壞使用者對他/她任務的關注。十秒是最大時間範圍，使用者應將注意力集中在對話方塊（進度指示器）上。這提供了流程的預期完成時間，因此使用者不會失去耐心並開始處理其他任務。

外包專案和績效影響績效的一個重要因素是軟體開發外包。通常，外包工作等同於優勢，包括顯著節省成本，培訓IT人員的可靠性，靈活的資源利用率以及最低的設定成本。常規的低級別任務可能會佔用公司資源的很大一部分，這可能是利用外包的一個原因，這可能會大大減少執行這些日常低級別任務所需的資源量並間接降低公司資源花費。

儘管外包提供了多種優勢，但是存在多種挑戰。例如，如果外包供應商無法理解需求，特別是在敏捷專案中，無法協同參與開發，則整個系統的效能會受到影響。

服務級別協議（SLA）直接適用於效能分析。 SLA應明確說明所需服務的範圍和性質。還應明確說明表現水平。吞吐量時間，週轉時間和系統可用性等因素是直接影響系統性能的一些關鍵問題。一個完善的，裝備精良且高效的供應商可以從系統的早期需求階段參與，比僅僅簽約“程式碼”的供應商更好地理解效能需求。頻寬組織級別的頻寬可用性與系統性能。

頻寬可能是組織本身的IT基礎架構對系統的約束。現有的組織通訊網路和將攜帶軟體解決方案的網路是效能不可或缺的。此外，需要研究，建模資料通訊過程（例如向/從雲傳送和接收大資料）並將其合併到系統設計中。頻寬可以對及時傳遞資訊產生關鍵影響。

網路頻寬是在給定時間內提供一定數量資料的能力。

應用程式要求組織內部和外部的高頻寬負載網路。

軟體解決方案的頻寬規格應包括最低可接受的資料傳輸速率。然而，這種傳輸速率需要根據不同的負載而變化 - 這可以根據一天中的時間，訪問位置和其他因素而變化。在示例HMS中，即使在64kbps的頻寬下，僅交換靜態和資訊的模組也可以執行。 HMS模組進行密集分析，涉及病人視訊剪輯和醫學影象等多媒體資訊的傳輸，需要更高的頻寬，如4 Mbps。

可伸縮性可伸縮性是系統的NFR，用於逐步增加工作負載。由於來自使用者的預期響應時間仍然相同，因此係統需求的擴大對其資源施加了約束。與可伸縮性相關的問題成為一個問題，特別是當系統執行成功時，因為系統提供價值越成功，使用者對其服務的需求就越大。可擴充套件性要求涵蓋範圍：擴充套件到越來越多的使用者，分析，使用者介面和多媒體功能的分佈，資料傳輸和儲存，以及終端使用者裝置訪問及其使用。

因此，可伸縮性既可以是技術要求，也可以是基於所使用的功能的業務需求。因此，可擴充套件性是可以在用例文件中輸入的要求，作為在系統啟動後的月，季度或年中可能使用該特定用例的使用者的估計。

從技術上講，可擴充套件性要求可以指定通過網路分配和平衡資料工作負載的技術和工具。此資料分佈還有助於通過多個通道和並行會話進行傳輸。由於網際網路和電子商務網站以指數級增長，因此可擴充套件性是專案可持續性中要分析的核心問題之一。

平衡擴充套件技術資源（尤其是基於雲的資源）可以改善訪問協議，儲存資金的價值以及專案所有者利益相關者的總體滿意度。

可伸縮性和硬體可伸縮性問題也可能具有硬體限制。為了應對更高的負載，可能需要新增更多處理器或更多伺服器，具體取決於存在的問題型別。每個附加處理器都可以提高整體伺服器效能。此外，良好的多執行緒架構技術可以幫助負載分配並提高系統性能，從而實現良好的可伸縮性。電子商務網站在後端涉及高水平的查詢，這是一項耗費資源的任務。一個常見的過程是使用單獨的資料庫伺服器，例如，從中央伺服器中刪除一些負載。

系統的體系結構應該足夠靈活，以允許新增額外的硬體，因為這有助於專案的可伸縮性。架構空間模型中使用的部署圖應該有助於開發一個沒有可伸縮性問題的穩定系統。

HMS可擴充套件性要求示例HMS的可擴充套件性要求的示例包括這樣的情況：例如，系統最初每天處理1000個事務，在釋出後3個月，系統需要按比例放大以每天處理5000個事務。雲端後端資料庫空間的初始釋出容量為1 TB;隨著醫療資料的多媒體和相關內容呈指數增長，後端容量需求將在第一年增長到5 TB。此後，需要密切監視資料需求，以確保系統可以擴充套件以處理資料儲存和處理的需求。

卷容量要求指定系統所需的總資料大小。該捲包括本地資料庫，基於雲的伺服器，本地儲存在計算機和智慧手機上的資料等。隨著大資料和相應雲技術的進步，資料的數量（大小）對於系統的成功變得更加重要。

預計HMS將被員工和患者大量使用。網站交易的粗略估計是每天500。 HMS需要有效地處理資料 - 它們的攝取，質量，傳輸和安全儲存。基於雲的伺服器可以處理HMS的負載 - 從伺服器上的1 TB空間開始。體積需求的估計基於每天新患者（100）和返回患者（150）的數量，這些患者在其手術的第一年由HMS專門處理。除了患者的個人詳細資訊外，還有大量的多媒體資料，如外科手術，產前視訊，恢復方法，其他健康相關視訊，音訊，圖片和圖形的視訊，需要以各種格式儲存。

作業系統系統的作業系統（OS）和相應的操作環境在專案開始時確定。這些作業系統要求並不像其他一些NFR那樣難以確定。但是，決定作業系統及其版本對於開發工作至關重要 - 使用者和系統架構師需要一起討論這一要求，使用者指定他們為什麼需要在特定操作平臺上執行的解決方案以及實現該操作的架構師組織給定引數內的要求。

除了現有的操作系​​統和環境之外，還需要結合相容性和未來增長問題來處理此要求。舉一個簡單的例子，為Windows平臺開發的系統無法在UNIX環境中工作，並引發相容性和可移植性等問題。通過使用相容介面，資料仍然可以作為服務傳輸到這些異構平臺上;但跨多個平臺執行系統是一個關鍵的NFR，需要業務和技術輸入。

對於HMS，使用者，業務分析師和軟體開發人員聚在一起決定Windows操作平臺最適合當前使用者群（通常是員工）。

這些利益相關者還為系統的成功執行設定了最低工作條件，例如Windows 7或更高版本。瀏覽器要求可以是Internet Explorer v.9及更高版本以及Google Chrome，它能夠執行所有系統功能，包括瀏覽，資料輸入，編輯和儲存頁面上的內容。

移動作業系統通常移動應用程式在Apple iOS和Android作業系統上執行。這些作業系統為應用程式功能提供了基礎。其附加功能包括安全性和效能調整。作業系統的要求基於管理資源，處理業務流程需求，滿足裝置分析需求（與後端基於雲的分析相比）的需求，並提供安全性。

輔助功能輔助功能是一種重要的NFR，可增強使用者體驗。設計易於訪問的軟體解決方案需要了解使用者的物理特性（和限制）及其可用性需求。可訪問性要求也是大多數處理軟體解決方案的政府機構的法律和合規需求的一部分。與物理可訪問性需求類似，政府法規還規定了在解決方案發布之前軟體解決方案必須滿足的軟體可訪問性需求4。

可訪問性要求的一個重要部分是確保它們不僅在設計，開發和測試期間滿意，而且在系統完全部署時也滿足。因此，與滿足可訪問性要求相關的工作仍然遠遠超出了軟體的釋出範圍。

HMS的可訪問性要求的示例包括使用者（尤其是患者）處理顏色的能力（用顏色突出顯示重要資訊;色盲使用者仍然可以獲得資訊），在螢幕上選擇性地放大內容，基於上下文的工具提示，佈局佈置以對應於演員的邏輯工作流程，以及對鍵盤和滑鼠的替代訪問（例如，音訊/聲音輸入和輸出）。隨著越來越多地使用物聯網裝置來監測患者引數，HMS的要求集中在最小干預和來自使用者（患者）的輸入上。因此，自動化是使用向HMS提供資料的物聯網裝置的關鍵標準。

可靠性和維護軟體系統的可靠性和維護要求轉化為使用者最需要時系統的可用性以及系統在更改（維護）後重新聯機的能力。

軟體維護包括後交付活動，這些活動是為了系統穩定性和功能而執行的。維護通常被視為主要的資源消耗活動之一。迭代和增量方法也有助於維護週期（與新的開發週期相反），因為它可以計劃對完全封裝的包進行逐件維護。

除了一般的系統維護，資料庫維護也是這個NFR的關鍵部分。維護策略應清楚地描述目標，功能，處理細節和驗證程式。資料庫維護策略描述了資料備份，資料清理和排程的過程。該策略還具有優先順序計劃，以在一般任務之前完成高優先順序任務。維護過程包括定義，測量和改進風險分析和質量保證。

驗證還構成維護策略的主要部分，並確保系統以所需方式執行。例如，在HMS專案中，使系統與各種元件和類的常規補丁保持同步是解決方案的重要組成部分 - 並且需要將這些活動納入系統的迭代和增量維護生命週期。例如，每個月都可以更新HMS的每個包 - 只要一個更改對其他包沒有影響。

維護還處理HMS資料的定期備份和映象。此外，歸檔資料（不再在醫院的患者和醫生）也需要有計劃的方法 - 並且需要在專案開始時指定為維護NFR。這種型別的維護消除了中央伺服器的負載，並提高了解決方案的整體效率。

環境如前所述，越來越需要在解決方案設計中納入環境要求。這些是與業務相關的可持續發展和環境要求。由於這些要求不是行為，因此屬於NFR類別。

例如，涉及開發解決方案的總計算機硬體產生一定的碳含量;類似地，操作解決方案導致碳生成和對環境的相應影響。複雜的伺服器技術和基於雲的部署對組織的碳排放負有同等責任。計算硬體的相應冷卻工作需要納入碳計算中。

因此，系統的部署需要考慮系統的這些環境引數。

例如，HMS要求可以指定在開發工作期間產生的總碳將為100KT（千噸）。還可以估算碳產量（例如，每個使用者每月1KT）。此外，這些環境要求規定了某些內部硬體要求（例如，低碳排放螢幕）和機器在不再使用時的回收（例如，自HMS釋出之日起3年）。

法律和合規性大多數軟體解決方案必須處理法律和合規性要求。這些要求源自業務情況以及開發和部署解決方案的地理區域。 NFR類別中的這些法律要求不同於作為系統邏輯一部分的法律要求。例如，如果法律要求規定在每個等級上增加10％的稅（例如，增值稅或商品及服務稅），那麼這就成為系統功能要求的一部分。作業系統的法律要求的示例包括託管系統，強制報告活動以及資料儲存的隱私問題。

安全性安全性是迄今為止軟體系統中最關鍵的NFR。早些時候，在圖20.1中，安全性顯示在框的頂部 - 影響所有其他NFR。這種影響很重要，因為從系統架構的角度來看，每個NFR都需要與系統的安全需求相平衡。假設世界上最安全的系統是一個根本無法訪問的系統;但沒有訪問這樣的系統是沒有意義的。安全的理念和實施涉及在適當的時間和地點允許對權利（授權）人員進行相關訪問的平衡行為。因此，安全性是系統的不斷變化的動態NFR。

安全性也有很大的功能元件。例如，與現在無處不在的使用者程式碼/密碼訪問相關聯的功能可以使用用例和相應的活動圖輕鬆建模。但是，在任何給定時間點訪問系統並確保訪問安全的使用者數是與安全性相關的NFR的一部分。安全級別的數量，型別，加密需求，伺服器，計算機和手持裝置的物理安全性以及防火牆的實現是影響軟體應用程式開發的重要非功能性引數。所有與安全相關的問題都不屬於系統的功能或行為方面，通過NFR進行考慮，記錄，原型化和驗證。

有四個安全因素會影響軟體系統中的所有安全級別。

圖20.4a所示的這四個影響因素是機密性，完整性，責任性和可用性。系統的機密性要求描述了與未經授權的使用者不公開資訊相關的問題。完整性要求確保系統中的資訊僅由具有適當訪問許可權（控制）的授權使用者操作。問責制要求指定授權哪些使用者以及具體時間。

可用性要求確保授權使用者在需要時不會被拒絕服務。

這四個要求中的每一個都適用於為系統提供的安全級別（如圖20.4b所示）。接下來描述這些安全級別：

◾物理安全性 - 對伺服器的物理訪問 - 在內部維護時（與雲相比）需要僅限於授權使用者。

- 伺服器，網路和裝置的物理位置應確保其安全性;這些機器應該對負責維護的人員是可訪問的，否則其他使用者不應該在物理上可見。

- 移動裝置訪問和裝置潛在丟失需要考慮到系統的安全性;例如，確保資料儲存在後端伺服器而不是物理裝置上，因此裝置丟失不會導致資料丟失。

問責制可用性機密性完整性硬體安全性

•對伺服器的物理訪問 - 在內部維護時（與大聲相比）

•與使用者相比，伺服器，網路和裝置的物理位置

•移動裝置訪問和裝置應用程式和瀏覽器可能容易丟失

•通用密碼保護和使用者培訓

•密碼的兩部分驗證

•特定於使用者的生物識別（音訊，指紋）訪問

•恢復選項 - 基於使用者的標識問題，裝置和其他電子郵件

•瀏覽器的型別，版本和安全性（例如，用於儲存密碼）作業系統和平臺

•加密應用程式和伺服器之間傳送/接收的資料

•作業系統的防禦機制

•作業系統和伺服器網路中內建的攻擊性（檢測）

•LAN，WAN（本地）和本地網路安全

•VPN（組織內部）通過提供訪問的安全管道

•網際網路訪問和應用程式的安全性

•移動運營商網路和平臺 - 以及內容提供商的責任（a）（b）圖20.4軟體和移動應用安全：（a）影響因素和（b）級別。

◾應用程式和瀏覽器 - 常用密碼保護機制（如密碼的長度和組成）以及使用瀏覽器方面的相應使用者教育（例如，不在瀏覽器中儲存密碼） - 密碼的兩部分身份驗證作為一個過程（這將是一個功能模型，雖然這裡作為NFR的一部分討論）。

- 特定於使用者的生物識別（音訊，指紋）訪問 - 減少未授權訪問的機會並增加責任 - 基於使用者的識別問題，裝置和其他電子郵件的恢復選項確保特定應用程式和裝置的訪問的完整性。

- 瀏覽器的型別，版本和安全性（例如，如果用於儲存密碼 - 儘管不建議使用）以確保使用者的機密性和責任性

◾作業系統和平臺 - 應用程式和伺服器之間傳送/接收的資料的加密保持資料的完整性。

- 作業系統的防禦機制確保解決方案的機密性和完整性。

- 作業系統和伺服器內建的攻擊性檢測也確保瞭解決方案的機密性和完整性。

◾網路 - LAN，WAN（本地）和本地網路安全，以確保使用者的授權訪問。

- VPN（組織內部），提供用於訪問的安全管道，模擬內部訪問。

- 應用程式的Internet訪問和安全性，以確保解決方案的機密性和完整性。

- 移動運營商網路和平臺以及內容提供商的職責也是為了確保解決方案的機密性和完整性。

可用性和使用者體驗將可用性要求應用於軟體解決方案第16章討論了可用性和以使用為中心的設計原則在軟體系統中的應用。螢幕之間的控制流程是需求的功能方面的一部分，這也在第16章中討論過。這裡討論的可用性要求僅在它們處理介面的靜態結構方面時才被認為是無效的。例如，移動應用程式的螢幕上的顏色和按鈕位置是系統的非功能方面的一部分。可用性與幾乎所有其他NFR一起使用。

可用性還描述了系統為使用者目標新增的價值。關於可用性的討論不僅要考慮建立良好的使用者介面，還要考慮提高使用者的最終價值。精心設計的使用者介面使使用者能夠完成任務，提高生產力，減少與培訓相關的時間和成本，減少使用者錯誤，提供使用者支援並提高介面的可維護性。

可用性有助於熟悉系統的使用者輕鬆學習和採用介面。例如，對於熟悉使用基於Web的應用程式的使用者，常見的OK，Cancel和Help按鈕的存在和位置是眾所周知的。由於大多數使用者可能熟悉這三個按鈕，因此它們應該以熟悉的位置和精心設計的介面順序出現。

介面中所有欄位和按鈕的命名約定是可用性的一個重要方面。應清楚地命名每個欄位和按鈕以表示它執行的功能。

介面中按鈕和欄位描述的隱蔽或極長名稱可能會導致不必要的混淆。例如，使用“PID”或“數字”來表示PatientNumber或患者身份識別不是一個好的設計。另一個常見的例子是使用“儲存”按鈕。儘管可以在使用者介面中使用“儲存”，但最好使用按鈕上的“更新”或“註冊”來進一步闡明按鈕背後的含義。

設計以防止錯誤設計介面時要記住的總體原則是關注預防，而不是糾正錯誤。例如，如果使用者輸入患者的“註冊日期”，則系統應首先向使用者顯示“今天的日期”，然後允許使用者更改它。此方法可防止在從頭開始要求使用者輸入日期（或任何其他資料）時可能出現的典型錯誤。還應該對使用者的操作進行連續的交叉檢查和驗證，以防止錯誤的資料進入系統。例如，如果使用者在填寫介面UI10-PatientRegistrationForm中的資訊後錯誤地按下取消按鈕，則系統應該要求使用者在執行之前驗證該動作。

通過良好的使用者介面設計，可以立即驗證螢幕上的大量欄位，而不是在“從”介面類傳輸資料之後由實體類驗證。例如，輸入有效日期幾乎總是介面類的函式，而不是實體類。但是，一旦輸入日期，它是否在語義上是正確的日期（例如，出生日期不應晚於今天的日期）是實體類的責任，而不是介面類。

最後，介面的設計應考慮到美學。例如，關於介面的資訊通常從左到右執行，而不是相反，患者的名字出現在患者姓氏的左側。應避免在螢幕上過度擁擠，並應使用顏色來傳達意義並在視覺上令人愉悅。

大資料（速度，多樣性）大資料是一個廣泛的術語，顧名思義 - 大量資料;此外，這些資料以非常高的速度進入系統（很可能是因為它是由機器生成的，除了人類之外）並且包含多樣性。各種資料的特徵除了文字構成的音訊，視訊，圖形，非結構化描述（部落格，電子郵件）和機器生成。在設計和開發新的軟體應用程式時，需要牢記大資料的上述每個特徵。這是因為大多數新應用程式處理大資料的某些元素 - 無論是在採購資料，分析它們，還是如下一節所述，將其儲存在雲上。

雲如本章前面所述，雲端計算是大多數新系統不可或缺的一部分，在確保滿足解決方案的非功能或操作要求方面發揮著至關重要的作用。

雲端計算描述了一個系統，使用者可以將系統連線到位於其他地方的大量計算資源，資料和伺服器，通常位於Internet上，而不是本地計算機，LAN或資料中心。雲是儲存資料的預設機制，它在軟體解決方案中的重要性超越了資料儲存。與軟體相關的處理，其資料的來源和共享，以及軟體在使用者選擇的時間和地點實現協作的能力是雲端計算所啟用的。

因此，應用程式和分析的實際執行也發生在雲上。雲無需在使用者裝置上本地安裝軟體和分析應用程式。

因此，計算成為一種可以按需提供分析應用程式的實用程式.6前面討論的NFR（包括效能，數量，可伸縮性，安全性和操作平臺）都受到雲的影響。這是因為雲將組織的整個後端呈現為虛擬。

因此，雲形成了軟體解決方案的系統架構的關鍵部分。 需要在早期需求收集階段中探索雲對軟體解決方案的非功能引數的影響，然後在解決方案部署之前和期間通過定期測試進行探索。