軟體需求分析方法總結 如何分析問題和需求

2021-08-25 18:32:04 字數 3545 閱讀 5322

如何分析問題和需求

萬事開頭難,需求沒有完全分析清楚,系統設計很難滿意。面對專案,我們如何提出問題,如何界定問題主次,哪些問題必須定義,哪些問題可暫時不理......。

一、提出問題

1.樹狀遍歷式尋找問題

每個問題都不是單一存在的,它都有相關問題,猶如一棵樹一樣,主問題就是主樹杆,主問題伴隨的其他問題,就是支樹桿,以次類推。首先不要怕麻煩,每當乙個問題提出,必須提出盡量多的相關新問題。提出問題的方法:順藤摸瓜。

2)如果資料型別不確定,我們如何確定程式編寫的物件。可以舉出一些可能的假設。假設我們將此通用編輯器用作程式源**編輯,那麼就應該有中斷、單步執行等設定,這導致資料不能封裝在編輯器內部,應該由後期開發指定資料結構。

3)如果是程式編輯器,關鍵字的特顯必不可少,所以顯示的屬性應該給出介面。

4)諸如關鍵字此類的是否還有其他需要特顯的,那麼,應該注意到特顯類不僅僅是一種,程式設計時,最好抽象出特顯的方法與資料結構(不管以後有多少不可預知的特顯內容)。可以深入考慮特顯介面應該如何給出,才能支援任意特顯方式,它還需要哪些資訊。

5)抽象特顯類時,應該舉出盡量多的可能性,綜合考慮。

10)未知資料應該有:顯示方法、游標定位處理等

11)游標定位需要當前座標,所以,必須有介面讓編輯器知道資料寬高。

首先任其深入提問,雖然問題可能多得十分複雜或凌亂,但它對即將做的系統設計絕對有幫助,最好把每個問題都有乙個清楚的了解,千萬不要急於設計系統。通過這些提問和假設,就可清楚地分析我們所作的軟體應該實現哪些內容,哪些內容實現有難度,實現這些內容的大體方法,通用編輯器能作什麼。通過上列系列提問和解答,我們可以認為,通用編輯器僅僅是乙個以行為基本編輯單位的編輯器摸板。編輯器不僅自己有編輯操作,同時允許外部提供特殊資料物件的編輯操作,最終實現文字編輯、圖形編輯、**編輯、公式編輯一體化。資料外部實現,將允許後期確定內容屬性。

上述方法基本上確保了軟體有好的可靠性、擴充套件能力、效能、重用性和系統化。想高效率生產系列軟體,確實應該考慮的更多。

2.直接切入目標問題

直接提出軟體要完成的系列任務,通過考慮任務的實現,羅列問題,在問題的解答過程中反思任務的需求。這樣的方法可以快速設計出軟體開發方案。

3)顯示:文字的不同字型風格顯示、圖形的顯示、圖象的顯示、**等的顯示。

5)考慮各項功能的實現方案,發現問題。

6)如果有沒有考慮到的,增加進去。

7)經過許多的方案設計,綜合考慮和優化方案,提出最後的設計方案

經過一系列的方案定義,將問題逐步減少,最後獲得乙個規模較大的系統設計早期方案。我們可以較早地進入系統設計,並且提前進入程式**級開發工作,同時逐步實現各項內容。

此方法分析需求,有助於我們盡早實現想法,同時較好地控制住程式開發方向和基本功能完成的進度。但遺憾的是提高開發速度的代價是降低程式的可靠性、擴充套件性和重用性。過去,我們往往覺得所作的程式基本上不能再次使用,原因就在於沒有抽象問題,尋找問題的根本解決方案。就問題實現問題的方法,忽略了深入分析問題的過程。對於針對開發某專業的應用軟體採用此方法分析需求比較合適,但對系統性強的軟體,最好採用樹狀遍歷式尋找問題的方法。

二、分析問題和需求

在沒有分析清楚問題和需求的來由就匆匆下定論是非常危險的。忽略問題和需求就可能埋下了潛在的程式或系統設計問題。我們也常常犯這樣的錯誤:由於沒有分析清楚問題和需求,結果到頭來更改系統設計。能夠提出的問題和需求,就一定要扎扎實實分析它,否則後果難料。

分析問題和需求的能力大小與思路和經驗有關。好的思路**於嚴謹、邏輯和跳躍的思考習慣。嚴謹要求不要放過任何乙個小問題,邏輯要求思考的過程應該是一種符合規則的推導過程,跳躍思維要求思考的路子不是一走到底而是多條路子並行著走。經驗來自於編寫除錯大量程式和善於總結,要求程式設計師不斷地開發新程式和創造新思路,並且敢於嘗試和接受失敗,當然還有一條重要的方面:跟蹤最新技術。

如何正確分析問題,有以下幾個要素值得注意:

1.所有問題和需求都有發生的根源。

問題和需求的表面現象總是與開發者思路切入點相關,如果切入點是狹隘的,那麼圍繞著問題和需求的分析往往侷限於自身的思路範圍,問題和需求產生的原因就很難發覺。所以當不能理解分析問題和需求時,不妨先找一找為什麼存在這樣的問題和需求,它的存在是否合理,然後再分析理解它就不難了。思路一定要跳出慣例。

