需求和設計之間存在差別，但應盡量使你的規(guī)格說明的具體實現(xiàn)無傾向性。理想情況是：
在設計上的考慮不應該歪曲對預期系統(tǒng)的描述。需求開發(fā)和規(guī)格說明應該強調(diào)對預期系統(tǒng)外部行為的理解和描述。讓設計者和開發(fā)者參與需求審查以判斷需求是否可以作為設計的基礎。
不同的軟件設計方法常常都會滿足最終需求，而設計方法會隨著性能、有效性、健壯性以及所采用的技術上的不同而變化。如果你直接從需求規(guī)格說明跳到編碼階段，你所設計的軟件將會是空中閣樓，其可能的結果只能是結統(tǒng)的最有效的方法?？紤]一下其它的設計方案將有助于確保開發(fā)人員遵從所提出的設計約束或遵從與設計有關的質(zhì)量屬性規(guī)格說明。
曾經(jīng)參與一項項目，進行了完整的需求分析，建立了詳細描述模擬攝像系統(tǒng)行為的8個變換過程的數(shù)據(jù)流程圖。經(jīng)過大量的需求分析后，我們并沒有直接進行源代碼的編寫工作。而是以數(shù)據(jù)流程圖為表示方法，創(chuàng)建了一個設計模型。我們立刻意識到模型中有三個步驟使用了相同的計算算法，另外三個使用不同的方程集，而剩下的兩個步驟共享三分之一集合。
分析模型代表了用戶和開發(fā)小組對我們正在解決的問題的理解，而設計模型則描繪了我們應該如何構造系統(tǒng)。通過設計期間的仔細思考，我們把核心問題簡化了60%，把8個復雜的計算集合減少到3個。如果我們在需求分析之后立刻進行編碼，那么在構造階段必定會出現(xiàn)代碼重復。但是，由于及早發(fā)現(xiàn)了可簡化問題，節(jié)省了許多時間和金錢。設計上的返工比編碼返工可能要效率高一些。
以需求為基礎，反復設計將產(chǎn)生優(yōu)良成果。當你得到更多的信息或額外的思想時，用不同的方法進行設計可以精細化你最初的概念。設計上的失誤將導致軟件系統(tǒng)難以維護和擴充，最終會導致不能滿足客戶在性能和可靠性上的目標。在把需求轉(zhuǎn)化為設計時你所花的時間將是對建立高質(zhì)量、健壯性產(chǎn)品的關鍵的投資。
在設計產(chǎn)品時，產(chǎn)品的需求和質(zhì)量屬性決定了所采用的合適的構造方法。研究和評審所提出的體系結構是另一種解釋需求的方法且會使需求更加明確。與原型法類似，這是一種自下而上的需求分析方法。兩種方法都圍繞著這樣一種思維過程：“如果我正確理解需求，那么這種方法可以滿足這種需求。既然我手中有一個最初的體系結構（或原型），它是否有助于我更好地理解需求呢？”
在你可以開始實現(xiàn)各個部分需求前，不必為整個產(chǎn)品進行完整、詳細的設計。然而，在你進行編碼前，必須設計好每個部分。設計規(guī)劃將有益于大難度項目（有許多內(nèi)部組件接口和交互作用的系統(tǒng)和開發(fā)人員無經(jīng)驗的項目）。然而，下面介紹的步驟將有益于所有的項目
◆ 應該為在維護過程中起支撐作用的子系統(tǒng)和軟件組件建立一個堅固的體系結構。
◆ 明確需要創(chuàng)建的對象類或功能模塊，定義他們的接口、功能范圍以及與其它代碼單元的協(xié)作。
◆ 根據(jù)強內(nèi)聚、松耦合和信息隱藏的良好設計原則定義每個代碼單元的預期功能。
◆ 確保你的設計滿足了所有的功能需求并且不包括任何不必要的功能。
當開發(fā)者把需求轉(zhuǎn)化為設計和代碼時，他們將會遇到不確定和混淆的地方。理想情況下，開發(fā)者可沿著發(fā)生的問題回溯至客戶并獲得解決方案。如果不能馬上解決問題，那么開發(fā)者所做出的任何假設，猜想或解釋都要編寫成文檔記錄下來，并由客戶代表評審。如果遇到許多諸如此類的問題，那么就說明開發(fā)者在實現(xiàn)需求之前，這些需求還不十分清晰或具體。在這種情況下，最好安排一兩個開發(fā)人員對剩余的需求進行評審后才能使開發(fā)工作繼續(xù)進行。