在上一代程序設計中（即“過程化或程序化設計”），這個階段稱為“建立需求分析和系統規格”。當然，那些操作今天已經不再需要了，或者至少改換了形式。大量令人頭痛的文檔資料已成為歷史。但當時的初衷是好的。需求分析的意思是“建立一系列規則，根據它判斷任務什麼時候完成，以及客戶怎樣才能滿意”。系統規格則表示“這裡是一些具體的說明，讓你知道程序需要做什麼（而不是怎樣做）才能滿足要求”。需求分析實際就是你和客戶之間的一份合約（即使客戶就在本公司內部工作，或者是其他對象及系統）。系統規格是對所面臨問題的最高級別的一種揭示，我們依據它判斷任務是否完成，以及需要花多長的時間。由於這些都需要取得參與者的一致同意，所以我建議盡可能地簡化它們——最好采用列表和基本圖表的形式——以節省時間。可能還會面臨另一些限制，需要把它們擴充成為更大的文檔。
我們特別要注意將重點放在這一階段的核心問題上，不要糾纏於細枝末節。這個核心問題就是：決定采用什麼系統。對這個問題，最有價值的工具就是一個名為“使用條件”的集合。對那些采用“假如……，系統該怎樣做？”形式的問題，這便是最有說服力的回答。例如，“假如客戶需要提取一張現金支票，但當時又沒有這麼多的現金儲備，那麼自動取款機該怎樣反應？”對這個問題，“使用條件”可以指示自動取款機在那種“條件”下的正確操作。
應盡可能總結出自己系統的一套完整的“使用條件”或者“應用場合”。一旦完成這個工作，就相當於摸清了想讓系統完成的核心任務。由於將重點放在“使用條件”上，一個很好的效果就是它們總能讓你放精力放在最關鍵的東西上，並防止自己分心於對完成任務關系不大的其他事情上面。也就是說，只要掌握了一套完整的“使用條件”，就可以對自己的系統作出清晰的描述，並轉移到下一個階段。在這一階段，也有可能無法完全掌握系統日後的各種應用場合，但這也沒有關系。只要肯花時間，所有問題都會自然而然暴露出來。不要過份在意系統規格的“完美”，否則也容易產生挫敗感和焦燥情緒。
在這一階段，最好用幾個簡單的段落對自己的系統作出描述，然後圍繞它們再進行擴充，添加一些“名詞”和“動詞”。“名詞”自然成為對象，而“動詞”自然成為要整合到對象接口中的“方法”。只要親自試著做一做，就會發現這是多麼有用的一個工具；有些時候，它能幫助你完成絕大多數的工作。
盡管仍處在初級階段，但這時的一些日程安排也可能會非常管用。我們現在對自己要構建的東西應該有了一個較全面的認識，所以可能已經感覺到了它大概會花多長的時間來完成。此時要考慮多方面的因素：如果估計出一個較長的日程，那麼公司也許決定不再繼續下去；或者一名主管已經估算出了這個項目要花多長的時間，並會試著影響你的估計。但無論如何，最好從一開始就草擬出一份“誠實”的時間表，以後再進行一些暫時難以作出的決策。目前有許多技術可幫助我們計算出准確的日程安排（就象那些預測股票市場起落的技術），但通常最好的方法還是依賴自己的經驗和直覺（不要忘記，直覺也要建立在經驗上）。感覺一下大概需要花多長的時間，然後將這個時間加倍，再加上10％。你的感覺可能是正確的；“也許”能在那個時間裡完成。但“加倍”使那個時間更加充裕，“10％”的時間則用於進行最後的推敲和深化。但同時也要對此向上級主管作出適當的解釋，無論對方有什麼抱怨和修改，只要明確地告訴他們：這樣的一個日程安排，只是我的一個估計！
