In any methodology, you can response to changes or modifications. However, some methodologies are better at responding to changes and delivering those changes at less expense (of time and/or money) to customers and users.
It sounds like you have a fundamental misunderstanding of what the difference between agile (iterative and incremental) and waterfall (sequential) models are. Even if you are following a sequential model, you don't need to redo the whole system if there are changes after development. In a traditional waterfall model, you capture your requirements up front and fix them. Then, you design those requirements and implement a solution, then test the solution, and finally release a system. The idea is that this system meets all of the needs of the customer and users. But there's still maintenance after the fact, and even in a sequential environment, you can release patches and new versions of the software. If you continue to follow a sequential model, you'll bundle up a large number of requirements at the front, and proceed sequentially through each of the other steps, ending in a release.
The iterative and incremental models focus on delivering smaller pieces of the software. These pieces are delivered quickly to the user and are used to obtain feedback and perform course corrections - identify mistakes or misunderstandings in the requirements or design. You don't fix the whole set of requirements for the product at the start, but instead prioritize and either demonstrate or deliver the things that will add the most value earlier in the project. This type of approach takes the mindset that software can continually evolve and change, and a project isn't done until the customers and/or users are satisfied.
Specifically, in RAD, if you get a change after Cutover, you'll have to do some level of Requirements Planning. You can't just go and implement a change (in most projects, especially larger, corporate projects). You'll need to ensure that any changes make sense within the product/project scope and constraints and that the requirements are clear and consistent. You also want to ensure that changes made for one stakeholder don't have negative impacts on other stakeholders. Most of the change effort should be in the User Design and Construction, though, and then you proceed to Cutover.