Ah, the sweet sounds of success. 

I got the opportunity, this week, to collect a list of requirements for a strategic planning tool that we will license and use within Microsoft IT (COTS).  The fact that I got to collect requirements is not particularly cool.  What is cool is this: I made a point of using a business process model to collect them in an agile process that took less than a week to run, start to finish.

Every day, I try to find ways to make Enterprise Architecture relevant to stakeholders.  Every day, I look for reasons to trace success in our normal IT duties back to the efforts of the EA team.  In this case, it was the simple demonstration of how the requirements for a system were directly derived from the needs of a business process.

This method, for those not familiar with it, involves insuring that a process model exists for the business, in each of the areas where a particular capability needs to be developed or improved.  Now, the existence of a process model does NOT mean that the process model is detailed to the task level.  That is simply not necessary, especially when specifying requirements for a COTS tool. 

The advantage of this method is this: our requirements are far more rich, and far more complete, and developed far more quickly, than if we had simply employed ‘traditional’ use case analysis to derive them.  We didn’t start with task-level technical functions (like "user logon," or "collect application metadata") and work up to describe the user interface steps needed to use them.  We started with the business objectives and methods (like "manage portfolio" and "quarterly funding cycle"), and quickly found the scenarios that we needed to detail.  This method is far faster, and far more resilient, than traditional use case analysis. 

The process model that I developed for this use is high level, but it covers all of the functions of IT management and Strategic Planning where we are expecting to use a tool.  The requirements are gathered, and the RFP has been released.  Once the product is selected, however, we will need a detailed model, so we will be spending some time, in the near future, to refine that high-level model and better understand the detailed processes that various constituencies will engage in.  (I’m being agile here.  I don’t develop something before I need it, and only what I need to perform the task at hand).

That detailed process work begins next week. 

For now… success is demonstrating that deriving requirements from a process map works, and works well.

Oh, and we can manage it entirely in a repository-based modeling environment. 

EA works.  Q.E.D.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “Collecting requirements from business processes”
  1. We had approached a Requirements Gathering assignment in a similar manner in MSN. This helped us guide the stakeholders decide on the right scope for the engagement. We didn’t adopt the Agile approach though. But the process model was a clincher while selling our arguments on ‘devil-in-the-detail’ domain concepts. However, it is a challenge to sell this concepts to developers and technical architects (rather, the technical audience, at large)

  2. Troux?

    We’ve had great fun with our implementation.  I only wish I had the time to code a bit more, I think we could extend our EA even further out with a bit of interface/touchpoint programming.


  3. This approach makes sense. The requirements are derived from the business environment – either process based or to deliver a specific Capability (business function). IMO requirements should be anchored in this way and not ‘float in the ether.’

    It’s beneficial in post implmenetation benefit reviews.

Leave a Reply

Your email address will not be published. Required fields are marked *

1 × five =

This site uses Akismet to reduce spam. Learn how your comment data is processed.