BPR and Requirements Development Process Definition
The third time is the charm. Ten years ago, I wrote a paper on systems analysis and requirements definition for the Army Systems Engineering folks in Monmouth, New Jersey titled “Just in time Analysis.” It used mission decomposition in IDEF0 to identify needed use cases as an inventory of work to be done. Five years ago, I developed an internal process document based on the Iconix Process for Battelle to use in development of Disaster Management Interoperability Services software for the Department of Homeland Security.
I am back at it. For more than a year, the Virginia Department of Motor Vehicles (DMV) has been following a customized version of the Iconix Process for its BPR and Requirements development needs. The process grew out of the need for DMV to control its own destiny in its new software redesign effort. It had to start simply enough for business analysts to use it to drive business requirements. A prime goal was to ensure that it was business-driven; not IT driven. As it grew, however, the process required the power to handle complex issues, particularly the refactoring of multitudes of silo-style business processes into a set of requirements geared to a Service Oriented Architecture (SOA).
We are getting there. It is amazing how the process has evolved over the course of a year. We have documented our processes, and their evolution, using the same tools we use to document the actual DMV requirements. I am now in the process of gathering and publishing that information in a single coherent written manual. As I write this manual, it is more and more amazing what the folks at the Virginia DMV here have been able to accomplish in the last year. There is a lot, and it is good. I pray that the document I am writing will do them justice.
