需求與設計的區別究竟是什麼？ 教科書上的經典答案是：需求關注系統「做什麼」，設計關注「如何做」，其實這是乙個很模糊的說法。
無論是在結構化方法中還是在物件導向的方法中，需求分析的結果既包括了「做什麼」也部分包括了「如何做」，只不過描述「如何做」時抽象的層次比較高或者描述了某個區域性需求的「如何做」。客戶在提出系統需求時，可能對「如何做」提出一些約束條件，比如客戶要求必須採用三層結構，必須採用某個中介軟體等等。在需求描述文件中，一般稱為「設計約束」。開發人員進行需求分析後的結果包括了系統構成元素（無論是稱為模組還是稱為包）的分解，包括了資料流程圖或類圖等，這實際上也是在定義系統「如何做」，只不過這裡描述的「如何做」應是從客戶的角度比較容易理解的。
在需求中包括了：
ø系統的目標、範圍以及與外部的介面；
ø系統的功能、操作流程、處理規則；
ø系統處理的資料，資料有屬性，資料之間有關係，這些資料可以解釋為實體或者類；
ø對於系統可以劃分為子系統，子系統中再分為模組，子系統、模組只是對系統功能進行分類的一種方法；
ø系統的設計約束；
ø系統的執行環境等。
另外在需求中還包括了：
ø子系統或模組之間的介面關係；
這一部分往往是和設計有交叉的，系統分解為子系統、模組，以及他們之間的介面關係在概要設計中往往也是涉及到的。在需求中對系統的分解是從功能的角度，是從邏輯分類的角度進行系統的拆分，而在設計時對系統的拆分是從實現的角度，比如在設計時將系統分為介面層、中間層、資料層。
在需求中盡量不描述「如何做」實際上是避免對設計進行太多的約束與假設，這樣會限制設計方案的選擇。設計可以認為是一種決策行為，是一種選擇行為。需求確定以後，解決的方案可能有多種，如果在需求裡描述了「如何做」，實際上就限制了設計只能選擇某一種方案，而這種解決方案卻很可能不是最優的。所謂的解決方案可針對整個系統，也可能針對某個具體的功能。
原則上「做什麼」是由客戶提出來，由系統分析人員進行文件化，「如何做」是由開發人員來確定的並進行文件化。
「做什麼」與「如何做」在現實中是實際上是迭代進行，交織在一起的。在專案立項之前進行的可行性分析，包括了系統目標與範圍的確定，包括了技術路線的論證，包括了成本、風險、進度的估算等等，在上述的行為中，包括了簡單的需求與設計。在專案立項之後，採集了客戶需求，進行需求分析，然後考慮系統的解決方案，此時還可能需要修改或增加需求。二者交叉或並行執行。
在需求和設計之間劃一條明確的界線其實很難，理解了二者的根本區別，企業可以自己硬性地規定一條界線：即哪些內容在需求中描述，哪些內容在設計中描述。
需求分析與設計
軟體需求規格說明書.docx 我們的產品受用人群為在校大學生，我們定位在我們的同學身上。在推廣的過程中，逐漸增加使用者群。在他們使用的過程中，我們定期徵詢他們的建議，然後不斷的完善我們的程式。同時線上線下的推廣也是很重要的。等使用者群逐漸壯大，有資金後我們還可以以廣告的形式繼續推廣。相對於其他記賬程...
需求分析與原型設計
031402632 朱松 031402615 林昊斌 n need，需求 b benefit,好處 c competitors,競爭 d delivery,推廣 結對過程 原型模型介紹 導師選擇系統主介面中根據輸入的使用者名稱進入不同的系統介面，分為學生介面和導師介面，當遇到問題時，可發郵件諮詢管理...
需求與設計的主要過程總結
需求 分析 設定工作上下文的範圍 業務事件 業務用例 網羅需求 多種方式，如用 volere模板問卷，場景方式 包括功能性 非功能性需求 驗收標準 編寫需求 目標，風險承擔者，目標使用者，強制限制條件，命名定義，事實與假定，工作範圍，產品範圍，需求項框架，原子需求volere，功能性需求 voler...