RAD is basically the opposite of top down design methodology. A system is functionally broken down into as many susbsystems, modules, and submodules as possible, as early as possible in the design process. Then, starting at the lowest level, modules are designed, coded, implemented, tested and (hopefully) documented. Development often takes place in a test environment sometimes referred to as a sandbox where inputs into modules can be forced and outputs monitored.
Once a collection of modules are completed, they are strung together to form a subsystem or system for further development testing. Once enough integration has been completed, a test systme is released to the users for alpha testing.
Standard top down design works great for database applications. You layout your normalized data tables along with the data rules during your top level design, then secondary data tables and GUI are added as the design progresses.
In control systems, design modifications often occur based on the performance of the machine or other hardware you are trying to control. Databases and system parameters such as alarm points, system constraints, an operator inputs cannot be finalized until the basic low level system I/O is determined. It is not practical to complete the design of the top level control algorithms until low level modules are designed, coded and tested. User input in the form of alpha testing is required as early as possible as changes in operator inputs often necessitate changes in control logic and/or I/O.