如何做好需求分析

2021-03-12 02:26:33 字數 4488 閱讀 1331

需求分析就是分析軟體使用者的需求是什麼.如果投入大量的人力,物力,財力,時間,開發出的軟體卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發乙個軟體,最後卻不滿足使用者的要求,從而要重新開發過,這種返工是讓人痛心疾首的.

(相信大家都有體會)比如,使用者需要乙個for linux的軟體,而你在軟體開發前期忽略了軟體的執行環境,忘了向使用者詢問這個問題,而想當然的認為是開發for windows的軟體,當你千辛萬苦地開發完成向使用者提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.

(這個問題是最典型也是最常見的,現在這個問題一般很好避免,都知道專案的一些敏感性的東西,例如想會有哪些地方設計的不好可能導致以後的使用出現bug.)

簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解使用者的各項要求,並準確地表達所接受的使用者需求.

需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.

問題識別

就是從系統角度來理解軟體,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標準.這些需求包括:功能需求(做什麼),效能需求(要達到什麼指標),環境需求(如機型,作業系統等),可靠性需求(不發生故障的概率),安全保密需求,使用者介面需求,資源使用需求(軟體執行是所需的記憶體,cpu等),軟體成本消耗與開發進度需求,預先估計以後系統可能達到的目標.

分析與綜合

逐步細化所有的軟體功能,找出系統各元素間的聯絡,介面特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).

制訂規格說明書

即編制文件,描述需求的文件稱為軟體需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.

評審對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。

需求分析的方法有很多.這裡只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.

原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的乙個早期可執行的版本,它實現了目標系統的某些或全部功能.

原型化方法就是盡可能快地建造乙個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,介面的友好性或其他方面上存在缺陷.建造這樣乙個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足使用者的需求等.如,為了考察是否滿足使用者的要求,可以用某些軟體工具快速的建造乙個原型系統,這個系統只是乙個介面,然後聽取使用者的意見,改進這個原型.

以後的目標系統就在原型系統的基礎上開發.

原型主要有三種型別(軟考考過):探索型,實驗型,進化型.探索型:

目的是要弄清楚對目標系統的要求,確定所希望的特性,並**多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.

進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。

在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:

先建造乙個功能簡單而且質量要求不高的模型系統,針對這個系統反覆進行修改,形成比較好的思想,據此設計出較完整,準確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。

追加策略:先構造乙個功能簡單而且質量要求不高的模型系統,作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求,發展成為最終系統。進化型屬於這種策略.

客戶與開發人員交流需要好的方法。下面建議20條法則,客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧,將通過協商達成對各自義務的相互理解,以便減少以後的磨擦(如一方要求而另一方不願意或不能夠滿足要求)。

1、 分析人員要使用符合客戶語言習慣的表達

需求討論集中於業務需求和任務,因此要使用術語。客戶應將有關術語(例如:採價、印花商品等採購術語)教給分析人員,而客戶不一定要懂得計算機行業的術語。

2、分析人員要了解客戶的業務及目標

只有分析人員更好地了解客戶的業務,才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員,客戶可以考慮邀請他們觀察自己的工作流程。

如果是切換新系統,那麼開發和分析人員應使用一下目前的舊系統,有利於他們明白目前系統是怎樣工作的,其流程情況以及可供改進之處。

3、 分析人員必須編寫軟體需求報告

分析人員應將從客戶那裡獲得的所有資訊進行整理,以區分業務需求及規範、功能需求、質量目標、解決方法和其他資訊。通過這些分析,客戶就能得到乙份「需求分析報告」,此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。

客戶要評審此報告,以確保報告內容準確完整地表達其需求。乙份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。

4、 要求得到需求工作結果的解釋說明

分析人員可能採用了多種圖表作為文本性「需求分析報告」的補充說明,因為工作圖表能很清晰地描述出系統行為的某些方面,所以報告中各種圖表有著極高的價值;雖然它們不太難於理解,但是客戶可能對此並不熟悉,因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果,以及怎樣檢查圖表有無錯誤及不一致等。

5、 開發人員要尊重客戶的意見

如果使用者與開發人員之間不能相互理解,那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為專案成功所付出的時間,同樣,客戶也應對開發人員為專案成功這一共同目標所做出的努力表示尊重。

6、 開發人員要對需求及產品實施提出建議和解決方案

通常客戶所說的「需求」已經是一種實際可行的實施方案,分析人員應盡力從這些解決方法中了解真正的業務需求,同時還應找出已有系統與當前業務不符之處,以確保產品不會無效或低效;在徹底弄清業務領域內的事情後,分析人員就能提出相當好的改進方法,有經驗且有創造力的分析人員還能提出增加一些使用者沒有發現的很有價值的系統特性。

