18 March 2008

Process Models Bridge The Requirements Gap

This is a review on a whitepaper that was sent to me by a friend;

The Requirements Communication Problem: Process Models Bridge The Requirements Gap by John Forrest of Holocentric. (Original article here)

This white paper proposes that linking requirements back to business processes is the first and best step you can take to ensure the quality of your project's business requirements.

There is another study I read a while ago that says processes lead to problematic requirements management and that (use) cases should be used in preference.

According to the wise folk who wrote that doctoral thesis business process models should only be used for non customer value adding work; typically back office support functions, or where you are automating the whole thing so the customer gets an instant end to end and seamless experience.

This aligns pretty nicely with management theory which suggests that if your front line people are dealing with complex or dynamic customer requirements they shouldn't be locked into processes; rather they should have tools that enable them to achieve desired outcomes.

(And this is where many localised process management teams and frontline management have got things so very wrong.)

Having said that, there is a lot going for mapping requirements back to frontline activities (and processes.) And business process management is still a growing field with plenty to offer in the right context.

Reading the article I felt there are a few incorrect points - e.g. managing requirements is not the MOST important aspect of project requirements. I checked out the business and they sell process mapping solutions. Naturally it's a bit biased.

Bottom line: The article is worth a read but be sceptical that processes are the solution to requirements management. They are just a part of the puzzle.

(You can read another review of this article at ZDnet here.)


  1. Anonymous10:46 pm

    Hi Craig - thanks for the reference to my white paper. The process oriented approach described integrates use cases and a process context. The requirements themselves are associated with use cases and the process can be viewed as a context and/or testable configuration which represents a meaningful business scenario. Under the covers, we use two meta-models, integrated via an meta-meta-model.

  2. Anonymous1:44 pm

    Hi Craig,
    Thanks for your comment on my trackback and notes. I agree with the gist of your reply, but I'll likely need a post to pull it together.

    Essentially, process is OK, even best, for rote, commoditized operations. The banks and telephone companies you reference (mistakenly) think that customer service is something that can be Taylorized into conformity.

    Differentiating one's business activities -- e.g., enabling the CSR that can up-sell based off of your buying, offer to change your service plan to save money, etc. -- requires non-process techniques to emerge the individuals and interactions required.

    Anyway, I need to think about this more. Managing this tension between operations and innovation is essential for me, so I appreciate the feedback.