Collecting requirements from business processes

 

Collecting requirements from business processes

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.

Posted: Friday, March 13, 2009 6:20 PM by NickMalik

Inside Architecture : Collecting requirements from business processes