An important element of the philosophy of RAD is the belief that not all a system’s requirements can necessarily be identified and specified in advance. Some requirements will only emerge when the users see and experience the system in use, others may not emerge even then, particularly complex ones. Requirements are also never seen as complete but evolve and change over time with changing circumstances . Therefore, trying fully to specify a system completely in advance is not only a waste of time but often impossible. So why attempt to do it? RAD starts with a high-level, rather imprecise list of requirements, which are refined and changed during the process, typically using toolsets . RAD identifies the easy, obvious requirements and, in conjunction with the 80/20 rule , just uses these as the starting point for a development, recognizing that future iterations and timeboxes (see below) will be able to handle the evolving requirements over time. Hough (1993) suggests using the technique of functional decomposition and each function identified and the requirements listed, but, he says,
the precise design specifications, technical issues, and other concerns should be deferred until the function is actually to be developed
The system to be developed is divided up into a number of components or timeboxes that are developed separately. The most important requirements, and those with the largest potential benefit, are developed first and delivered as quickly as possible in the first time box. Some argue that no single component should take more than 90 days to develop, while others suggest a maximum of six months. Whichever timebox period is chosen, the point is that it is quick compared with the more traditional systems development timescale.
Systems development is sometimes argued to have three key elements. In tradi- tional development two are typically variable: time and resources (see Figure 6.3). In traditional development when projects are in difficulty, either the delivery time is extended or more resources are allocated or both but the functionality is treated as fixed. In RAD the opposite applies, resources and time are regarded as fixed (allocating more resources is viewed as counterproductive although this does sometimes happen), and so that only leaves functionality as a variable. So, under pressure and when projects are in difficulty, time and resources remain constant but the functionality is reduced.
RAD compartmentalizes the development and delivers quickly and often. This provides the business and the users with a quick, but it is hoped, useful part of the system in a refreshingly short timescale. The system at this stage is probably quite limited in relation to the total requirements, but at least something has been delivered. This rapid delivery of the most important requirements also helps to build credibility and enthusiasm from the users and the business. Often for the first time they experience a system that is delivered on time. This is radically different from the conventional delivery mode of most methodologies which is a long development period of often two to three years followed by the implementation of the complete system. The benefits of RAD development is that users trade off unnecessary (or at least initially unnecessary) requirements and wish lists (i.e. features that it would be ‘nice to have’ in an ideal world) for speed of development. This also has the benefit that, if requirements change over time, the total system has not been completed and each timebox can accommodate the changes that become necessary as requirements change and evolve during the previous timebox. It also has the advantage that the users become experienced with using and working with the system and learn what they really require from the early features that are implemented.
Figure 1.2 illustrates three chunks of development and, although the overall time to achieve the full implementation could be the same as with a .traditional development, the likelihood is that the system actually developed at the end of the three timeboxes will be radically different from that developed at the end of one large chunk as a result of the learning and evolving processes which leads to change being made to each specification at the beginning of each timebox.
Some RAD proponents argue that, if the system cannot be divided into 90 day timeboxes, then it should not be undertaken at all. Obviously such an approach requires a radically different development culture from that required for traditional or formalized methodologies. The focus is on speed of delivery, the identification of the absolutely essential requirements, implementation as a learning vehicle, and the expectation that the requirements will change in the next timebox. Clearly such radical changes are unlikely to be achieved using conventional techniques.
Once the duration of the timebox has been decided it is imperative that the system is delivered at the end of it without slippage, as timeboxes are fixed. So how is this achieved? Well, first, by hard work and long hours and, secondly, by the use of the other RAD techniques discussed below. But also if slippage is experienced during development of a timebox then the requirements are reduced still further (i.e. some of the things that the system was going to do will be jettisoned).
The Pareto principle
This is essentially the 80/20 rule and is thought to apply to requirements. The belief of RAD proponents is that around 80 per cent of a systems’ functionality can be delivered with around 20 per cent of the effort needed to complete 100 per cent of the requirements. This means that it is the last, and probably most complex, 20 per cent of requirements that take most of the effort and time. Thus why do it? – just choose as much of the 80 per cent to deliver as possible in the timebox, or at least the first timebox. The rest, if it proves necessary, can be delivered in subsequent time boxes.
In RAD the requirements of a project are prioritized using what is termed the MoSCoW Rules:
- M = ‘the Must Haves’. Without these features the project is not viable (i.e. these are the minimum critical success factors fundamental to the project’s success).
- S = ‘the Should Haves’. To gain maximum benefit these features will be delivered but the project’s success does not rely on them.
- C = ‘the Could Haves’. If time and resources allow these features will be delivered but they can easily be left out without impacting on the project.
- W = ‘the Won’t Haves’. These features will not be delivered. They can be left out and possibly, although not necessarily, be done in a later timebox.
The MoSCoW rules ensure that a critical examination is made of requirements and that no ‘wish lists’ are made by users. All requirements have to be justified and categorized. Normally in a timebox all the ‘must haves’ and at least some of the ‘should haves’ and a few of the ‘could haves’ would be included. Of course, as has been mentioned, under pressure during the development the ‘could haves’ may well be dropped and even possibly the ‘should haves’ as well.
RAD requires high levels of participation from all stakeholders in a project as a point of principle and achieves this partly through the JAD workshop. JAD (Joint Application Development) is a facilitated meeting designed to overcome the problems of traditional requirements gathering (see Section 16.2), in particular interviewing users. It overcomes the long time that the cycle of interviews take by getting all the relevant people together in a short period to hammer out decisions. Normally in the context of RAD, a JAD workshop will occur early on in the development processto help establish and agree the initial requirements, the length of the timebox, what should be included and what excluded from the timebox, and most importantly to manage expectations and gain commitment from the stakeholders. Sometimes a subsequent JAD workshop is used to firm up on the details of the initial requirements, etc. In some RAD approaches the whole process is driven by a series of JAD meetings that occur throughout the timebox.
The fourth element is the presence of an executive sponsor. This is the person who wants the system (or whatever the focus of the meeting is), is committed to achieving it and is prepared to fund it. This person is usually a senior executive who understands and believes in the JAD approach and who can overcome the bureaucracy and politics that tend to get in the way of fast decision making that usually bedevils traditional meetings
Prototyping is an important part of RAD and is used to help establish the user requirements and in some cases the prototype evolves to become the system itself. Prototyping ;helps speed up the process of eliciting requirements, and speed is obviously important in RAD, but it also fits the RAD view of evolving requirements and users not knowing exactly what they want until they see or experience the system. Obviously the prototype is very helpful in this respect.
Sponsor and Champion
Having a committed sponsor and a champion of the systems is an important requirement for RAD and for its success. We have discussed the sponsor above. A champion is someone, often at a lower level of seniority, who is also committed to the project, who understands and believes in RAD, and is prepared to drive the project forward and overcome some of the bureaucracy and politics.
RAD usually adopts, although not necessarily, the use of toolsets to help speed up the process and improve productivity. In general it is usually argued that the routine and time-consurning tasks can be automated as well as using available tools for change control, configuration management, and even code reuse. Reuse of code is another way that RAD speeds the development process. However, it is not just about speed but also quality because existing code or modules have usually already been well tested, not just in development, but in real use. RAD searches for shortcuts and reuses code, maybe clones existing code and modifies it, or utilizes commercial packages, etc. where applicable. This may be code within the organization or bought from outside. Sometimes more than just a little piece of code is used; for example, complete applications may be used and the developers use this as the basis of the new system and change the interface to produce the desired results. Many ‘new’ e-commerce or Internet applications have been developed in this way using the legacy systems and then providing a new ‘umbrella’ set of applications and user interfaces on top. The idea is to leverage existing code, systems, experience, etc.
Specific RAD productivity tools have been around for some time and are developing fast, and existing tools and languages are being enhanced for RAD, particularly for rapid development of Internet and e-business based applications.
- David Avison & Guy Fitzgerald, 2006. Rapid application development (RAD). In David Avison & Guy Fitzgerald Information Systems Development. 4th ed. Pearson Education Limitied. Ch. 7. pp.128-132.ISBN-13 978-0-07-711417-6