董文彬
(同濟大學 中國 上海 200092)
作為客戶我們都有過類似的經驗:一個不能進行一項基本操作的軟件是多么令人煩惱。盡管開發(fā)者最后會滿足要求,但客戶也不會感激他。而從開發(fā)者的角度來說,在整個系統(tǒng)完成之后,用戶再提出對功能的進一步要求是多么煩人的事。
在開發(fā)中遇到的上述的問題,都是由于收集、編寫等需求分析過程中的失誤帶來的,這也是整個軟件行業(yè)的普遍問題:過于側重于開發(fā)而忽略了軟件需求分析的重要性。實際上,在軟件開發(fā)技術中,軟件需求分析是軟件開發(fā)周期非常重要的一步,也是整個軟件開發(fā)的基礎,關系到軟件工程的成敗和軟件產品的質量,是軟件項目是否成功的重要因素之一。
每個軟件產品都是為了使其用戶能夠以某種方式改善自己的生活、提高自己的工作效率,所以,開發(fā)者必須要詳細的了解用戶需要什么,并總結出功能需求來設計軟件、實現功能,從而滿足用戶要求。
但是在許多軟件項目中,由于需求分析人員在需求階段采取一些不嚴謹的方法,導致了開發(fā)者開發(fā)的產品和用戶所期望的產品之間存在著巨大的期望差異。這些不嚴謹的方法包括:非正式信息的收集,未確定或不明確的功能,未發(fā)現或未經交流的假設,不完善的需求文檔和突然的需求變更過程。
Frederick Brooks在他的文章中說過:開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。這句話的也充分說明了軟件需求分析的任務:就是用嚴謹的方法對目標系統(tǒng)提出完整、準確、清晰、具體的要求,確定軟件系統(tǒng)的必須完成的任務,并深入描述軟件的功能和性能,確定軟件的設計邊界和軟件同其他元素的接口。
簡單來說,軟件需求的任務就是消除軟件產品和用戶期望產品之間的鴻溝。
一個成功的軟件產品是能以合理的價格和時限在功能、質量上完全滿足用戶的期望。倘若一個項目團隊不重視需求過程,就會給軟件的成功與否帶來極大的風險。這些風險包括:
(1)缺乏一些基本功能,導致產品不被用戶接受
(2)用戶需求的增加導致產品開發(fā)成本的增加
(3)模糊的需求說明導致軟件產品的返工
(4)開發(fā)人員開發(fā)一些用戶用不到的功能
那么項目團隊應該如何解決上述問題呢?需要在需求過程中抓住以下四個基本原因:
(1)用戶參與不充分
從客戶的角度來看,他們通常不明白為什么收集需求需要花費那么多功夫,或者有些時候,用戶自己也不太明白真正的需求。
另一方面,有些開發(fā)人員也不重視用戶的參與。因為對于習慣編寫代碼的人,寫程序要比和用戶交流有趣的多。
還有一種可能就是開發(fā)人員覺得自己已經明白用戶的需求了。
對于此類問題的解決方法也很簡單:讓業(yè)務熟悉、具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中,并一同經歷整個開發(fā)過程。
(2)用戶需求的不斷增加
雖然用戶需求的不斷增加在絕大多數項目中,都是一個不可避免的問題,但是如果在整個軟件開發(fā)過程中,都有著持續(xù)不斷的補償需求,那么整個項目會變得越來越龐大,甚至超出了項目計劃和項目預算范圍,最后項目的完成將會很困難。
實際上,開發(fā)者可以將需求變更范圍控制到很小。需對項目視圖、范圍、目標、約束限制和成功標準給予準確說明,并將此說明作為評價需求變更和新特新的的參照框架。
(3)模棱兩可的需求
在需求規(guī)格說明中的諸多問題中,模棱兩成為可怕的問題。它讓不同的開發(fā)人員對同一個內容產生了不同的理解,它不但會讓軟件與用戶的要求不符合,而且在開發(fā)過程中給開發(fā)人員造成許多麻煩:比如它會讓開發(fā)人員因為錯誤的理解而浪費時間,并且使開發(fā)者與測試者的期望不一致。
模棱兩可的需求帶來不可避免的后果就是返工。
當然對于模棱兩可的需求的處理也有很多方法。其中一種是組織負責從不同角度審查需求的隊伍,因為簡單的瀏覽需求文檔時不能解決模棱兩可問題的,如果能讓不同的人從不同的角度來對需求文檔進行評審,就會真正的解讀需求文檔,避免了后期才發(fā)現的歧義,從而避免了軟件返工。
(4)畫蛇添足的功能
有些開發(fā)人員喜歡自作主張的添加一些“具有欣賞”性但是需求文檔中并未提及的功能,但是用戶并不覺得這些功能有用,反而增加了產品使用的復雜性,還讓開發(fā)人員的時間無意義的浪費了。因此作為開發(fā)人員來說,應當努力使軟件簡單易用,而不是未經用戶同意,就擅做主張,脫離實際。
同樣,作為用戶來說,有些用戶可能會要求加一些看上去很“酷”的功能,但是缺乏實用價值,而實現這些功能同樣會耗費額外的時間。為了將此類問題的損害減到最小,開發(fā)人員應該堅持一點:需求分析始終注重的是那些能使用戶完成他們業(yè)務的核心功能。
綜上所述,一個項目團隊如果實行高質量的需求分析過程就會獲得多方面的好處。最大的好處是開發(fā)后期和整個維護階段的重做工作大大減少了,開發(fā)成本和時間損耗也大大減少了。
為了完成完善需求階段的工作,形成規(guī)格說明是必要過程,可是僅僅完成需求規(guī)格說明是不夠的,開發(fā)人員不但要把所有客戶的需求應用到產品里,還要有效的控制需求與設計的一致,達到最準確的實現既定的需求的目的。需求管理另一個目標則是把軟件需求建立一個基線供軟件工程和管理使用。
許多項目組都遇到這樣的情況,定義需求時,無論怎樣謹慎和小心,總會有可變因素;變更需求之所以難以管理,是因為一個變更了的需求需要花費很多時間來實現一個新的特性和功能,而且有時候一個需求變更還會影響到其他需求。
所以,應當保證一個需求有一個彈性的結構,使他能更好的適應變更,從而能讓項目風險承擔者在開發(fā)過程中能控制變更。
為了讓變更控制更為有效,一個好的變更控制過程是必要的。好的變更過程給項目風險承擔者提供了正式的建議需求變更機制。通過這些處理過程,項目負責人可以在信息充分的條件下做出決策通過控制產品生存期成本來增加客戶和業(yè)務價值。當通過變更控制過程來跟蹤已建議變更的狀態(tài),就會確保不會丟失或疏忽已建議的變更。
大多數項目組對于需求的管理都是基于文檔,然而基于文檔存儲需求的方法有著若干限制及缺陷。例如難以保證文檔與現實的一致性、手工變更產生錯誤信息、低效率的工作和很難跟蹤每個需求的狀態(tài)等。使用需求管理工具就可以解決以上問題。
對于小項目來說,使用簡單的數據庫就可以管理需求。對于大項目就需要用到商業(yè)需求管理工具。
許多大型項目都有一個較為漫長的開發(fā)過程,隨著開發(fā)的進行,開發(fā)人員會逐漸記不清需求細節(jié),這時商業(yè)需求管理工具就會凸顯作用。它可以幫助開發(fā)人員管理需求變更、存儲需求屬性、幫助影響分析、跟蹤需求狀態(tài)、訪問控制、與風險承擔著進行溝通、重用需求等。
人工管理的話是很難實現如此多的功能。因此,使用商業(yè)需求管理工具,雖然會增加一些投入,但是卻可以讓項目組更好的獲益。
對于一個軟件項目來說,核心任務就是理解需要解決的問題并且解決它??茖W有效的需求分析為這個核心任務提供了成功的基礎。盡管就目前而言,改變軟件行業(yè)對于需求分析階段一貫的工作方式是較為困難的,但是隨著一些標準的推廣(如CMMI),對軟件開發(fā)過程中軟件需求分析的管理,會越來越規(guī)范和高效。