怎樣進行軟件需求分析[6]

怎樣進行軟件需求分析[6]    軟件需求管理

關鍵字：軟件 需求分析

　　6： 劃分需求優先級別

　　大多數項目沒有足夠的時間或資源來實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發的主要部分。只能由你來負責設定需求優先級，因為開發者并不可能按你的觀點決定需求優先級。開發者將為你確定優先級提供有關每個需求的花費和風險的信息。當你設定優先級時，你幫助開發者確保在適當的時間內用最小的開支取得最好的效果。在時間和資源限制下，關于所需特性能否完成或完成多少應該尊重開發人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現，但畢竟是要面對這種現實的。業務決策有時不得不依據優先級來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。

　　7：評審需求文檔和原型

　　正如我們將在第1 4章討論的，無論是正式的還是非正式的方式，對需求文檔進行評審都會對軟件質量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來反饋信息以改進他們的工作。如果你認為編寫的需求文檔不夠準確，就有義務盡早告訴分析人員并為改進提供建議。通過閱讀需求規格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產品開發一個原型。這樣你就能提供更有價值的反饋信息給開發人員，幫助他們更好地理解你的需求。必須認識到：原型并非是一個實際產品，但開發人員能將其轉變、擴充成功能齊全的系統。

　　8：需求出現變更要馬上聯系

　　不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響。變更是不可避免的，但在開發周期中變更越在晚期出現，其影響越大。變更不僅會導致代價極高的返工，而且工期也會被迫延誤，特別是在大體結構已完成后又需要增加新特性時。所以一旦你發現需要變更需求時，請一定立即通知分析人員。

　　9：應遵照開發組織處理需求變更的過程

　　為了將變更帶來的負面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項目中。

　　10：尊重開發人員采用的需求工程過程

　　軟件開發中最具挑戰性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認為需求過程不太劃算，但請相信花在需求開發上的時間是“很有價值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術，那么整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關的活動。

　　系統分析人員在開發過程中可能會遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導致不理想的產品。故一定要確保需求開發中的主要參與者都了解并接受他們的義務。如果遇到分歧，通過協商以達成對各自義務的相互理解，這樣能減少今后的摩擦。

　　7.需求文檔

　　需求開發的最終成果是：客戶和開發小組對將要開發的產品達成一致協議。協議綜合了業務需求、用戶需求和軟件功能需求。就像我們早先所看到的，項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。只有以結構化和可讀性方式編寫這些文檔，并由項目的風險承擔者評審通過后，各方面人員才能確信他們所贊同的需求是可靠的。

　　你可以使用以下三種方法編寫軟件需求規格說明：

　　用好的結構化和自然語言編寫文本型文檔。

　　建立圖形化模型，這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系。

　　編寫形式化規格說明，這可以通過使用數學上精確的形式化邏輯語言來定義需求。

原文轉自：http://www.kjueaiud.com