軟體要求
reddish
雖然有許多產品功能，但在許多系統中，只有一小部分需要認真考慮。
雖然有許多產品功能，但在許多系統中，只有一小部分需要認真考慮。 如果開發人員知道哪些功能對專案的成功至關重要，他們就可以選擇軟體工程方法來實現特定的質量目標。 根據設計，可以對質量屬性進行分類。 對屬性進行分類的一種方法是區分在執行時可識別的特徵和不可識別的特徵。 另一種方法是區分對使用者很重要的可見功能和對開發人員和維護者重要的不可見功能。 對開發人員很重要的屬性使產品易於更改、驗證和移植到新平台，從而間接滿足客戶的需求。
產品的不同部分具有所需的質量特性的不同組合。 效率對於某些部件可能很重要，而可用性對其他部件也很重要。 區分應用於整個產品的質量屬性與特定部件、使用者類或特殊使用環境的質量屬性。 將任何全域性屬性要求記錄到 RS 中，並將特定目標與 RSS 的功能、用例或功能要求聯絡起來。
在確定質量屬性時，它們必須基於使用者對系統的期望。 量化重要屬性有助於明確使用者期望，並幫助設計人員提出最合理的解決方案。 但是，大多數使用者不知道如何回答諸如“互操作性對您有多重要？ “或者，”軟體應該有多可靠？ 等等。
在乙個專案中，分析師提出了可能對不同使用者類很重要的屬性，並根據每個屬性設計了許多問題。 他們使用這些問題來要求每個使用者類的代表將每個屬性分類為 1 到 5（極其重要的屬性）。 這些問題的答案有助於分析人員確定哪些質量特徵最重要，可以用作設計標準。
然後，分析師與使用者合作，確定每個屬性的具體、可衡量和可驗證的要求。 如果質量目標無法驗證，則無法判斷它們是否已實現。 在適當的情況下，指定每個屬性或目標的測量級別或單位，以及最大值和最小值。 如果你不能定量地識別出對你的專案很重要的某些屬性，那麼你至少應該優先考慮它們。 IEEE軟體質量測量方法標準提出了一種在全面的質量測量基準系統下定義軟體質量要求的方法。
定義屬性的另一種方法是識別與質量期望衝突的任何系統行為。
通過定義不良行為（反向要求），您可以設計強制系統表現出這些行為的測試用例。 如果你不能強迫系統這樣做，那麼你可能已經達到了你的財產目標。 這種方法最適合安全關鍵型應用，在這些應用中，系統錯誤可能導致危及生命的應用。
有效性是指系統在計畫的啟動時間內實際可用並完全執行的時間百分比。 正式地，有效性等於系統的平均故障時間 （MTTF） 除以平均故障時間和修復時間的總和。 有些任務比其他任務更耗時，如果使用者在執行任務時系統不可用，他們可能會感到沮喪。 因此，需要詢問使用者對有效性的需求，以及是否需要在任何給定時間滿足業務或安全目標。
有效性要求的陳述可能是：“在工作日當地時間早上 6 點到午夜之間，系統的有效性至少為 99。5%，下午 4 點到 6 點，系統的有效性至少為 9995%。”
效率是衡量系統充分利用其處理器、磁碟空間或通訊頻寬的程度的指標。 如果系統用完所有可用資源，則使用者可能會遇到效能下降，這是效率降低的標誌。 較差的系統效能可能會激怒等待資料庫查詢結果的使用者，或者可能會對系統的安全性構成威脅，例如過載的實時處理系統。 為了在發生不可預見的情況時實現安全緩衝，可以將其定義如下：“在預期的峰值負載條件下，必須留出 10% 的處理器容量和 15% 的系統可用記憶體作為備份。 “在定義效能、功能和效率目標時，重要的是要考慮硬體的最低配置。
靈活性類似於我們所知的可擴充套件性、增強性、可擴充套件性、可擴充套件性，它表示向產品新增新功能所需的工作量。 如果開發人員能夠預見到系統的可擴充套件性，他們就可以選擇合適的方法來最大限度地提高系統的靈活性。 對於通過一系列連續版本、增量和重複方式開發的產品來說，靈活性非常重要。
例如：“具有至少 6 個月相關工作經驗的軟體維護工程師可以在不到乙個小時的時間內將新的列印輸出就緒裝置新增到系統中。 ”
完整性（或安全性）主要涉及四個方面：防止未經授權訪問系統功能、防止資料丟失、防止病毒入侵和防止私人資料進入系統。 完整性已成為通過 www 執行的軟體的重要問題。 電子商務系統的使用者擔心保護信用卡資訊，網路瀏覽者不希望他們的私人資訊或訪問記錄被非法使用。 對完整性的需求必須是萬無一失的，即必須通過特定方法充分保護資料和訪問。
用精確的術語描述對完整性的需求，例如身份驗證、使用者許可權級別、訪問限制或需要保護的確切資料。 完整性要求的示例可以描述如下：“只有具有審核員訪問許可權的使用者才能檢視客戶交易歷史記錄。 ”
互操作性表示產品與其他系統交換資料和服務的難易程度。 為了評估所需的互操作性級別，您必須知道使用者使用哪些其他應用程式連線到您的產品以及他們正在交換哪些資料。 “文書處理系統”的使用者習慣於使用商業工具繪製組織結構圖，因此他們有以下互操作性要求：“文書處理系統應該能夠從Microsoft Visio和SmartDraw工具匯入任何有效的組織結構圖。 ”
可靠性是軟體在一段時間內無故障執行的概率）。穩健性和有效性有時可以被視為可靠性的一部分。 衡量軟體可靠性的方法包括正確執行的操作比例、系統在發現新缺陷之前執行的時間長度以及缺陷發生的密度。 可靠性要求是根據故障對系統的影響程度以及實現最大可靠性的成本是否合理來定量確定的。 如果軟體滿足其可靠性需求，那麼即使軟體仍然存在缺陷，也可以認為它已經達到了其可靠性目標。
魯棒性是指系統或其元件在相關軟體或硬體元件發生非法資料輸入、缺陷或異常執行條件的情況下能夠繼續正常執行的程度。 強大的軟體可以完好無損地從相關環境中恢復，並容忍使用者錯誤。 當從使用者那裡獲得魯棒性目標時，您需要詢問系統可能遇到的錯誤情況，以及使用者希望系統如何響應。
可用性也被稱為“易用性”和“人體工程學”，它描述了構成“使用者友好性”的許多因素。 可用性衡量準備輸入、操作和理解產品輸出所需的工作量。 您必須在易用性和學習如何操作產品的易用性之間取得平衡。 “文書處理系統”的分析師會問使用者這樣的問題：“快速簡單地建立、編輯和格式化文件對您來說有多重要？ “以及”您認為建立新文件需要多長時間？ “這只是乙個簡單的起點，用於定義許多使軟體易於使用的功能。 對可用性的討論可以導致可衡量的目標，例如“訓練有素的使用者應該能夠在平均 3 分鐘或最多 5 分鐘內建立新文件。 ”
可維護性表示糾正缺陷或更改軟體的難易程度。 可維護性取決於理解、更改和測試軟體的難易程度，而可維護性與靈活性密切相關。 對於那些週期性變化或快速開發的產品來說，高可維護性很重要。 您可以根據修復問題所需的平均時間和修復正確的百分比來衡量可維護性。
可移植性是衡量將軟體從乙個執行時移動到另乙個執行時所需的工作量的指標。 軟體可移植性的設計方法類似於軟體可重用性的設計方法。 可移植性對專案的成功並不重要，對專案的結果也不重要。 可移植目標必須說明產品中可移植到其他環境的部分，並標識相應的目標環境。 因此，開發人員可以選擇適當提高產品可移植性的設計和編碼方法。
從軟體開發的長期目標來看，可重用性表示軟體元件除了在最初開發的系統中使用之外，還可以在其他應用程式中使用。 開發可重用軟體將比建立只打算在乙個應用程式中使用的元件更昂貴。 可重用軟體必須是標準化的、有據可查的、獨立於特定應用程式和操作環境的，並且是通用的。 確定新系統的哪些元素需要以便於重用的方式進行設計，或者將可重用元件庫指定為專案的副產品。
可測試性是指在測試軟體元件或整合產品時發現缺陷的難易程度。 如果產品包含複雜的演算法和邏輯，或者存在複雜的功能相互關係，則可測試性設計非常重要。 如果產品經常更改，可測試性也很重要，因為產品將經常進行回歸測試，以確定更改是否破壞了現有功能。
有時，不可避免地要對某些屬性進行權衡。 使用者和開發人員必須確定哪些屬性比其他屬性更重要並確定其優先順序。 當他們做出決定時，他們總是遵循這些優先事項。
例如，增強軟體可重用性的設計方法還可以使軟體更靈活、更易於與其他軟體元件連線、更易於維護、更易於移植和更易於測試。 單元格中的減號表示單元格所在的行的屬性增加了對單元格所在列的屬性的不利影響。 高效率對許多其他屬性有負面影響。 如果編寫最緊湊、最快的，並且使用特殊的預編譯器和作業系統，那麼移植到其他環境就不容易了，並且很難維護和改進軟體。 同樣，優化操作員易用性或試圖靈活、可用且與其他硬體和軟體互操作的系統也將以效能為代價。
例如，與使用具有完整圖形**的舊應用程式系統相比，使用外部通用圖形引擎工具生成圖形計畫將顯著降低效能。 您必須在效能成本和建議的解決方案的預期收益之間進行權衡，以確保做出合理的權衡。
為了實現產品特性的最佳平衡，您必須在需求獲取階段識別、確定相關質量屬性並確定其優先順序。 為專案定義重要的質量屬性時，請防止與目標衝突的行為。 以下是一些示例：
如果軟體要在多個平台上執行（可移植性），那麼不要對可用性持樂觀態度。
可重用軟體普遍適用於各種環境，因此不能滿足特定的容錯（可靠性）或完整性目標。
對於高安全性系統，很難全面測試其完整性需求; 可重用的類元件或與其他應用程式的互操作性可能會破壞其安全機制。
在軟體中，它本身並不能實現質量特性的合理平衡。 在需求獲取過程中，包括對質量屬性的期望的討論，並在軟體需求規範中包括您所知道的內容。 通過這種方式，可以提供滿足所有專案利益相關者的產品。
本文同時發表在《軟體需求探索》上。