02《軟體需求分析教程》

標籤：

　　作為功能需求的補充，軟體需求規格說明還應包括非功能需求，它描述了系統展現給使用者的行為和執行的操作等。  它包括產品必須遵從的標準、規範和合約；外部介面的具體細節；效能要求；設計或實現的約束條件及品質屬性。所謂約束是指對開發人員在軟體產品設計和構造上所具有的選擇限制。品質屬性是通過多種角度對產品的特點進行描述，從而反映產品功能，多角度描述產品對使用者和開發人員都極為重要。

　　需求並未包括設計細節、實現細節、專案計劃資訊或測試資訊。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。項目也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。儘管這些需求對項目成功也至關重要，但它們並非本書所要討論的。

　　開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的介面。同時這也是一旦做錯，將會最終給系統帶來極大損害的部分，而且以後再對它進行修改也極為困難。

　　不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這裡的“成功”是指推出的產品能以合理的價格、及時地完成並在功能、品質上完全滿足使用者的期望。下面將討論一些需求風險。第 5章將介紹怎樣應用軟體風險管理從而防止與需求有關的風險的出現和不適當的需求過程所引起的一些風險。

　　（1）包含的使用者數不多將導致無法接受的產品。

　　（2）使用者需求的擴充將帶來過度的耗費和降低產品的品質。

　　（3）模稜兩可的需求說明可能導致時間浪費和返工。

　　（4）使用者增加一些不必要的特性和開發人員“畫蛇添足(gold-plating)”的追求。

　　（5）過分精簡的需求說明以致遺漏某些關鍵需求。

　　（6）忽略某一部分使用者類的需求將導致眾多客戶的不滿。

　　（7）不完善的需求說明使得專案計劃和跟蹤等無法準確進行。

　　客戶經常不明白為什麼收集需求和確保需求品質需花費那麼多功夫，開發人員可能也不重視使用者參與。究其原因：一來因為與使用者合作不如編寫代碼有興趣；二來因為他們覺得已經明白使用者的需求了。在某些情況下，與實際使用產品的使用者直接接觸很困難，而客戶也不太明白使用者的真正需求。但還是應讓具有代表性的使用者在項目早期直接參与到開發隊伍中，並一同經曆整個開發過程。

　　在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃安排及預算範圍。計劃並不總是貼近項目需求規模與複雜性的實際情況、風險、開發生產率及需求變更情況，這使得問題更難解決。實際上，問題根源在於使用者對需求的改變和開發人員對新需求所作的修改。

　　要控制變更範圍的不斷擴充，必須一開始就對項目視圖、範圍、目標、約束限制和成功標準給予明確說明，並將此說明作為評價需求變更和新特性的參照架構。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，這也將有助於所有風險承擔者明白業務決策的合理性，為何進行某些變更，以及相應消耗的時間、資源或特性上的折中。

　　產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程式難以理解和維護。插入補丁代碼也使模組違背強內聚、松耦合的設計原則，特別是如果項目組態管理工作也不完善的話，收回變更和刪除特性也會帶來問題。如果你能儘早區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，並能更好地適應它，這樣設計階段需求變更不會直接導致補丁代碼，同時也有利於控制因變更導致品質的下降。

　　模稜兩可是需求規格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。模稜兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，並且使測試者與開發人員所期望的也不一致。一位系統測試人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多測試案例和重做許多測試。

02《軟體需求分析教程》