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.
Comments
Anonymous
March 15, 2009
Windows Azure and Cloud Computing April CTP update of the Live Framework SDK and Tools Connecting to Live Mesh with the Live ID Client SDK Live Services - List Cloud Computing Links March 14, 2009 The Anatomy of Cloud Computing Software Architecture/SoftwareAnonymous
March 23, 2009
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)Anonymous
March 26, 2009
The comment has been removedAnonymous
March 30, 2009
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.