品質要求
品質的一切問題都圍繞着需求——始于需求，終于需求。需求規定了軟體必須達到的技術性目标，在設計和開發過程中指導着軟體的建立。這些需求是否得到滿足需要通過測試來決定，測試能夠證明軟體的完成情況，說明預期的品質。
在介紹動态性能需求時，講述了如何将每個品質特征的技術性需求融合到需求中，該部分的目的是 ：盡管加入性能非常重要，而且 SDLC中也經常這樣做，但最好是在規劃設計階段就落實，并且要反映具體的要求和需求。
随着軟體項目中利益相關者的不斷增加，形式化需求的重要性也相應地越來越突出。當利益相關者就是開發人員，共同協作以建立軟體的各個元件時，需求能夠幫助他們确定大家是否都在按照相同的要求朝着共同的目标努力。需求能清楚地描述開發工作的内容，這使開發人員能夠依靠既定的資訊而不是對資訊的诠釋展開工作。在項目規劃階段，利益相關者對軟體預期的功能和性能的看法很少一緻，但借助需求，他們能夠統一對軟體目标和後期功能及性能的看法，開啟軟體項目。
如果沒有統一的軟體需求，那麼在軟體完成時，利益相關者可能對于軟體是高質 量、低品質甚至是否建立完成的問題看法不一。沒有公認的軟體需求，利益相關者 隻能對照自己的需求來評估軟體，而每個人都有自己不同的看法，是以，軟體的評估 缺乏客觀性。而且，在 SDLC 的“範圍擴充”中，不成文的需求随時都會發生變化。當軟體超出或無法滿足客戶需求時，軟體需求能夠幫助避免這種偏差，如圖 2-4所示，後面部分會繼續講述這一點。
圖2-4 “不盡人意”和 “畫蛇添足”
需要注意的是，盡管“畫蛇添足”會提供一些附加的功能或性能，但這并不會提升軟體的品質，因為客戶不需要、未做出要求或者無法從中獲得額外的商業價值。
避免“不盡人意”
在我們的職業生涯中，有些時候，“不盡人意”并不表示我們就是失敗者，客戶可能在看過軟體之後告訴我們軟體沒有達到标準。我們沒有滿足技術要求中明确和隐含的功能性目标或性能目标，是以我們的軟體沒有達到預期的品質。“不盡人意”指 預期品質和實際表現的品質之間的偏差。然而，某些環境主要依賴隐含的性能需求而不是技術需求中明确表示的要求，如果在這些環境中出現了不盡人意的情況，那麼這種模棱兩可可能造成利益相關者的慌亂。開發人員可能認為自己給出的是預期的軟體，但客戶和使用者會覺得功能性或性能沒有達到要求。
若經理要求建立高效的軟體，規定了運作時間、速度及記憶體使用率的門檻值，但我們所建立的軟體并沒有滿足這些目标，這時候就出現了性能差距。從功能性來看，軟體是合理的，但品質差強人意，因為性能未達到要求。如果預期的性能沒有通過需求明确地表達出來，而隻有暗示，那該怎麼辦呢？經理或許會認為我們已經知道軟體需要在 15 分鐘之内建立完成，但他實際上并沒有明确地傳達這一資訊，或者隻是在軟體規劃階段提出其他需求時有所暗示。經理需要的是“快速的SAS”，而且我們也認為自己給出的是“快速的SAS”，但由于性能需求未陳述清楚或未經過公認（以便進行評估和驗證），我們在評估軟體品質時要參考哪一方對“快速的SAS”的定義呢？
公認的、可評估的需求能夠避免出現“不盡人意”的情況，它能夠為 SAS從業人員提供一個核對表以便他們對照評估自己的代碼。代碼滿足所有的功能性需求嗎？滿足 ；能滿足所有的性能需求嗎？滿足 ；能滿足正式的測試計劃中所有的測試案例嗎？滿足。建立需求能夠確定在軟體規劃階段共同确定品質，在軟體完成階段共同評估和驗證品質。
避免“畫蛇添足”
從“SDLC中的品質”部分中的開發場景繼續往下講，我們是研究人員，需要編寫 SAS軟體對資料進行分類，以篩選出獨特的觀測結果。在軟體規劃階段，我們問了自己幾個與性能相關的問題，而且在終端使用者開發環境中，商業價值主要通過功能性而非性能實作。是以，關鍵的一點是SAS軟體能夠篩選出獨特的觀測結果并生成一個詳細的資料集。如果程式失敗，我們作為終端使用者開發人員可以重新開始，是以穩健性并不是那麼重要。因為資料集不是很大，幾秒就可以處理完，是以運作效率也不是首要的考慮因素。而且由于資料集不會随着時間的推移而不斷擴充，是以，資料的可擴充性也不是開發過程中關注的重點。
這并不是說品質在這種情境下或在終端使用者開發環境中不重要，而是指如果性能屬性的添加沒有任何價值，或者性能屬性的缺失也不會帶來負面的影響（至少在可接受範圍内），則無須考慮添加性能屬性。是以，在這種情況下，如果我們憑着以前的經驗，花費了幾小時來測試 SASIndex函數、SQL程式、混合SORT程式或 DATA步驟是否能生成運作速度最快的代碼，那麼完全就是在浪費時間——至少在這個項目中是如此，因為這不會帶來任何額外的商業價值，而且還會拖慢軟體完成的進度。即便我們确實成功地提高了使用率，軟體品質顯然也不會增加，因為附加的性能沒有實作任何性能需求。
當軟體需求缺乏明确性，留有解釋或假想的空間時，就會出現“畫蛇添足”的情況。一個 SAS從業人員可能會自豪地推出一個穩健、高效的程式，期望能夠獲得經理的贊賞，但最終等來的卻是責備，因為軟體不需要穩健。相反，它應該是早已完成的，而且，性能的添加實際降低了軟體的價值，因為它拖慢了分析師使用合成資料集或資料産品的速度。通過在項目初始階段提出技術性要求，開發團隊能夠對軟體價值形成統一的認識和了解，指導 SAS從業人員隻關注全體公認的、有價值的功能性和性能。
實質上，“畫蛇添足”回答的問題是：我們能有太多的品質嗎？是的，我們能。增添意料之外的性能有時能拉近我們與客戶之間的距離——老闆未要求我們提高軟 件的處理速度，但我們這樣做了，因為我們就是這樣的善解人意，是以老闆會從心底 感謝我們提升了軟體的速度。但是，額外添加一些不必要的性能并不會提升軟體的質 量，而且如前所述，這樣做還會降低軟體的價值，因為它拖慢了進度，增加了預算， 影響了有價值的功能和性能作用的發揮，是以，随意添加或改變軟體是非常危險的， 需要我們慎重考慮。
對品質說“不”
避免“畫蛇添足”的一個技巧是明确地規定軟體中應該包含哪些性能屬性，以及 不應該添加哪些品質特征。并非所有的軟體都用于生産或為了獲得較長的使用期限， 通常在分析環境中，許多 SAS代碼片段的編寫都隻是權宜之計，在分析完結果之後就會被丢棄或者修改。對于這種應急的軟體而言，多個性能特征的疊加未必能起到好 的作用。但如果随着時間的推移，建立該軟體的目的不再是權宜之計，而是戰略需要， 不再是發揮輔助的作用，而是至關重要的基礎結構，那麼同樣的性能稍後就需要被添 加到該軟體中。
這同樣又說明，一些SAS 軟體不需要考慮性能需求，隻需功能性需求即可界定。在軟體意圖會随着時間推移不斷變化的情況下，我們需要重新進行評估，确定軟體需 求——包括功能性和性能需求是否仍然适用。但在某些情況下，比如性能不能為軟體 帶來任何内在價值時，我們需要考慮的就不是性能特征，而應優先考慮機會成本—— 如附加的功能或降低的項目成本。
對品質說“是”
軟體意圖或開發環境的某些方面能夠保證軟體的高效率。在某些情況下，性能如功能性一樣都會獲得高度重視，對軟體至關重要。這主要因為附加的功能被看作是非常有用的，或者從風險管理的角度來看，優先考慮性能可以減輕或消除某些具體的風險。下面這些情況就需要軟體具有高性能。
行業規定 某些行業具有具體的、必須遵守的軟體開發規章制度，通常，這類軟體可能會或将要由政府機構進行審查。例如，用于支撐臨床試驗研究的 SAS軟體通常必須遵守美國食品藥品監督管理局（FDA，FoodandDrugAdministration）的“軟體驗證通用原則”以確定滿足相關的品質及性能标準。
組織内部的指導原則 除了行業規定之外，一些組織或團隊通常會制定一些在軟體開發中必須遵守的、綱領性的最佳指導原則，而且，這些指導原則通常要求添加品質特征。例如，一些團隊要求SAS所有的宏都必須包含一個傳回代碼顯示宏的運作或故障，以幫助我們處理異常情況，提升軟體的穩健性。
支撐關鍵基礎架構的軟體 支撐資料分析架構關鍵元件的 ETL或其他 SAS軟體就需要提升性能，以避免出現系統、軟體或合成資料産品不可用的風險。
預定的軟體 設定為重複執行的自動化 SAS軟體需要具有較高的性能，自動化、預設的 SAS工作表示 SAS從業人員無須再手動審查 SAS 日志，是以，對可靠性及穩健性要求較高。
具有獨立處理過程或使用者的軟體 如果 SAS 軟體獲得高度認可，具有獨立的、依賴于該軟體的處理過程或使用者，那麼其性能不僅要能夠反映軟體自身運作的故障風險，還要能反映出依賴項的故障風險。
具有預期使用壽命的軟體 打算使用較長時間的 SAS軟體應該具有較高的性能。靜态性能需求在維持軟體産品的使用中尤為重要，因為它們支撐着軟體的可維護性， 軟體預期使用周期越長，越能展現該投資的價值。
隐含的需求
我們講了很多需求，可能許多讀者會認為品質就意味着沒完沒了的文檔。某些軟體開發環境确實會建立許多文檔，這是因為它們确實需要這樣做，尤其是當出現 “對品質說‘是’”部分所提到的幾個或全部特征時。然而，從ISO對品質的定義來看，軟體品質包括隐含的和明确的需求。而且，靈活軟體開發四條價值中的第二條指出“工作的軟體高于詳盡的文檔”。是以，在組織或團隊層面上，利益相關者需要評估哪些類型的需求需要建立具體的文檔，哪些需求能夠通過對性能和需求的解讀推斷出來。
舉例說明，在一個組織嚴密的團隊中，所有的SAS從業人員都知道每個人的優缺點，了解并相信各自的技術能力。如果團隊成員技術過硬，并且對哪些品質特征能 推進高效能軟體的開發了如指掌，那麼類似“通過動态SAS 宏代碼子產品化建立軟體”的需求就顯得多此一舉，而且如果單獨在需求文檔中指明這一點，就會顯得特别突兀。尤其是在那些配合高效默契的團隊中（參照品質模型，确定是否在軟體定義中添加技 術性需求），我們在技術中完全沒有必要過多地提及性能。