Change Requests or CR from Business Users after an application has been deployed are an integral part of the Development Process. No matter how much care and thought went into the creation of the requirements on which the application was built, it is impossible to get everything right the first time. This is particularly true of large and complex enterprise applications.
In most organizations, CR and Defects are tracked together after initial deployment of the application. There are benefits to this approach, primary among them being the ability to track these requests together and group them into manageable buckets that Development can deliver on at periodic intervals. It is also a practical solution to the reality that in a lot of cases, the lines that divide Defects from CR are often blurry. So, instead of managing entirely different processes for Defects and CR, most organizations have taken the practical step of merging both into one process.
While this is very advantageous for management and tracking of both defects and CR, improperly documented CR actually end up creating a lot of churn and the productivity gains of merging both processes into one is quickly lost. The main reason for this is that CR are documented and tracked in exactly the same manner as Defects using the same tool. Documenting defects is relatively straightforward and business users are able to effectively identify the improper behavior and communicate what the correct behavior of the application should be. The tools used to track Defects also do a good job of enabling these simple communications between the users and developers, in addition to tracking status and other functionality needed to manage this process.
However, documenting CR in the same manner as Defects leads to very suboptimal results. For starters, CR are really requirements that were either missed or improperly communicated during the initial requirements gathering stage. Unlike defects, there is no simple baseline of functionality that is expected behavior versus actually delivered software to call out. The complexity of CR also varies significantly from extremely minor changes (typically at the UI level) to full blown extensions to functionality. Having the testers or end users document these changes results in requirements that are partial, unclear or flat out wrong. This is not a criticism of users but rather an expected outcome. This is not their core competence. They are experts in Finance, Marketing, Sales, Accounting and a myriad other skills that are found in modern Corporations. They are not experts in creating Software Requirements.
The net result of this is that CR often go through multiple iterations of Development as the Developers and Business Users attempt to determine what is exactly needed. This leads to increase in delivery times, frustration on both sides and significant loss in productivity across the entire team. There is also a very real danger of scope creep as CR are used to expand the scope of the project incrementally over time leading to significant cost overruns.
The simple solution to this problem is to devote full time Requirements Engineers to documenting and managing CR. The number of Requirements Engineers needed to support this effort will vary depending on the complexity of the project. But in my experience, one full time Engineer is more than sufficient to support even a large and complex development effort. The cost argument is made that devoting a full time Requirements Engineer AFTER development is complete is not justified. But when one considers the lost productivity, frustration and real expenses incurred with a never ending stream of CR, the cost of the Requirements Engineer turns out to be a bargain. Paybacks of 5 to 10 times the cost of the Engineer can easily be reaped on most projects.
