1.尋找哲學家的石頭（ps:哲學家的石頭，真善美結合體，此處意思應爲，完美的解決方案？）：爲何我們想要一個理性的設計過程
一個完美的理性人是他做的每一件事情都由一個好的理由。他採取的每一步都可以被證明是達成一個設計好的目標的最好的方式。我們大多數人都傾向於認爲自己是理性的專家。但是，對大多數研究者來說，通常的軟件設計過程表現的相當非理性。軟件設計者開始時並沒有對期望的行爲和實現約束有一個明確的聲明。他們在沒有對爲什麼他們以他們做事情的方式有明確說明的情況下做了一系列的決定。他們的推理過程很少被解釋。
我們之中很多人對這樣的一個設計過程並不滿意。這就是爲什麼有對軟件設計，編程方法，結構化編程以及相關課題的研究。理想情況下，我們希望我們的程序來源於一個明確的需求，統一，我們希望定理是從出版的公理推導出的。所有被認爲組織嚴密的方法論都源於我們想要有一個理性的系統的軟件設計過程。
本論文將給你帶來既有好的消息也有壞得消息。壞消息是，以我們的觀點，我們永遠找不到哲學家的石頭。我們永遠也找不到一個可以讓我們以完美的理性方式來設計軟件的流程。好消息是，我們可以複製他。我們可以想其他人展現我們的方法，就好像我們是理性的設計者，並且在開發和維護中如此做事值得的。
2.爲什麼軟件設計過程總是非理想化的呢？
我們從來沒有看到過一個軟件項目以理性的方式進行。原因如下：
（1)大多數情況下，發佈軟件構建任務的人不準確的知道他們相應什麼並且部能夠告訴我們他們知道的全部內容。
(2) 就算我們知道需求，設計軟件還有許多其他內容需要知道。許多細節只有到實現的時候我們才知道。有些時候我們發現我們的設計不能使用，需要會對。由於我們試着最小化浪費的工作，理想的是設計可能來自於非理性的過程。
(3)就算我們在開始前就知道相關的內容，經驗表明人類不能夠完全瞭解爲了設計和構建一個正確的系統需要考慮的很多細節。設計軟件的過程是我們爲了使用可控數量信息工作而嘗試抽象的過程。然而，在我們抽象之前，我們註定會犯錯。
(4）經我們可以掌握需要的細節，除了試驗項目外所有的項目註定會因外部原因而改變。其中有一些改變會使前期的設計失效。這導致沒有一個軟件是由理性化的設計過程產出的。
(5)人爲錯誤只有不使用人時纔可以避免。就算在抽象之後，也會犯錯。
(6)我們經常受先入爲主的設計理念，我們發明的想法，從其他相關項目獲取的理念或者從課堂上聽到的理念。有時候我們爲了嘗試或使用一個理念而開發一個項目。這些理念可能並不是由理性過程中的需求分析獲得的。
(7)我們經常由於經濟原因會被鼓勵使用爲其他項目開發的組件。在其他情況下我們會被鼓勵和其他症狀開發的項目共享我們的組件。結果程序可能對所有的項目都不是理想的，也就是說，我們開發的軟件不是僅僅基於需求，也因爲它是足夠好的，所以我們就節省精力了。
由於以上原因，軟件設計者在理性的，不犯錯誤的，從明確的需求的情況下進行設計是不現實的。以前沒有程序在這種情況下開發，估計以後也不會有。甚至於教科書和論文中的小開發項目也是部真實的。它們被不斷的修改知道作者認爲能夠表達他期望他已經完成的東西，而不是確實發生的事情。
3.然而爲什麼描述一個理想化的理想設計過程是有用的？
對於每一個細心的思考者來說，上面說的是顯而易見的，並且是被誠實的人所承認的。除了我們看到的軟件設計過程的討論者，以軟件設計方法爲工作的人和描述理性軟件設計過程的創意市場的課程設計者。這些人想達到什麼目的呢？
如果我們有一個理想的設計過程但是不能夠完全遵循，我們可以儘量接近並且我們可以寫我們將要構建的軟件的文檔，如果我們遵循理性的設計過程。這就是我們說複製理性的設計過程的含義。
下面是複製理性設計過程的一些原因：
（1）設計者需要指導。當我們承擔一個大項目時，我們很容易被大量的任務包圍。我們不確定需要先做什麼。對理想化的設計過程的理解能夠幫助我們知道如何處理。
（2）我們會逐漸接近理性的設計，如果我們嘗試遵循一個流程而不是基於臨時的想法。例如，儘管我們部能夠知道設計一個理想系統的所有知識，但是在編碼之前，爲尋找這些知識的努力會幫助我們設計的更好，回退的更少。
（3）當一個組織承擔很多軟件項目是，有一個標準是有利的。這有利於設計走查，人員，想法和模塊從一個項目到另一個項目轉換。如果我們需要遵循一個標準，那麼這個標準應該是理性的。
（4）如果我們承諾進行理想的流程，那麼度量項目的流程會更容易。我們可以以流程的需要來比較項目的成效。我們可以確認我們在哪些方面做的好，哪些方面做的不好。
（5）外部人員對項目規律性的流程檢查是好的管理的基礎。如果項目遵循一個理想話的路程，那麼會更便於檢查。
4.開發流程的描述能夠告訴我們什麼?
流程描述的最有效產出是項目產品。對於流程的每一個階段，本論文說：
(1)我們下面要工作的產品?
(2)我們的工作產品要滿足的標準?
(3)需要什麼樣的人來進行工作?
(4)工作中他們需要哪些信息？
任何部以工作產品描述的流程的管理都只能被會讀心術的人完成。只有我們知道要完成哪些產品並且知道它們需要滿足的標準，我們纔可以檢查項目和評價流程。
5.什麼是理想化的設計流程？
本小節描述理性的理想化的設計過程應該嘗試遵循的東西。每一步都要有對該步需要完成的工作產品的詳細描述。
對流程的描述部應該只包含測試和檢查。雖然，這兩者是不可忽略的。當一個作者應用本文種描述的流程時，我們包含對每個工作產品的可擴展的和系統化的檢查和對可執行代碼的測試。檢查流程在11頁和17頁討論。
A。構建和需求文檔
如果我們是理性的設計者，我們必須知道我們需要做什麼會成功。這個信息應該被記錄在一個工作產品中作爲文檔要求。在我們對需求開始設計之前。
（I)爲什麼我們需要一個需求文檔？
（1）我們需要一個地方來記錄用戶向我們描述的系統預期的行爲。我們需要一個文檔供用戶或他的代表檢查。
（2）我們想要避免在設計程序的過程中需求的隨意變更。面向系統開發的軟件開發者經常對應用是不熟悉的。有一個對可視行爲的明確定義使他們可以決定怎樣是對用戶最好的。
(3)我們想避免重複和不可持續。沒有需求文檔的情況下，許多文檔解決的問題會被軟件設計者、軟件編碼者、檢查者，一次又一次詢問。這增加了工作成本並且可能答案並不統一。
(4)一個完整的需求文檔對於估算建立系統工作量和其他資源是必須的（但並不足夠）。
（5）需求文檔是對避免人員流動的損失的保障。我們從需求中獲取的知識可能會隨人員流動而丟失。
（6)需求文檔爲測試計劃提供了一個好的基礎。如果沒有需求，我們就不知道怎麼測試。
（7）需求文檔可以在系統使用很長時間後仍然被使用，勇於約束未來的變更。
（8）需求文檔可以避免軟件開發者之間的爭論。如果我們有一個完整的和準確的需求文檔，我們就不需要或諮詢需求專家。
（II）什麼內容被寫入需求文檔？
對理想化的需求文檔的定義很簡單。它需要包括你開發可供用戶接受的軟件需要的所有知識，沒有其他內容。當然，我們可能使用對已有信息的引用，如果那些信息是準確並經過良好組織的。一個理想化的需求文檔，可接受的標準如下：
（1）每一個陳述需要對所有的可接收的產品有效。沒有東西依賴於實現決定。
（2）文檔需要完整，也就是說，如果產品滿足所有的陳述，那麼，產品就是可接受的。
（3）在開發前部能夠明確確定的信息，不完整的部分需要明確說明。
（4）產品需要被組織作爲引用文檔而不是對系統的陳述性的介紹。儘管編寫這樣一份文檔是困難的，一個引用比瀏覽一個介紹性的東西，但是從長遠來說，是節省工作量的。本階段獲取的信息被記錄以容易被整個項目過程中引用的形式。
（III）誰編寫需求文檔？
（1）理想情況下，需求文檔有用戶或他們的代表編寫。實際上，用戶很少具有編寫該文檔的能力。另一方面，軟件開發者必須編寫一個草稿文檔然後被檢查最終被用戶認同。
（IV）需求規格說明書背後的數學模型是什麼？
爲了保證文檔的完整性和可持續性，在文檔組織背後必須有一個簡單的數學模型。下面的模型是由對實時系統的工作產生的，但是因爲這，它是完全通用的。所有的系統都可以被描述爲一個實時系統，儘管對實時性要求不高。
模型鑑定理想的產品不是一個純粹的數字計算器，是一個由模擬計算器控制的數字計算器。模擬計算器將持續的輸入值轉換爲持續的輸出值。一個純粹的數字計算器或純粹的模擬計算器是通用模型的特例。將要開發的系統是一個進行數字估算的混合系統。就像在其他工程領域裏一樣，我們可以首先通過對系統的描述我們的規格說明書，然後細化可以接受的容忍度。需求文檔重視輸出過於重視輸入。如果輸出的值是正確的，沒有人會在乎輸入值甚至是否被讀取。需求文檔的核心是以表格形式描述的一系列數學方法。每一個表格描述多個狀態變量經一個方法計算後的值。
（V)需求文檔應該怎樣組織？
需求文檔的完整性可以通過抽象的獨立來獲取以下部分：
(1)計算機規格說明：程序需要運行的機器規格。這個機器不是指硬件。對於一些軟件來說，這部分僅僅指出幫助手冊語言。
讀後感：對需求的明確定義，以文檔輔助設計。通過不斷的估計和調整計劃，獲取交付日期，避免軟件黑洞情況。