軟件測試之如何進行軟件需求分析[2]

軟件測試之如何進行軟件需求分析[2]  軟件需求管理

關鍵字：軟件 需求分析

　　4.需求的類型

　　下面這些定義是需求工程領域中常見術語的定義。

　　軟件需求包括三個不同的層次：業務需求、用戶需求和功能需求(也包括非功能需求)。

　　1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。

　　2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例(use case)文檔或方案腳本說明中予以說明。

　　3.功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。

　　在軟件需求規格說明書 (SRS)中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統(或軟件部件)。

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

　　下面以一個字處理程序為例來說明需求的不同種類。業務需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換。

　　從以上定義可以發現，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。項目也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。盡管這些需求對項目成功也至關重要，但它們并非本書所要討論的。

　　5.需求分析的原則

　　不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這里的“成功”是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望。下面將討論一些需求風險。

　　不適當的需求過程所引起的一些風險:

　　1. 無足夠用戶參與

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

原文轉自：http://www.anti-gravitydesign.com