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