Requirements elicitation is a critical, yet under-appreciated, activity.  A core capability of business analysts, the ability to get the customers to describe what they want, and need, is both a science and an art.  Requirements elicitation requires equal measures of careful planning, situational awareness, acute listening skills, business acumen, and a kind of optimistic tenacity. 

I have long taken for granted two basic principles of requirements elicitation. 

Requirements_elicitation

First: a rule: The goal of requirements elicitation is to first understand, and then document, the needs of the business for a software solution.

Secondly, a process: if you want to understand a system (be it a software system or a system of business processes), look first at the business problem that it solves.  Look second as how people use that system to solve the problem.  Look next at the information that moves from one point to another.  Look last at the technologies that have been identified and consumed by the system.

To be honest, I don’t know where these notions came from.  I don’t remember reading them in any book, although I suppose that I may have done just that.  They are assumptions that I have used, for a long time, to organize my thinking about software requirements.

Yet when I went looking for industry sources that discuss the need to trace a requirement from the business problem, through business process, I could not find any. 

The "Guide to the Business Analysis Body of Knowledge (BABOK)" published by the International Institute of Business Analysis goes into some depth about requirements elicitation.  in the BABOK, the authors discuss many techniques for getting users to talk, including Brainstorming, Focus Groups, Job Shadowing, and JAD sessions, to name a few.  Unfortunately, their description of the traceability matrix, where a requirement is traced to something valuable, is sparse IMHO (This is true for BABOK version 1.6.  Perhaps the upcoming version 2.0 will provide examples?)

To my surprise: there is no mention of using a model of the business process as the source for software requirements!  As far as the BABOK is concerned, requirements come from people… not from a process model that may have required the consensus of six or sixteen people to help build it.  (Perhaps I missed it.  If there is such a reference, in v1.6 of the BABOK, please reply with the section where I can find it).

Of course, this only meant that I needed to search out other sources of information… Someone, somewhere, must be talking about using business processes as the source for IT software requirements. 

Now, many of you are probably saying: what about use cases?  Aren’t they simply descriptions of a business process, specifically for describing software requirements?

The answer is: go up a few layers of abstraction… away from the software… I’m interested in seeing how the subprocesses, from an enterprise viewpoint, are driving requirements.  I’d like to see how specific activities in a BPMN business process model drive requirements.  The requirements can be captured and shared in the form of a use case, or a big list, or a database in Visual Studio, for all I care.  But we don’t start with the use case.  We start with the process.

Or at least, I do. 

Do you trace your requirements back to business process models?  If so, why?  If not, why not?  I’d love to hear from others.