همان‌طور که قبلاً نوشته بودم، یکی از باورهای رایج در توسعهٔ نرم‌افزار این است که باید ابتدا «مسئله» را خوب شناخت و بعد آن را حل کرد، یعنی اول باید نیازمندی‌های مشتری را کامل استخراج، تحلیل و درک کنیم تا بعدش بتوانیم وارد طراحی و پیاده‌سازی راه‌حل شویم.
ظاهر این باور خیلی منطقی است؛ شاید بپرسید: «مگه کار دیگه‌ای هم می‌شه کرد؟» یا «نکنه منظورتون اینه که قبل از شناخت مسئله به دنبال راه‌حل بریم؟ این که خیلی بده!»
جواب این است که بله، درست است که برای طراحی راه‌حل باید اول مسئله را شناخت. ولی در این موضوع هم نباید افراط کرد. می‌پرسید چرا؟ دلیلش این است که در دنیای واقعی شما هیچ‌وقت نمی‌توانید بدون ساختن راه‌حل یا لااقل بخشی از راه‌حل، مسئله را کامل درک کنید! در واقع اگر می‌خواهید مسئله را کامل درک کنید، یکی از بهترین راه‌هایش این است که یک راه‌حل اولیه بسازید، آن را به مشتری یا کاربر نهایی نشان بدهید و از او بخواهید از آن استفاده کند. در این صورت هم شما و هم مشتری/کاربر به درک خیلی بهتری از نیازهای وی خواهید رسید و می‌توانید راه‌حل‌تان را بر اساس این درک بهبود دهید.
همهٔ ما انسان هستیم، و انسان‌ها نمی‌توانند یک چیز پیچیده مثل نرم‌افزار را قبل از «دیدن» و «لمس کردن»اش به طور کاملی تصور کنند. به همین دلیل است که به نفع همهٔ تیم‌های توسعهٔ نرم‌افزار - به‌خصوص آن‌هایی که نگران فهم ناقص‌شان از نیازمندی‌ها هستند - است که «فهم مسئله» و «تولید راه‌حل» را فعالیت‌های جدا از همی نبینند، بلکه این‌ها در یک چرخهٔ فشرده و به‌هم‌پیوسته، مرتباً به دنبال هم اجرا می‌شوند، مثل شکل زیر:
اینطوری حتی کارتان سریع‌تر هم پیش می‌رود، چون راه‌حل اشتباهی تولید نمی‌کنید یا اگر تولید کنید، زودتر معلوم می‌شود. به مرور راه‌حل شما کامل‌تر و بیشتر مطابق نیازهای مشتری‌تان خواهد شد. حتی اسکات امبلر - یکی از پیشگامان حوزهٔ مهندسی نرم‌افزار شیءگرا - استدلال می‌کند که وقتی ابتدا و قبل از توسعهٔ نرم‌افزار، سعی می‌کنیم کل نیازمندی‌ها را تشریح کنیم، نزدیک دوسوم سرمایه‌گذاری ما در تولید آن نرم‌افزار به هدر می‌رود.
به همین دلیل است که اکنون در همهٔ دنیا، روش‌های تکاملی برای فهم و تشریح نیازمندی‌ها بر مبنای توسعهٔ تدریجی نرم‌افزار، فراگیر شده‌اند و روش سنتی - که در آن قبل از تولید نرم‌افزار، یک سند تفصیلی از نیازمندی‌های پروژه تهیه می‌شد - رو به منسوخ شدن است.