When we work in the abstract realm of pure analysis, we are detached from physical constraints such as implementation costs and limits imposed by technology choices. If requirements are considered from a purely business perspective then we may get so creative that we specify a system that exceeds our budget.
When planning a project it is useful to be able to identify the priority of requirements so that we can consider delivering the high value features early and can mark nice-to-have features as potential contingency for schedule slips. However, traditional requirements specifications fix the scope of the entire development, all system features described are deemed necessary and their descriptions are intertwined throughout the documents. Expressing requirements in a meshed form makes it difficult to trim scope in response to development delays.
The traditional approach is to document the requirements for the whole system and then freeze the requirements to provide a stable base for implementation to proceed. This assumes that we can come to a complete understanding of the system before developing real code. Perhaps this is possible in simple or well-known domains but this is a risky assumption to make for complex software development projects.
This raises a fundamental question of whether the human brain is capable of building a virtual system in our imaginations that we can explore and document. In a traditional waterfall process, requirements documents are the culmination of an analysis phase, during which the problem space has been explored via abstract models. To make this task manageable, we break the system down into pieces. However, we still need to keep track of all the pieces so that we may compose a coherent system from them. The human mind has limited capacity for complex problems, it is to be expected that when working in the realm of abstract ideas, we may miss scenarios, stakeholders’ needs and functions that need to be supported by the system. It is not clear that we can we fully determine the system requirements without starting to develop some software to explore possible interaction patterns. In his book "Serious Play", Michael Schrage  suggests that we can only really determine what we want by interacting with a prototype.
Let’s contrast the traditional approach to requirements in software development with how we operate outside the software domain. For example, if we are investing in home improvements such as a new kitchen or bathroom – do we just place an order based on drawings and make no comment until the installation is complete? Most people would be keen to see samples of new fittings and retain the right to change their mind about some aspects as installation proceeds. We would naturally expect that, as the fittings are installed in situ, we are likely to spot some ergonomic issues that were not apparent from the original two-dimensional plans.
The final flaw with freezing requirements early is that we are developing the system for use in a changing world. Time does not stand still during software development, the world around us changes – new business opportunities may arise during the development. When we freeze requirements early we deny the chance to adapt the system to a changing context.