Solutions for the Requirement Gathering Process
Friday, October 26th, 2007Gathering the requirements for a new system takes time. Imagine what it is like to record the opinions and demands of dozens of employees, sort the priorities and then make them work side by side while implementing the software rollout. The requirement gathering process (RGP) is often the cause of project failure because it drains an organization’s resources before a new system is even implemented and tested. Over the past three decades, organizations have slowly improved upon the RGP and have discovered and actualized various methods of success. There have been three notable attempts at rapid application development (RAD). Two proved unsuccessful, though factors from each are still being used in the third and seemingly successful attempt at RAD.
The first attempt at RAD was the introduction of the business analysts (BA) position, who was business minded but also trained in IT. By creating a ‘bridge’ between business users and IT, information that was often lost in the jargon between business users and IT was reclaimed. Although a blessing at first, BAs soon became technicians in their own right and began to guide and provide information rather than translate it, further distorting the messages between business users and IT. In this three part series I will continue to illustrate progress in RAD.
