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.
August 20th, 2008 at 11:17 am
As you go through Business Process and requirements gathering and analysis you will also find business rules. Do you use any methodology to capture the rules?
Do you use ICONIX too? Can you keep track of relationships and sequence between rules?
I found the following Agile Business Rule Development could, http://www.ilog.com/brms/media/ABRD/ which could be helpful in your situation.
August 22nd, 2008 at 11:22 am
Actually, you may be of tremendous help here. I will research your link. We do of course, find business rules. We also have a separate process reviewing/discovering the more detailed business rules that are embedded in legacy system code and tables. The difference in granularity between BPR level rules and code level rules can be an issue. Still, in the long run, a rule is just another form of requirement that needs to be traced to applicable business processes.
August 22nd, 2008 at 11:32 am
Virginia DMV is using the ICONIX Process for Design. They have added a few twists that allow for collaborative design between DMV and its development vendor. This is actually exiting stuff. And yes, by using the Enterprise Architect tool we are able to identify relationships and sequencing of rules in the model. It will be interesting to see what the longer term implementation results are as well. As a contractor, I do not see any of the vendor proposals for the new system, but I expect that they all have something similar to ilog. It is going to be fun.