人員和客戶溝通的方式，以及規(guī)范需求說明的格式，如果可能的話，盡量采取象XP 的UserStory ，或者用戶可以理解的用例圖來對需求進行標準、規(guī)范的描述，保證雙方在工具的協(xié)助下對需求達到共同的認識，這一點是老生常談，就不多說。

確定文檔的有效性（Validity ）順便要提的一句是關(guān)于文檔，需求文檔是相當重要的，可是目前存在一種奇怪的現(xiàn)象，本來說必須要有文檔，而且是按照某種特定的格式，當然這沒有錯，但接下來，卻沒有人關(guān)心文檔的真正內(nèi)容是否正確，格式是否真的合理，是否實用（而且很多情況下是在幾天時間里趕出來或補上去的），例如我遇到一個例子，需要在原來的需求基礎(chǔ)上進行后續(xù)開發(fā)，文檔找到了，完全符合格式的要求，但是我在里面找到的線索是有限的，結(jié)果是自己花幾天的時間查找數(shù)據(jù)表結(jié)構(gòu)、甚至查看數(shù)據(jù)表的內(nèi)容，詢問當時的開發(fā)人員，才分析到所要的關(guān)系，這種情況在設(shè)計文檔里也存在，所以同時提一提，希望我們的開發(fā)人員、PM 以及各級領(lǐng)導可以注意文檔的有效性和有用性問題，甚至對文檔的格式進行一下合理性檢查。建立代價估算（Cost Estimate ）概念這一點對開發(fā)方和客戶同樣重要，因為如果出現(xiàn)需求變更，不可避免將帶來成本的增加、開發(fā)時間延長等不良后果，這樣的影響是雙方的。這時候需要區(qū)分需求變更的原因，是客戶方必要/不必要的要求，還是由于開發(fā)方的工作失誤，還是雙方都有原因，然后對現(xiàn)實情況進行分析，得出雙方實現(xiàn)變更需求的需要的成本，包括時間，人力，資源等等方面，再與客戶商討是否必要進行變更和如何在最小代價下實現(xiàn)變更。當客戶看到實際的代價估算，他們也會再一次慎重地考慮需求變更問題，也會更容易理解系統(tǒng)建設(shè)中的進行狀況，自然開發(fā)方也不用負擔所有的需求變更成本，
所以進行成本分攤還是有其積極意義的。當然還有建立需求變更版本控制等等專業(yè)的需求管理，在這里不做專門論述。從軟件分析和設(shè)計著手前面說了面對需求變更的幾種策略，那么從軟件系統(tǒng)分析和設(shè)計的角度來看，通過采用合理的分析設(shè)計方法，進行可擴展性設(shè)計可以有效地降低需求變更引起的風險和維護代價。

采用OO 技術(shù)

采用OO 技術(shù)可以建立易于改變和加強可重用性的軟件系統(tǒng)。
對于OO 技術(shù)，我想現(xiàn)在已經(jīng)不是什么陌生的概念：

　　1 封裝（Encapsulation ）可以把問題影響的范圍縮小，外部的變化要求對系統(tǒng)的影響可以限定到某個類層次或某些類層次中，從而改變系統(tǒng)的一部分相對簡單；
　　2 繼承（Inheritance ）可以使改變基于原有技術(shù)基礎(chǔ)，很大程度上減少重復開發(fā)工作；
　　3 多態(tài)（Polymorphism ）的應(yīng)用可以使開發(fā)和設(shè)計人員在相對統(tǒng)一的接口下更改系統(tǒng)的實現(xiàn)細節(jié)，從而改變系統(tǒng)的行為；
　　4 而且由于對OO 的類體系結(jié)構(gòu)業(yè)界有非常清楚明晰的描述方式，就是目前規(guī)范的描述語言-UML ，非常易于被開發(fā)組的理解并達成共識，促進開發(fā)組成員之間的合作以及加強軟件開發(fā)工作的可延續(xù)性；可見本身即是一種增強軟件可維護性、健壯性以及保持設(shè)計穩(wěn)定性的一種分析和設(shè)計方法，本身可以在一定程度上快速對需求變更進行反應(yīng)，并可相對減少需求變更需要的成本。（OO 的意義在于分析和設(shè)計軟件系統(tǒng)的思考方式，以及建立對象庫以后的軟件重用將給軟件系統(tǒng)的開發(fā)帶來質(zhì)的改變，但是在建立OO 開發(fā)體系之前的過程，一定會是一段荊棘遍布的路，需要付出加倍的努力以及達成思想的轉(zhuǎn)變。這里還有一個誤區(qū)需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 就是面向?qū)ο蟮拈_發(fā)了，其實只是用了一些面向?qū)ο蟮墓ぞ?，骨子里仍然是結(jié)構(gòu)化的分析和設(shè)計方法，套上一層OOP 的外殼而已。）可擴展性設(shè)計（Extensi

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

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