> > You cannot analyse how users will empirically interact with a product that does not yet exist.

You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user.

But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.

Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put <non-iterative approaches> under the heading "waterfall".

Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!

You might be interested in [1]. Supposedly it has the diagram that became known as the "waterfall" diagram. I don't think the author is advocating for what we normally associate with waterfall, though, as there are some additional steps they advocate for. They start with a simplified model, criticize it, and then add some more complexity to the model.

Also to note, the paper is titled "Managing the Development of Large Software Systems."

The author outlines 5 steps they believe need to be used to improve the success of a project. One step is called "do it twice" in which the author advocates the development of a prototype well in advance of delivering the final product. I think this is iteration. It's not indefinite iteration, but it's definitely not showing the big bang single release waterfall approach either.

It also advocates to involve the customer throughout the process instead of only at the end.

The summary says to refer to Figure 10 as the process that incorporates the author's steps. This final diagram is pretty far from the simplified and flawed waterfall picture that has been pulled from the front of the document.

[1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

Thank you!

Waterfall is indeed a decidedly non-iterative approach. Anyone calling an iterative approach "Waterfall" is, well, confused about the terms. As soon as you add iteration, you're doing something else. Something intelligent. Often some variation of Iterative & Incremental (of which Scrum is an extreme form), Evolutionary, or perhaps the V-Model.

When I studied the SDLC formally, many years ago, “iterative waterfall” was called the spiral model.

Waterfall is not iterative. That’s the whole point. You go over the waterfall once. If you’re iterating then, by definition, it’s not waterfall.

> you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user

This is almost always false, for any non-trivial project, within the usual commercial constraints of money and time.