程
    為了將變更帶來的負面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項目中。
10：尊重開發(fā)人員采用的需求工程過程
   軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認為需求過程不太劃算，但請相信花在需求開發(fā)上的時間是“很有價值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術，那么整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關的活動。
    系統(tǒng)分析人員在開發(fā)過程中可能會遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導致不理想的產(chǎn)品。故一定要確保需求開發(fā)中的主要參與者都了解并接受他們的義務。如果遇到分歧，通過協(xié)商以達成對各自義務的相互理解，這樣能減少今后的摩擦。
7．需求文檔
    需求開發(fā)的最終成果是：客戶和開發(fā)小組對將要開發(fā)的產(chǎn)品達成一致協(xié)議。協(xié)議綜合了業(yè)務需求、用戶需求和軟件功能需求。就像我們早先所看到的，項目視圖和范圍文檔包含了業(yè)務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔，包括質(zhì)量屬性和外部接口需求。只有以結(jié)構(gòu)化和可讀性方式編寫這些文檔，并由項目的風險承擔者評審通過后，各方面人員才能確信他們所贊同的需求是可靠的。
你可以使用以下三種方法編寫軟件需求規(guī)格說明：
用好的結(jié)構(gòu)化和自然語言編寫文本型文檔。
    建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關系、邏輯流或?qū)ο箢惡退鼈兊年P系。
編寫形式化規(guī)格說明，這可以通過使用數(shù)學上精確的形式化邏輯語言來定義需求。
    由于形式化規(guī)格說明具有很強的嚴密性和精確度，因此，所使用的形式化語言只有極少數(shù)軟件開發(fā)人員才熟悉，更不用說客戶了。雖然結(jié)構(gòu)化的自然語言具有許多缺點，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已經(jīng)為大多數(shù)項目所接受。圖形化分析模型通過提供另一種需求視圖，增強了軟件需求規(guī)格說明。
    軟件需求規(guī)格說明不僅是系統(tǒng)測試和用戶文檔的基礎，也是所有子系列項目規(guī)劃、設計和編碼的基礎。它應該盡可能完整地描述系統(tǒng)預期的外部行為和用戶可視化行為。除了設計和實現(xiàn)上的限制，軟件需求規(guī)格說明不應該包括設計、構(gòu)造、測試或工程管理的細節(jié)。許多讀者使用軟件需求規(guī)格說明來達到不同的目的：
客戶和營銷部門依賴它來了解他們所能提供的產(chǎn)品。
項目經(jīng)理根據(jù)包含在軟件需求規(guī)格說明中描述的產(chǎn)品來制定規(guī)劃并預測進度安排、工作量和資源。
軟件開發(fā)小組依賴它來理解他們將要開發(fā)的產(chǎn)品。
測試小組使用軟件需求規(guī)格說明中對產(chǎn)品行為的描述制定測試計劃、測試用例和測試過程。
    軟件維護和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的某部分是做什么的。
產(chǎn)品發(fā)布組在需求規(guī)格說明和用戶界面設計的基礎上編寫客戶文檔，如用戶手冊和幫助屏幕等。
培訓人員根據(jù)需求規(guī)格說明和用戶文檔編寫培訓材料。
    軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說明，那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。
    我見過有一個項目突然接到測試人員發(fā)出的錯誤災難的報告。結(jié)果是他們測試的是老版本的軟件需求規(guī)格說明，而他們覺得錯誤的地方正是產(chǎn)品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟件需求

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html