什麼是需求呢，簡單地說，是（正在構建的）系統必須符合的條件或具備的功能。
在軟體開發中，擺在我們面前的第乙個問題就是如何獲取和描述正確的需求，而後才能談得上構建正確的系統來滿足對應的需求。可是，需求的獲取不是一件容易的事，就拿大家熟悉的日常生活中的活動來看，需求的捕獲都不簡單。何況，隨著系統複雜度和專案規模的增加，系統的需求捕獲、定義和管理成為乙個複雜的問題。
以下借食客（代稱「賈方」）和廚師（代稱「伊方」）之間的對話來說明乙個需求溝通和獲取的過程，看看在其中我們可能會碰到的問題和一些常見的陷阱。
需求的溝通過程
伊方
：「中午吃什麼呢」
?（了解需求，提出需求的大範圍）
賈方：「隨便，能吃得下就行」
（想不清楚自己的需求。。。，當然午飯本身就包含了很多需求）
伊方：「就怕你吃不下，吃公尺飯還是麵條」
（開始引導需求。。。，
是否還有吃飽子的選擇呢？）
賈方：「天熱，還是麵條吧，做起來簡單」
（其實已經有需求，就是不想說或是沒有意識到）
賈方：「嗯，最近也有些想吃海鮮了」（
看似隨便一說，可能包含了真正的需求）
伊方：「那好啊，我們就做海鮮麵吃吧」
（總結了乙個高層需求）
賈方「嗯，海鮮面嘛，至少得有魚和蝦吧」
（開始細化需求）
伊方：「我以前很少做海鮮面，你能給些建議嗎？」
（考慮需求獲取的辦法，敞開式問題）
賈方：「應該是湯麵，最好要再加點菜
」(
更多的功能性需求
)
賈方：「夏天了，麵湯要清淡一些」
（哈哈，非功能性需求？可是，清淡怎麼體現？）
伊方：「寬麵還是細麵？」
（再一次使用選擇式問題）
賈方：「細麵吧」
伊方：「對了，你以前如果有吃過海鮮面的話，回憶看看需要哪些原料」
（模擬法獲取需求）
賈方：「那倒沒有印象了，不過我可以上網給你搜尋乙份海鮮面的選單；哈哈，有了，麵條
500克
，蝦半斤。。。。」
（需求還是設計呢？）
伊方：「你有吃過這麼做出來的海鮮面嗎？這就是你需要的海鮮面嗎？」
（挖掘問題背後的問題，客戶的實際需求是這樣的嗎？）
賈方「我也沒試過，只是看這裡這麼寫的，感覺做出來的會好吃」
（是個假象，只是感覺而已，實際的需求還是要好吃的面，可是『好吃』怎麼體現呢？）
伊方「嗯，我打個**諮詢一下，看看怎麼做好吃」
（諮詢專家？頭腦風暴？好像已經開始設計了哦？）
伊方「要不，我先少做一點，你先嚐嚐；
（快速原型法？可是對於做頓午飯來說，似乎代價太大了）
伊方「或者，我用少量面和海鮮先做湯，你嚐嚐口味」
（這也可以迭代？麵湯是最重要的用例或使用者故事？客戶最關心湯的味道）
伊方「你看，這裡有個海鮮面的，希望做出來的是這樣的」
（原型介面？）
賈方「我們家裡有現成做好的蝦和魚丸，就用它們好了」
（設計約束？）
伊方「除了海鮮面，還要有其他配菜嗎」
（開始考慮其他相對次要的需求）
。。。。。。
為了方便，伊方記錄了對於海鮮面的需求
（需求規格說明？）
故事的繼續
-烹飪開始
伊方開始了烹飪海鮮面的過程。
先準備好蝦、魚丸、麵條、青菜等主料，考慮好燒水、下面、加海鮮、下調料等的順序（架構，或是其部分？）
為了今後做海鮮面作為參考，將上述的配方和過程記錄下來（設計文件？過程文件？）
燒水、下面、海鮮單獨加熱、加入海鮮、新增調料。。。。。。，哈哈麵條要出鍋了（實現？）
快出鍋前，先嚐嚐口味，加調料不斷調整（測試和修改？）
。。。。。。
驚人發現
發現用家中現成的蝦和魚丸來做海鮮面，味道不錯，決定批量生產，銷路很好（構件化？服務？）
發現用這種方法調製出來的麵湯，實在是很鮮美，用它來煮面，有沒有海鮮似乎都不重要了（框架？）
終有一日，伊式海鮮面風行天下。。。
秘訣
用做軟體的方式來做海鮮面，效果果然不同凡響。
一頓午飯的需求
一頓午飯的需求 什麼是需求呢，簡單地說，是 正在構建的 系統必須符合的條件或具備的功能。在軟體開發中，擺在我們面前的第乙個問題就是如何獲取和描述正確的需求，而後才能談得上構建正確的系統來滿足對應的需求。可是，需求的獲取不是一件容易的事，就拿大家熟悉的日常生活中的活動來看，需求的捕獲都不簡單。何況，隨...
一頓午飯引發的風波
又是乙個陽光燦爛的中午，看了一上午的報紙，茶水也順帶喝了不少，肚子早已經咕咕作響了，今天中午吃點什麼了，貌似樓下的新開張的盒飯還不錯，於是我來到樓下準備買上一盒。菜色還不錯，有6元，8元，10元，12元，20元的，像哥這樣的精英管理人才，怎麼著也的吃最高端的才配合身份，就在我準備購買時，乙個響亮的聲...
又是一頓搓歸來
嗯，從現在開始，珍惜每一次搓的日子嘍 月份了，距離明天七月份僅有八個月了，再八個月，大家就要各奔東西了，或許可能一生能再相遇到的時機都不多了 可惜好像還是和 個人沒在一起吃過飯，甚至基本上沒講過話 所以，以後大家能一起出來，偶就決定一定盡興 如果說初中的友誼不能算是友誼的話，高中最多只能算是初級階段...