7、 描述產品使用特性

客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性,因為這些易用特性或質量屬效能使客戶更準確、高效地完成任務。例如:客戶有時要求產品要「介面友好」或「健壯」或「高效率」,但對於開發人員來講,太主觀了並無實用價值。

正確的做法是,分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性,具體分析哪些特性對哪些特性有負面影響,在效能代價和所提出解決方案的預期利益之間做出權衡,以確保做出合理的取捨。

8、 允許重用已有的軟體元件

需求通常有一定靈活性,分析人員可能發現已有的某個軟體元件與客戶描述的需求很相符,在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間,而不必嚴格按原有的需求說明開發。所以說,如果想在產品中使用一些已有的商業常用元件,而它們並不完全適合您所需的特性,這時一定程度上的需求靈活性就顯得極為重要了。

9、 要求對變更的代價提供真實可靠的評估

有時,人們面臨更好、也更昂貴的方案時,會做出不同的選擇。而這時,對需求變更的影響進行評估從而對業務決策提供幫助,是十分必要的。所以,客戶有權利要求開發人員通過分析給出乙個真實可信的評估,包括影響、成本和得失等。

開發人員不能由於不想實施變更而隨意誇大評估成本。

10、 獲得滿足客戶功能和質量要求的系統

每個人都希望專案成功,但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有資訊,而且還要求開發人員能通過交流了解清楚取捨與限制,一定要明確說明您的假設和潛在的期望,否則,開發人員開發出的產品很可能無法讓您滿意。

11、 給分析人員講解您的業務

分析人員要依靠客戶講解業務概念及術語,但客戶不能指望分析人員會成為該領域的專家,而只能讓他們明白您的問題和目標;不要期望分析人員能把握客戶業務的細微潛在之處,他們可能不知道那些對於客戶來說理所當然的「常識」。

12、 抽出時間清楚地說明並完善需求

客戶很忙,但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論,接受採訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點,而過後發現還需要您的講解,這時請耐心對待一些需求和需求的精化工作過程中的反覆,因為它是人們交流中很自然的現象,何況這對軟體產品的成功極為重要。

13、 準確而詳細地說明需求

編寫乙份清晰、準確的需求文件是很困難的。由於處理細節問題不但煩人而且耗時,因此很容易留下模糊不清的需求。但是在開發過程中,必須解決這種模糊性和不準確性,而客戶恰恰是為解決這些問題作出決定的最佳人選,否則,就只好靠開發人員去正確猜測了。

在需求分析中暫時加上「待定」標誌是個方法。用該標誌可指明哪些是需要進一步討論、分析或增加資訊的地方,有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚,以便分析人員能準確地將它們寫進「軟體需求報告」中去。

如果客戶一時不能準確表達,通常就要求用原型技術,通過原型開發,客戶可以同開發人員一起反覆修改,不斷完善需求定義。

14、 及時作出決定

分析人員會要求客戶作出一些選擇和決定,這些決定包括來自多個使用者提出的處理方法或在質量特性衝突和資訊準確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切,盡快做處理,做決定,因為開發人員通常只有等客戶做出決定才能行動,而這種等待會延誤專案的進展。

如何做好專案需求分析

5,軟體產品的價值在於其不斷的創新,企業唯有將創新納入有效的管理規劃之中,遵循明確的指導原則和方 進行持續不斷的系統化創新,才能長久地保持競爭優勢。分析師的作用不僅僅是了解使用者的需要,更需要在早期以一種創新思維參與產品構思,幫助使用者從自己的現狀中釋放出來,這就要求分析師具有很強的創新能力。6,為...

如何做好需求管理

二 讓客戶開啟話匣子 對客戶進行提問,引導客戶說出他們的需求,是非常關鍵的,這裡面的學問也是很大的。有一些人通常會問這樣的問題 你們的工作流程是什麼樣的?這種問題是非常經典的無效問題。當你向客戶提出問題的時候,你可以先進行換位思考,如果有人問你這個問題你該怎麼回答呢?是不是很好回答呢?如果連你也覺得...

如何做好酒店的培訓需求分析

很多酒店都非常的重視員工培訓,但是又經常抱怨培訓沒有效果,結果是員工埋怨培訓沒有意思 內容單 一 華而不實 培訓師出力不討好 管理層對培訓部意見很大。其實拋開一些培訓技術方面的問題,出現這個問題很大程度上是培訓需求分析沒有做好的緣故。那麼究竟什麼才是正規的培訓需求分析具體方法 組織分析 決定酒店中 ...