2.交替反覆分析多個問題和需求,尋找問題間的共性和特性

看似問題和需求間沒有聯絡,而且分析不清各自意義,那麼建議交替反覆分析考慮這些問題。勤能補拙,不要擔心它將花費開發者多少時間,只有開發者仔細分析問題需求,以後的工作越來越簡單明瞭。

3.複雜化問題,

問題複雜化,是乙個抽象問題或需求的逆過程,提出問題需求的許多可能的假設,豐富了問題需求的形式。能夠複雜化問題,本身就體現了分析問題和需求的能力。比如:做乙個加法程式,兩個數相加,返回結果。簡單的問題,但,我們一般都按兩整數加法,有時考慮了浮點加法。為什麼不是兩個複數相加,或者是兩個字串相加等。這是乙個使用操作符過載或類模板解決的簡單例子,在這裡我的意圖是許多問題應該從更多的方面去驗證問題是否同樣存在。

4.問一問自己:問題是否能夠抽象化,繼而簡化問題。

眾多的問題和需求變成程式**的過程,就是公式化問題和需求。如果象上例加法一樣,不管三七二十一,什麼樣的資料就寫一段什麼的**,不同型別資料間的加法同樣又要寫一段**,這樣下去就寫不完了。抽象問題,簡化問題,類模板就是乙個抽象問題很好的例子。在分析問題和需求的過程中,同樣採用物件導向的思維方式去求解,會獲得乙個非常滿意的需求報告。

5.問題和需求分類分主次考慮

1)軟體產品的效能指標:可靠、功能全、速度、易擴充套件。

易擴充套件:一種是產品公升級換代快、系列化產品豐富。另一種是使用者的二次開發擴充套件產品的再生功能。

速度:表示軟體執行速度不僅要快,同時操作中的速度要均衡。

功能全:大而全不一定是不好,有能力和實力,最好做到功能盡量全。功能全直接體現軟體開發商的實力。

可靠:這是最為重要的一點,軟體首要考慮的應該是可靠。測試時,極限、異常操作都應該考慮進去。

2)問題和需求根據軟體產品的效能指標和實現難度分類:核心需求,基本功能需求,高階功能需求、組合功能需求。

核心需求:直接影響速度、可靠、易擴充套件指標的好壞。比如:cad刷屏要求速度、cad命令列機制提高了易擴充套件效能、cad內部資料結構的管理機制直接影響軟體的可靠性。核心需求將定義出軟體的本質內容,它主要以程式設計原理為基礎,結合軟體任務需求定義資料結構和管理機制。核心需求是首先要確定下來的,是最主要的工作。

基本功能需求:完成任務的最基本的操作功能集合,這些基本功能是軟體產品的底層處理功能,是眾多問題和需求中抽象出的共性部分,它是其他功能的基礎。基本功能需求也是非常重要的,它的好壞直接影響到後面高階功能的質量和能力。

高階功能:是眾多問題和需求中的特性部分,這些功能對某個應用是非常有用,但在另乙個應用中可能沒有用。比如:cad中的圖形計算:求面積或體積,在建築施工圖設計中沒有使用,但在計算路基方面則非常有用。高階功能的需求應該放在較次要的位置,

組合功能:通過基本功能和高階功能組合操作後的功能。例如:cad中的lisp語言,cad的批命令輸入,cad的圖塊功能等。這些借助於基本功能和高階功能的組合功能是一種後期行為,沒有這些功能,軟體一樣可以使用,所以,這些需求開發並不需要急於實現,但一定要在核心中考慮組合機制。

總之,需求分析是導致軟體產品好壞的關鍵工作,導致軟體開發難易程度大小的絕對因數。寧可將需求分析的時間給充足一些,也不願以後在程式設計階段補充修改需求(雖然修改需求是不可避免的事實)。

軟體需求分析方法總結

align center 撰寫優秀的需求 by karl wiegers.bear縮譯 軟體需求常常被寫得很糟且難於遵循。清楚地闡明你的需求將使每位專案參與者獲益。需求說明總的特點 1 它們必須是正確的。2 它們必須是可行的 3 它們必須是對專案來說是必不可少的。4 它們必須是被標明優先次序的。5 ...

軟體需求分析方法

軟體需求分析方法大體分為如下四類 結構化方法 物件導向方法 面向控制方法和面向資料方法 結構化分析方法 結構化分折 structured analysis,sa 方法是一種單純的由頂向下 逐步求精的功能分解方法。分析員首先用上下文圖表 稱為 資料流圖dfd 表示系統的所有輸入 輸出,然後反覆地對系統...

軟體專案需求分析總結

需求分析是專案開發的基礎,基礎打的牢不牢直接關係到後面所有的工作,是專案實施成敗的關鍵 總體上說,我們的需求分析是做了,但是做得很不夠,我們做的需求只解決了我們能做出這樣的專案,但是沒有解決這樣的專案是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況 客戶本身說不清楚 文物網是這樣,中彰國...