Always know your goals

Recently, I've been involved in discussions about requirements. Business requirements - what do they represent? Now, you might wonder what this has to do with BPM unplugged. Every client has some intention in automating processes. But, when we get to requirements, no one really seems to know what they are or what they should represent.

Let's go back to process... When we understand what customers really expect from an organization, those expectations can be expressed as goals. The customer wants to "accomplish something." When we develop processes in light of these expectations we make sure that the process is measured against them. This is the one method we have to assure that our processes are not trying to do "something else."

The same is true with requirements. If we look at the end goal(s) of a process that is, already, established to meet a customer expectation then we can frame our requirements structure starting with those goals. If we work backward from there, into the process, then we maintain a better chance of drafting requirements that elicit a "goal-based" statement of what an actor/user expects to accomplish in the process.

If we develop use cases, then, the use cases will more accurately reflect the system view of the processes we've worked hard to map and the goal-based requirements we've drafted to represent them. We accomplish several things this way. First, we keep our requirements tied to customer expectation goals that we used to develop the business processes. Second, we maintain our focus on what actors/users expect to accomplish with respect to a system process that mimics the business process. Third, we maintain traceability throughout the project - from business processes to functional system artifacts. And, finally, we provide a stronger basis for testing both the processes and the systems that represent them.

So, always develop your processes and functional artifacts (your requirements) based upon the goals customers expect from the processes and actors/users expect from the systems that realize the processes.