वाटरफॉल मॉडल के संदर्भ में कई लोग यह तर्क देते हैं कि व्यवहार की दृष्टि से यह एक ख़राब विचार है। ऐसा खास कर उनके विश्वास के कारण होता है क्योंकि वे सोचते हैं कि किसी भी नॉन-ट्रिविअल परियोजना के लिए यह असंभव है कि वह अगले चरणों में जाने और उनसे सीखने से पहले एक सॉफ्टवेयर प्रोडक्ट के लाइफ़साइकल के एक चरण की पूर्णता को प्राप्त कर सकता है।

उदाहरण के लिए, हो सकता है कि क्लाइंट्स इस बात से अच्छी तरह से अवगत न हो कि काम के प्रोटोटाइप की समीक्षा करने और उस पर टिपण्णी करने से पहले उन्हें किन-किन आवश्यकताओं की आवश्यकता है; वे अपनी आवशयकताओं को लागातार बदल सकते हैं। डिजाइनरों और प्रोग्रामरों का इस पर थोड़ा-बहुत नियंत्रण हो सकता है। डिजाइन को अंतिम रूप देने के बाद यदि क्लाइंट्स अपनी आवश्यकताओं में बदलाव करता है तो नई आवश्यकताओं को समायोजित करने के लिए डिजाइन को अवश्य ही संशोधित किया जाना चाहिए। इसका प्रभावी ढ़ंग से यही अर्थ निकलता है कि काम करने के अधिकांश समय को अमान्य कर दिया जाता है जिसका अर्थ है कि लागत में वृद्धि कर दी जाती है, खासकर यदि परियोजनाओं के संसाधनों की एक बहुत बड़ी मात्रा को बिग डिजाइन अप फ्रंट में पहले से ही निवेशित कर दिया गया है।

हो सकता है कि डिजाइनरों को एक अकार्यान्वित सॉफ्टवेयर उत्पाद के डिजाइन का लेखन करने के समय भविष्य में कार्यान्वयन की कठिनाइयों की जानकारी न हो। इसका अर्थ यही है कि कार्यान्वयन चरण में यह स्पष्ट हो सकता है कि कार्यक्रम की कार्यक्षमता का एक विशेष क्षेत्र असाधारण रूप से कार्यान्वित करना मुश्किल है। यदि यही मामला है तो उस डिजाइन को प्रयोग करते रहने की अपेक्षा डिजाइन को संशोधित करना बेहतर होता है जो गलत पूर्वानुमान पर आधारित था और जो नए खोजे गए समस्या के क्षेत्रों के संदर्भ में अब उपयोगी नहीं है।

कार्यान्वयन के दौरान विनिर्देशन के ऐसे परिवर्तन के बिना भी, या तो स्क्रैच, "ऑन ए ग्रीन फील्ड" से नए SW परियोजना को शुरू करने, या कुछ पहले से ही विद्यमान, "ए ब्राउन फील्ड" (पुनः निर्माण से) को जारी रखने की संभावना है। वाटरफॉल पद्धति का प्रयोग मूलतः किसी दूसरे टीम के सतत वृद्धि के लिए, पहले से मौजूद SW के लिए भी, किया जा सकता है। जब सिस्टम का एनालिस्ट, कस्टमर की आवश्यकताओं को सही ढ़ंग से समझने में विफल हो जाता है तो निम्नलिखित चरणों के परिणामित प्रभाव को अभी भी इस पद्धति द्वारा वश में किया जा सकता है और इस मामले के साथ-साथ व्यवहार के मामले में भी यह एक QA टीम के लिए एक चुनौतीपूर्ण काम होता है।

"मैनेजिंग द डेवलपमेंट ऑफ लार्ज सॉफ्टवेयर सिस्टम्स", प्रथम पत्र जिसमें वाटरफॉल मॉडल का वर्णन है, में डॉ॰ विंस्टन डब्ल्यू रॉयस ने भी सर्वसामान्य रूप को "रिस्की ऐंड इन्वाईट्स फेल्योर" (जोखिम भरा और विफलता को आमंत्रित करने वाला) के रूप में वर्णन किया है।

"कोड कम्प्लीट" (एक पुस्तक जिसमें वाटरफॉल मॉडल के व्यापक प्रयोग पर आलोचना की गई है) में स्टीव मैककॉनल ने डिजाइन को एक "विकेड प्रॉब्लम" (दुष्ट समस्या) के रूप में संदर्भित किया है — जो एक ऐसी समस्या है जिसकी आवश्यकताओं और सीमाबद्धताओं को संपूर्णता से पहले पूरी तरह से ज्ञात नहीं किया जा सकता है। इसका निहितार्थ यही है कि सॉफ्टवेयर डेवलपमेंट के एक चरण को पूर्ण करना असंभव है, इस प्रकार अगले चरण में जाने के लिए वाटरफॉल मॉडल का प्रयोग करना भी असंभव है।

"ए रैशनल डिजाइन प्रोसेस: हाउ ऐंड व्हाइ टु फेक इट" में डेविड पार्नस ने लिखा है:

"[सिस्टम के] के कई विवरणों का पता हमलोगों को तभी चल पाता हैं जब हमलोग [सिस्टम के] कार्यान्वयन में प्रगति करते हैं। जिन कुछ चीज़ों को हमलोग सीखते हैं वे हमारे डिजाइन को अमान्य कर देते हैं और हमलोगों को उस पर जरूर नज़र रखना चाहिए." 

वाटरफॉल मॉडल के पीछे "मेज़र ट्वाइस; कट वंस" (दो बार मापों और एक बार काटो) का विचार भी हो सकता है और वाटरफॉल मॉडल के विपक्षी यह तर्क देते हैं कि यह विचार अलग राह पकड़ लेता है जब आवश्यकता में संशोधनों और स्वयं समस्या के संदर्भ में नई प्रतीतियों के कारण मापी जा रही समस्या लगातार बदल रही होती है। कुछ "इनवेस्टमेंट ऑफ मैन-टाइम" (व्यक्ति-समय का निवेश) के रूप में एक समाधान निकल सकता है जिसका उद्देश्य SW को वापस एकसाथ समेकित करना है जिसके लिए कुछ अनुभवी डेवलपरों को रिफैक्टरिंग पर समय देने का आदेश दिया जाता है। एक और दृष्टिकोण, इंटरफेस के साथ प्रतिरूपकता का लक्ष्यीकरण करके एक भविष्यवाणी डिजाइन द्वारा इन आवश्यकताओं की रोकथाम करना है।

सहायक तर्क
आलोचना
मॉडल
संशोधित मॉडल