Process Models - are they bad for Requirements?

I am not aware of the origin of Process Models as we see them today, but their profile was certainly raised by Hammer and Business Process Re-engineering; you certainly had to define your Business Process before improving/re-engineering it. For myself, the one aspect of Process Models that does not get enough attention is defining & understanding the Events in the business environment (external or internal) that kick-off the execution of a Process; know your Events, as they come in handy in many ways when defining Information System Requirements

As a format for documenting Information System Requirements, process models can have a negative impact on the resulting system. The process as it exists at the time of documentation has often been ‘hard-coded’ in the delivered computer system; when the process needs to change, the system cannot support a different process, and the business starts to adapt or create work-arounds to get the work done despite the constraints of the system.

This situation occurs frequently because it is not recognized that some aspects of the business are less stable than others. It has been shown that the process of a business, especially the order of separate steps, is the least stable aspect of a business; at the other end of the scale, the data items and their definitions as used by a business are the most stable aspect of that business. In between the two ends of the scale fall things like specific procedures (units of work) and business rules.

So, automation of the current business process should not be an Information System Requirement. In fact, more generic process and workflow software have been developed over the years to specifically support rapid change in process, adding or changing or re-ordering process steps as needed.

Where Process Models play a role in documenting Information System Requirements is to provide a context for Use Cases. Most steps in a process map will state that some work is done in that step, before the process flow continues; often this work involves use of an Information System, which can be documented as a Use Case. As stated in earlier posts, the Use Case then provides context for Declarative Requirement Statements, as well as a cross-reference to data items and their definitions in a Data Model.

Just a few years ago, this would have been the last ‘format’ that would have been described in this document. However, a new emphasis on methods and formats for documenting Business Rules has recently emerged, the topic for my next posting.