I sometimes use the analogy of baking when talking about software delivery. Eliciting requirements and then developing software is often like baking bread.
The customer and the development team have a good common understanding of the domain they are working in. White or brown, baguette or bloomer, both mean just about the same thing to the customer and to the bakers. The bread is baked that morning, and then it sits on the shelf. Once the bread is made, the clock is ticking. It needs to be eaten quickly. Once the requirements have been elicited, the software needs to be developed promptly. Otherwise, the business needs will change, or the technology landscape will change, or the user representatives or user base itself will change, or the competition will change. Whatever happens, change is the constant. Change in any of these and the piping fresh requirements will have gone cold and then stale.
That’s one important reason agile development places such an emphasis on moving requirements through analysis (when this happens) to design to code to tested code, feature by feature as quickly as possible. The more this happens, the more time a software development team spends dedicating itself to adding value to a customer through working software and the less time it spends on wasteful activities.