Similarly in a large DSDM development the implementation may be phased, so system design may be concurrent with some implementation. This approach is not as chaotic as it might at first appear. The results of reviews feed into the setting of objectives for the next cycle. One important aspect of RAD not covered so far is the constant focus on meeting the necessary business requirements. Requirements are baselined early in the project at a high level to allow their refinement through prototyping activity, but more importantly in a RAD project they have to be clearly prioritised.
All activity is timeboxed.
Any of the lesser requirements which cannot be fitted into the time available are either considered for inclusion in the next cycle or they may be left to later enhancement work after the project is over. If during a timebox new requirements are discovered, their relative priorities are discussed and recorded. Since timeboxed activity has a clear cut-off date, the introduction of new requirements means that the possibility of dropping existing requirements to a lower priority to allow their implementation is negotiated. In a DSDM project, requirements may not always be met, but time constraints are. The acceptability of the tested system is assessed against the agreed minimum useful set of requirements rather than all the requirements.