如何分析問題和需求

1.樹狀遍歷式尋找問題

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

比如：寫一個通用編輯器程序，此程序為自己或別人開發其他專業編輯器打下可靠穩定的基礎。

1）問題：什么是通用編輯器。編輯器面向的對象應該是不確定的。

2）如果數據類型不確定，我們如何確定程序編寫的對象?？梢耘e出一些可能的假設。假設我們將此通用編輯器用作程序源代碼編輯，那么就應該有中斷、單步執行等設置，這導致數據不能封裝在編輯器內部，應該由后期開發指定數據結構。

3）如果是程序編輯器，關鍵字的特顯必不可少，所以顯示的屬性應該給出接口。

4）諸如關鍵字此類的是否還有其他需要特顯的，那么，應該注意到特顯類不僅僅是一種，程序設計時，最好抽象出特顯的方法與數據結構（不管以后有多少不可預知的特顯內容）?？梢陨钊肟紤]特顯接口應該如何給出，才能支持任意特顯方式，它還需要哪些信息。

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

6）問題：哪些內容需要特顯。編輯器很難知道，數據類應該自己了解。所以，特顯內容的定義必須有一個機制讓后期開發時使用。

7）問題：源代碼編輯器有自動縮排、詞法、語法分析，這些操作如何在編輯器中體現?？紤]語法類接口。是否有收縮與展開操作，接口又如何。

8）又假設：后期要擴展成字處理程序。數據有文本、圖象、特殊公式編輯、段落概念、表格等。

9）送進編輯器的數據可能是一組含有控制字的數據，問題：如何獲得讓編輯器知道不同數據的不同顯示操作。編輯器肯定無法全知，所以，干脆交給后期開發需求處理。

10）未知數據應該有：顯示方法、光標定位處理等

11）光標定位需要當前坐標，所以，必須有接口讓編輯器知道數據寬高。

12）綜合結論：應該有一個接口機制。凡特殊操作的內容，交給后期處理，但通用編輯器應該做好數據管理和傳送的工作，而這些工作，不管哪種編輯器都需要。

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

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

2.直接切入目標問題

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

仍然以通用編輯器為例：

1）編輯對象有：文本、圖形、圖象、表格等。

2）操作有：焦點移動、增加、刪除、存取盤、選擇塊、粘貼拷貝、縮進、展開收縮、書簽、中斷設置、單步執行標記等。操作有分文本、圖形圖象、表格等的操作編輯。

3）顯示：文本的不同字體風格顯示、圖形的顯示、圖象的顯示、表格等的顯示。

4）狀態設置：改寫插入、段落格式設置、標題控制、編輯器專業化的設置等

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

6）如果有沒有考慮到的，增加進去。

7）經過許多的方案設計，綜合考慮和優化方案，提出最后的設計方案

8）綜合結論：程序考慮了諸多功能，通用編輯器是眾多功能的集合體，內部詳細規劃了各種類型數據的操作、顯示和排版分析。

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

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

二、分析問題和需求

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

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

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

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

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

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

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

3.復雜化問題，

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

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

眾多的問題和需求變成程序代碼的過程，就是公式化問題和需求。如果象上例加法一樣，不管三七二十一，什么樣的數據就寫一段什么的代碼，不同類型數據間的加法同樣又要寫一段代碼，這樣下去就寫不完了。抽象問題，簡化問題，類模板就是一個抽象問題很好的例子。在分析問題和需求的過程中，同樣采用面向對象的思維方式去求解，會獲得一個非常滿意的需求報告。

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

1）軟件產品的性能指標：可靠、功能全、速度、易擴展。

易擴展：一種是產品升級換代快、系列化產品豐富。另一種是用戶的二次開發擴展產品的再生功能。

速度：表示軟件執行速度不僅要快，同時操作中的速度要均衡。

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

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

2）問題和需求根據軟件產品的性能指標和實現難度分類：核心需求，基本功能需求，高級功能需求、組合功能需求。

核心需求：直接影響速度、可靠、易擴展指標的好壞。比如：CAD刷屏要求速度、CAD命令行機制提高了易擴展性能、CAD內部數據結構的管理機制直接影響軟件的可靠性。核心需求將定義出軟件的本質內容，它主要以程序設計原理為基礎，結合軟件任務需求定義數據結構和管理機制。核心需求是首先要確定下來的，是最主要的工作。

基本功能需求：完成任務的最基本的操作功能集合，這些基本功能是軟件產品的底層處理功能，是眾多問題和需求中抽象出的共性部分，它是其他功能的基礎?；竟δ苄枨笠彩欠浅Ｖ匾?，它的好壞直接影響到后面高級功能的質量和能力。

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

組合功能：通過基本功能和高級功能組合操作后的功能。例如：CAD中的LISP語言，CAD的批命令輸入，CAD的圖塊功能等。這些借助于基本功能和高級功能的組合功能是一種后期行為，沒有這些功能，軟件一樣可以使用，所以，這些需求開發并不需要急于實現，但一定要在核心中考慮組合機制。

總之，需求分析是導致軟件產品好壞的關鍵工作，導致軟件開發難易程度大小的絕對因數。寧可將需求分析的時間給充足一些，也不愿以后在編程階段補充修改需求（雖然修改需求是不可避免的事實）。

原文轉自：http://www.anti-gravitydesign.com